Note to self: Missing lvm2 and cryptsetup packages lead to non-working initrd very, very soon

I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).

At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.

I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:

Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).

Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks

After a long frustrating evening of trying to figure out why my laptop wouldn't boot after a Debian upgrade, I finally stumbled on this blog post, and soon had the machine running again. Thanks for posting it.

Hans

Same here

Hi, had the same problem with my Debian, so I changed it to Gentoo, lucky me that I made a full back up before the crash and formatting of my hdd.

energy talk radio

I booted into Ubuntu and did some updates I rebooted into Debian. Horror: fsck failed on root fs, cannot find superblock, read-only mode. I too could not find the superblock. Nice post!

edit of my previous post.

edit of my previous post:

sidux is using the 2.26.32 kernel now, which greatly improves hardware support... and no more xorg.config!

nearly painless Debian unstable.

firstly a big thanks Uwe! info found in the last couple of years on your blog helped me break away from the influence of the Evil Empire for good.

have you ever tried sidux? it's a relatively painless way to use Debian unstable.

keep up the great work Uwe. thanks again. (if we're not paranoid we're not paying attention.)

it's a maintainer fail

http://bugs.debian.org/545032 perhaps? You'll have to thank a specific fellow DM, who seems to think that adding a conflict on a critical package like dmsetup is an acceptable workaround.

Talk Radio

I had shut down Ubuntu while it was doing an fsck on my Debian partition, and this interfered with Debian's own bootup checks and fsck. Odd indeed, linuxes interfereing with one another. Gave me a right fright, that did.

You almost certainly lost

You almost certainly lost those packages during the period in which dmsetup conflicted with devicekit-disks, and GNOME started requiring devicekit-disks. Apt thus removed dmsetup to keep GNOME and devicekit-disks, and removed lvm2 and cryptsetup which depend on dmsetup, and since nothing on your system depended on lvm2 and cryptsetup...

devicekit-disks

Hm, I don't use GNOME per se (just plain icewm) but I guess I have some GNOME libs installed due to some application dependencies. However, I have no "devicekit-disks" package installed right now, so not sure if it's the same issue.

Uwe.

Conflicts

Are you using gnome? Then it was probably due to a conflict between devicekit-disks (a gnome dependency) and dmsetup.

scary when fsck fails

Thanks for relating that horror story, good to be warned. Here's mine, from last night:

I have an AMD64 system with Debian and Ubuntu (and MS Windows Vista), each on a single partition (but different hard drives). The "working" GRUB is the one from the Debian system. After I booted into Ubuntu and did some updates I rebooted into Debian. Horror: fsck failed on root fs, cannot find superblock, read-only mode. I too could not find the superblock. Bah!

Eventually I rebooted into Ubuntu, and was told that drives are being checked. So I notice that fsck is working on the Debian partition (which I mount in Ubuntu to make accessible easily). After fsck completed there, apparently problem-free, I could boot happily into Debian.

I conclude that perhaps I had shut down Ubuntu while it was doing an fsck on my Debian partition, and this interfered with Debian's own bootup checks and fsck. Odd indeed, linuxes interfereing with one another. Gave me a right fright, that did.

Most likely the infamous

Most likely the infamous dmsetup bug (#550434) which caused a lot of pain for users