Bug 340837

There seems not to be enough sanity checking, and error handling in YOU kernel update, this update ran without comment (text mode YaST->Online Update), appearing to complete successfully).

The /boot partion was unmounted, so there was a /boot directory but it was empty without any kernel, initrd, map files nor a boot loader (grub); so parts of the update script must have received runtime errors.

To reproduce :

1) Make /boot an empty directory, for instance unmounting a /boot partition, though probably mount --bind /some/empty/dir /bind would do the job.

2) Update new kernel with YOU, "forgetting" to make real /boot accessible.

I noticed no error messages, nor any warning indication from YaST YOU of an issue or problem.

New kernel files in /boot contained in root partion, were present.  The running kernel module files were deleted!

Module for ext2 partion therefore unloadable making /boot unmountable, booting to Rescue CD was therefore necessary.

Off Live CD, it was possible to mount / & /boot, and copy in new kernel files, then update /boot/grub/menu.lst.


Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb5               489900    186616    303284  39% /

Deleting /lib/module/`uname -r` and the old kernel entries, before successfully rebooting when there is plenty of disk space, seems rather aggressive and fragile.  That also means that installing a kernel update accidentally, forces a reboot of system, in order to load modules for features not yet used since boot.


A good precaution would be to allow the Adminstrator to nominate a fallback 'trusted' kernel, with entry in boot menu that is never removed, so that kernel upgrade cannot leave system unbootable.

The update should be a transaction, that only completes if all steps to install   
new kernel succeeded, including boot menu changes.

Safer to only delete files from previous kernel, after a successful boot, or even leave this as a task to be done by weekly maintenance script.  Unused kernel files could then be deleted after a month or so, and each boot of kernel-`uname -r` recorded by boot script using touch <path>/lastboot/kernel-`uname-r`

Kernel installation is a critical task, which should be done very carefully, and procedure ought be conservative.  The auto update mechanism loses value if the Admin cannot trust it to be careful.

Greater robustness would also protect SuSE's name in event of a troublesome kernel update, causing unforeseen problems at very many sites.