It never rains but it pours.
Just about the next thing to do after installing an Ubuntu distro is to let the automatic update process run. The Update Manager reads the files available in the on-line repositories, scans the local system, and sorts out which files need to be updated. It displays a list of the changes to be made, asks for authorization, then downloads and installs all the updates for both the operating system and the applications currently in use.
The update process kicks in on an as-and-when-required basis, i.e. when new files are available. But it’s almost certain to want to run after installing a new Ubuntu release. The files contained in the distro will probably have been committed to the package some time ago, and so new versions of some of the files are quite likely to be available.
So it came as no surprise that Update Manager offered a huge batch of file upgrades. As usual, I authorized the updates and let the manager take care of business. The final task was to restart the machine, a not uncommon requirement when a large batch of updates is provided. However, what did come as a surprise was the failure of the machine to reboot – with the accompanying error message – “udevadm trigger is not permitted while udev is unconfigured”.
Not having seen this error previously, an action plan was needed to recover the system. With such a specific error, the simplest procedure was to just enter the whole text string into a Google search box and see what advice was available on the web.
Sure enough, a fix was found at: http://ubuntuforums.org/showthread.php?t=1567147 giving the following sequence of steps:
|1. Boot LiveCD
2. sudo fdisk -l to find your boot disk [for my Ubuntu 10.04 it was /dev/sda7]
3. sudo mkdir /media/newroot
4. sudo mount /dev/sda7 /media/newroot
5. sudo chroot /media/newroot
6. sudo update-initramfs -u -k 2.6.32-24-generic
The final command produces a number of error messages. However, the string of posts in the above-noted link indicated that these can be ignored. And, indeed, the fix worked like a charm. Once the above steps had been performed, the machine booted normally.
While this once again shows the power of the Internet in providing specific solutions to problems that are encountered, it is also instructive to examine the posts to try to isolate the nature of the underlying problem. One clue is in the phrase: “The idea is, there is a special ram-based file system used during the bootup process (ramfs) that is a special image attached to the kernel. If it’s not created properly, this error occurs.”
Clearly, therefore, the real magic in the solution is in the last command, Step 6 in the sequence: update-initramfs. An explanation of the syntax of this command can be found at: http://man.he.net/man8/update-initramfs. In particular, option u causes an update to be generated for the initramfs that is associated with the kernel version specified by option k. Or, in short, the update fixed the problem!
So, we are two steps along the road to using Ubuntu 10.04 in a production environment, and have encountered two fairly major problems to date. What can happen next? Stay tuned!