Ubuntu 7.04 Alpha 5+ - Updating experiences

I'm writing about how Ubuntu handled an automatic update the week of March 5, 2007. These days the process of keeping your system up to date has evolved considerably so that it is very easy to stay current with fixes and security updates. Essentially your distribution runs a background process with an associated desktop applet that keeps tabs on any updates to your distribution, and alerts you when updates are available. You can then determine if you wish to install them or not. The most important reason for having this feature is security upgrades. Windows in particular has made the importance of this feature quite clear over the years.

Upgrading is not always straight forward. Again, Windows proves the point, most notably with XP SP2. Many IT shops refused to push out SP2 because it broke one or more key internal applications. As an example of this, up until mid-2005, when I still worked for SAIC, SAIC refused to fully install SP2 (although, oddly enough, Lockheed/Martin, to whom SAIC served as a subcontractor on a major program, had no such issues and installed it on all their machines).

Linux distributions have also had upgrade issues along the way. In Ubuntu's case there is the notable failure during an upgrade of xorg.core in Ubuntu 6.06 that broke the X desktop. The disruption was limited in scope and a solution quickly provided. I've not heard or read of anything of that magnitude since. But the ghost of that incident was briefly resurrected last week when I attempted to update a number of packages, three of them related to the X windowing system.

Early last week Update Manager presented 17 new updates, three of them related to X11: x11-common, xorg, and xserver-xorg. These updates were trying to repair the following problem: "revert the "fix" to validate_nice_value, which in fact broke it completely." I was able to install all the packages except those three. When the update manager attempted to update x11-common, the following dialog was displayed.


There was no way to satisfy the dialog. No way to change the value, to move forward. If you canceled the dialog, it resulted in the update being aborted, as shown below. I was never able to install the packages.


Patience, especially in testing, is a virtue. I waited for the solution to be pushed out to the update servers. By Friday the files had been removed, and a new major update was made available (with 149 new updates to existing packages). Fortunately, the update problem was such that the flawed packages would not even install. Regardless, this incident raises in my mind issues of quality control and process. The X subsystem can't be rendered inoperative because of an update mistake, especially for novice users.

All Linux distributions, because they depend upon X, suffer from the same problem; if X fails, there is no other way to correct the problem except from the command line. For seasoned users this is not so much a problem as an aggravation. For novice users or users not used to the command line, this is a real show-stopping problem. I've had similar issues with Suse 10.1 and 10.2, where my dependence on nVidia and ATI video driver kernel modules causes X to crash when the kernel is updated and the video driver module is no longer available on reboot.

I know what to do when this problem occurs, but I said it then and I'll say it now: X needs a fall-back video mode built into the X server that it uses if it fails to successfully boot based on xorg.conf values. Canonical dreams of 'selling' Ubuntu to novice and non-Linux-technically savvy users. Until Ubuntu addresses this issue, it will never be ready for those types of users. Ubuntu needs to be resilient and to degrade, not to be fragile and crash. And in the mean time, folks need to find out what happened (again) with the process producing X updates.