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)...
The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:
This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.
Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.
This should make for an interesting summer with nice improvements for coreboot.