boots into busybox with 2.6.28-11-generic kernel.

[Steve Alexander]

I just updated all the packages on my jaunty system to the latest ones, and rebooted my Dell X1. It rebooted into busybox, with a message like:

Boot args (cat /proc/cmd line)
check root delay = (did the system wait long enough ? )
check root = (did the system wait for the right device ? )
Missing Modules ( cat /proc/modules ; ls /dev )
ALERT /dev/disk/by-uuid/(some uuid) does not exist. Dropping to a Shell !

When I reboot and choose the previous kernel, 2.6.28-9-generic, it boots as normal.

So, I think something broke in 2.6.28-11-generic to cause this.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=
MachineType: Dell Inc. Latitude X1
Package: linux-image-2.6.28-9-generic 2.6.28-9.31
ProcCmdLine: root=UUID=9068a157-1b84-48cd-9091-357ae30e7adf ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-9.31-generic
SourcePackage: linux
UnreportableReason: This is not a genuine Ubuntu package

[Steve Langasek (vorlon)]

I believe this is the problem:

Setting up linux-image-2.6.28-11-generic (2.6.28-11.42) ...
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.28-11-generic
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.28-11.40 was configured last, according to dpkg)
[...]
Setting up linux-image-2.6.28-6-386 (2.6.28-6.20) ...
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.28-6-386
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.28-6.17 was configured last, according to dpkg)
[...]
Setting up udev (141-1) ...
 * Stopping kernel event manager... 
[ OK ]
 * Starting kernel event manager... 
[ OK ]
Removing `local diversion of /sbin/udevadm to /sbin/udevadm.upgrade'
update-initramfs: deferring update (trigger activated)
[...]
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.28-6-386

udev was not yet configured when the initrd for the current kernel was generated; then udev was configured, triggering update-initramfs, but update-initramfs picks the wrong kernel to update (2.6.28-6-386 instead of 2.6.28-11-generic).

[Steve Langasek (vorlon)]

Two problems, here:

- when update-initramfs is triggered, it only updates what it perceives to be the "current" initramfs, leaving other initramfses demonstrably broken.
- the "current" initramfs is determined as "the version pointed to by /vmlinuz", and that's going to be the last kernel *installed*, not necessarily the most *recent*, because the kernel-package-based postinst unconditionally claims /vmlinuz on install.

[Stefan Bader (smb)]

Generally, I would think of update-initramfs not touching _all_ kernels rather a feature than a problem. For kernels that have not been touched (as the previous kernel demonstrates) this preserves integrity.
I am not sure I completely understand the upgrade progress here. There seems to be one step of udev being done before the kernel generates the initramfs (adding diverts?). Does this mean between that and the final configuration udev is in an undefined/bad state?
If that is true, maybe the solution could be to create a timestamp at the beginning of an installer run (if that does not already exist). The kernel always runs update-initramfs with the version number, so I assume udev runs it without a specific version and that triggers the default. This default would be changed to initrd files that have been modified since the installer started if the timestamp file is there.
Steve, how does this sound to you?

[Colin Watson (cjwatson)]

Yes, it is slightly odd that the kernel is being configured while udev is only unpacked here, but that isn't the real issue. 'update-initramfs -u' may be called at any time, and it needs to work. (There is no support in the packaging system for anything like your timestamp idea, and I don't think it would work anyway; we need to update initramfses for reasons other than kernel installations.)

I agree that 'update-initramfs -u' should not update all versions of the initramfs that it can find. However, I think it ought to update the newest version of each installed kernel flavour - so it should update 2.6.28-11-generic and 2.6.28-6-386, but not (say) 2.6.28-10-generic and 2.6.28-5-386 if those are also installed.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364029/comments/5 is entirely correct. There should be two tasks open on this bug report:

 * initramfs-tools: 'update-initramfs -u' should update newest versions of all installed flavours
 * linux: postinst should have a more sophisticated notion of whether to claim the /vmlinuz symlink (perhaps needs discussion to get the semantics exactly right)

[dino99 (9d9)]

Can confirm the same thing with Karmic 2.6.31-5-generic kernel.
When booting, i have a useless message: can't find system.map which exist in /boot (googling around, adding rootdelay=40 or + turn that message off), and then i failed in busybox needing to exit to continue the boot process.

[dino99 (9d9)]

this problem is over for me now.
Doesn't exist anymore with karmic beta (31-11-generic) & the latest updates.

[Jeremy Foshee (jeremyfoshee)]

Fix Releasing this as it sounds as if it has been fixed, barring any update from the original reporter.

Thanks!

~Jfo