Comment 2 for bug 147216

This seems to be the bug that's most similar to my own experience. In my case, a Feisty box was upgraded to Gutsy (network upgrade about a week ago), using, because I am old-fashioned, apt-get dist-upgrade. Unlike most (any?) of the other reports, I do NOT use LVM for the root partition (which includes /boot; /usr, /var, /tmp, /home and swap are in LVs), so after some poking I discovered that at the time checkfs.sh was being called the volumes, both physical and logical, were known to the LVM system (eg., pvs and lvs showed everything as it should be), but they had no entries in /dev/mapper. Typing just "vgchange -a y" at the shell prompt, then control-D to resume, completed the boot normally (but without ever running fsck, of course).

I'm currently using a modified checkfs.sh, with the vgchange command added to the start) case before do_start, and that seems to workaround the issues for me.

Oh, using the Feisty kernel and initfs never did work for me. It's possible that that initfs had been rebuilt, either during the upgrade or during my early thrashing about, and that that somehow confused it. I was able to get the Gutsy image working largely because I had a completely separate image to boot into.

BTW, I have another machine that had a similar root=/dev/sda#, rest in LVM setup that got a fresh Gutsy install rather than upgrade (it was running Dapper), which has never had the least trouble with LVM. I've spent some time tryign to find the key difference between them, but so far no luck.