Wednesday, May 01, 2013

Upgrading to Kubuntu 13.04 from 12.10 breaks Ubuntu 13.04 in VirtualBox

Another post in my short saga of upgrading to Kubuntu 13.04.

The situation


So here's my scenario: I'm running Kubuntu 12.10 and all is well (enough). In a VirtualBox instance I have a copy of Ubuntu 13.04 that I'm keeping up to date as it gets closer to release. In all, everything in working fine as I work inside the VM and prod at it from the outside.

Suddenly my system starts to act a bit flaky, and ultimately freezes up completely. I suspect this is actually an audio driver issue, and I figure Kubuntu 13.04's new kernel may just fix it, so I decide to upgrade to Kubuntu 13.04 after doing a hard-reset to recover from the lockup.

Debugging a hosed virtual machine


The upgrade goes smoothly enough, but my virtual machine is now completely baffooned. The screen comes up but is just the default purple wallpaper. Clicking does nothing. Eventually I get an error message that there was a system failure and perhaps rebooting will make things better. There is a button on the dialog that says "Continue" (or "OK") but doesn't show up until you hover over it. Rebooting does not help.

From the VirtualBox 'Machine' menu I can send the Ctrl-Alt-Delete signal and this is captured correctly. I can log out and log back in, but this changes nothing. I can get to a command prompt by hitting <Host>-<F1> and log in there. I create a new user with 'adduser', hit <Alt>-<F7> to return to the GUI, and log in as the new user ... but the new user has the same problem. This means that the default user account is likely fine and the problem is elsewhere.

I go to the Devices menu in VirtualBox and mount the new Guest Additions. I go back to the command prompt and install these as root. While this step is probably necessary (this is a new version of VirtualBox, afterall), it is insufficient to fix the problem. As the root user, I can run 'startx -- :1' but this presents the same type of problems.

So I reset the machine and think a bit. The VM is setup to auto-login the default user, so I leave X running and go back to the command prompt via <Host>-<F1>. I log in and try running things from the command line:

DISPLAY=unix:0 compiz

Interesting - compiz is crashing with I/O errors and complaining about not being able to access sessions, waiting for dbus to respond, not able to access pixmaps, etc. In short, complete madness. But I can run
DISPLAY=unix:0 gnome-terminal
and, after installing metacity,
DISPLAY=unix:0 metacity --replace

Some searching suggests these compiz errors have been around for a long time and therefore aren't likely to help. However, one post recommends reinstalling ubuntu-desktop. This package is already up to date, but they go on to suggest installing it from the Ubuntu Software Center. This doesn't make much sense but what could it hurt? Suddenly, I find myself strace'ing software-center trying to figure out why it's crashing and, furthermore, why it's complaining about not being able to find icons.

The ugly fix


I try reinstalling the icons it appears to be complaining about but that doesn't work. Eventually, I give up, and decide to just reinstall the entire system. For me, this doesn't mean getting out a CD, however. It means -- (a) print a list of every available package - (b) print the names of the packages that are installed - (c) filter out the packages that contain circular dependencies - and (d) reinstall them live.

apt-get install --reinstall `dpkg -l '*' | awk '/^ii/ { print $2 }' | egrep -v '(mountall|perl-base|libpam-modules|kbd|ntpdate|resolvconf|ifupdown|dpkg|bash|debconf)'`

Somewhere in there, despite some unnecessary exclusions, magic. The best part is that all my settings are retained so I don't need to reconfigure any of my settings.

Kubuntu 13.04 and immediate screen blanking after upgrade

Upgrading from Kubuntu 12.10 to Kubuntu 13.04 is a less-than completely smooth experience. I'll skip any niceties and dig right into the problems.

Screen lock problems


I don't want to spend a lot of time debugging this, but it doesn't even appear possible to shut off the screen blanker so I have to do something. My google-fu is completely overwhelmed by another screenlock bug in KDE 4.10 that appears to lock the screen if you tell it to blank but not lock the screen.

This is not my problem. My problem is that the screen locker appears not to be able to tell time. If I'm idle for more than about 15 seconds, the screen locks. Suffice it to say, this gets annoying really quickly.

The dirty hack


Here's what I've done to fix the issue, and to completely confuse myself the next time the package gets upgraded:

mv /usr/lib/kde4/libexec/kscreenlocker_greet /usr/lib/kde4/libexec/kscreenlocker_greet.old

I welcome real solutions in the comments.

Linux, Ubuntu, INotify - flash and pulseaudio sound stutter

This post was initially drafted on March 6.

Having issues with Linux slowing to a crawl over time? I certainly seemed to have this problem when running Ubuntu 12.10 and KDE (Kubuntu 12.10).

Initial symptom: Audio stutter using flash (e.g: YouTube)


Recently I had problems with Shockwave Flash misbehaving (frozen, stuttered video) in Chrome so I used the task manager (shift-escape, or right click in the tabs area) to kill the plugin and GPU processes. Unfortunately, reloading flash didn't fix the stutter, so I took a step further and killed pulseaudio. Pulseaudio manages access to the audio hardware and because has caused weird effects on my system's performance in the past it was next on the list.

pulseaudio refuses to start


However, trying to restart pulseaudio by typing 'pulseaudio' on the command line kept giving me this error:

E: [pulseaudio] module-udev-detect.c: inotify_init1() failed: Too many open files
E: [pulseaudio] module.c: Failed to load module "module-udev-detect" (argument: ""): initialization failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.

Debugging the error


"Too many open files" is one of those generic and woefully overloaded errors that tends to provide little help in figuring out what's really happening. I checked my file descriptor limits using "ulimit -a" but the number of open files used by chrome was under this limit. In retrospect, this is not helpful information because 'ulimit' is used to set a limit on the number of file descriptors that can be opened by subsequent commands; it does not tell you how many files are currently open whether globally or in that shell. But running "pulseaudio -vvv" didn't provide much more useful detail:

shell$ ulimit -a[...]open files                (-n) 1024
The next tool in the toolbox is 'strace' - running "strace -fff pulseaudio" shows the error at the point that the system call being made:

inotify_init1(O_NONBLOCK|O_CLOEXEC)     = -1 EMFILE (Too many open files)

I checked the manpage for inotify_init1 which describes the error EMFILE as: "The user limit on the total number of inotify instances has been reached". By combining that with some additional searching, it appears that the system limit may be set too low for the number of inotify user instances. I found that my kernel defaults to 128:

shell$ cat /proc/sys/fs/inotify/max_user_instances 
128

Finding and fixing the root cause



root# sysctl -w  fs.inotify.max_user_instances=512 
fs.inotify.max_user_instances = 512 
root# grep inotify /etc/sysctl.conf 
root# vi /etc/sysctl.conf

Once I knew what I was looking for, this was easier to find: