Slow boot of Ubuntu into Unity 3D with proprietary nVidia drivers

I have Ubuntu Oneiric Oncelot 11.10 with proprietary nVidia (nvidia-current: 290.10-0ubuntu1~oneiric~xup1) drivers.

And there're 2 things I'm tired of:

1. Slow boot. Mostly a black screen after nVidia drivers are already loaded.
   It turned out it lasts more then a minute (73 seconds for example, compared to booting into Unity 2D - 38 seconds).
2. Slow wake-up from suspend. Don't have precise numbers but Unity 2D wakes just immediately while Unity 3D shows me a black screen more then a minute.

So I decided to try "bootchart".
Installed it with: sudo apt-get install bootchart
And booted into:
Unity 3D - got 1:12.98 min

Unity 2D - got 0:38.66 min

Then looked if some processes related to nVidia differ in both boot logs.
And indeed I found out that "nvidia-settings" process was mentioned proc_ps.log in such proportion:
- 66 times for Unity 3D and
- 21 times for Unity 2D.

That lead me to conclusion that disabling "nvidia-settings" may improve boot performance.
So I did "sudo chmod a-x /usr/bin/nvidia-settings" and the next boot in Unity 3D took the same 37 seconds (0:37.76) as with Unity 2D.

For sure it is not the solution, but at least a direction to look.

Moreover this unfortunately has nothing to do with wake-up delay, so keep looking into it.

Anyway, hope this helps.

P.S. Make sure you know what are you doing while dealing with system files.

Fix FlexNET License Server Manager

For some reason in FlexNET tools version 11.4 license server manager application stopped working. Actually it won't start at all:
=========
 ./lmgrd 
bash: ./lmgrd: No such file or directory
=========

the most probable reason for such sort of problem is unavailability of some dependence (i.e. shared library).

So let's look at dependencies:
=========
$ ldd lmgrd 

linux-gate.so.1 =>  (0xb784b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb781a000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb77f0000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb77d1000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7655000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7650000)
/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xb784c000)

=========

The first suspect is definitely (for me at least it was so) "linux-gate.so.1"

But it turned out that it's ok: http://www.cyberciti.biz/faq/linux-linux-gate-so-1-library-dynamic-shared-object-vdso/ refers to http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-102-3/

=========

This virtual library provides the necessary logic to allow user programs to access system functions through the fastest means available on the particular processor, either interrupt, or with most newer processors, fast system call.

=========

Others look pretty solid except the last one:  /lib/ld-lsb.so.3

=========

$ file /lib/ld-lsb.so.3

/lib/ld-lsb.so.3: ERROR: cannot open `/lib/ld-lsb.so.3' (No such file or directory)

=========

For some reason in some modern Linux distributions this symlink is not set by default and one needs to fix it whether manually or simply installing "LSB core" (Linux Standard Base core support package)  package.

In RedHat:
=========
yum install redhat-lsb.i686
=========


or for Debian/Ubuntu
=========
apt-get install lsb-core package

=========

Now it resolves correctly:

=========

$ file /lib/ld-lsb.so.3

/lib/ld-lsb.so.3: symbolic link to `ld-linux.so.2'

=========

And as a consequence lmmgr starts and acts properly now!