09:22 am, 6 Oct 05
ubuntu boot failure -- unable to find volume group
A recent kernel upgrade on my desktop caused it to stop booting. Kernel package 2.6.10-5-686-smp worked, but 2.6.12-6-686-smp didn't. Right after I chose the kernel with GRUB I'd get:
And then I'd be dropped to a Busybox shell.
Lots of looking around on Google produced nothing. Some people had similar problems but they all came back to lilo, and I wasn't using lilo. I finally subscribed to the ubuntu-users mailing list and sent out my info, and this morning I was given the pointer that lead to fixing it.
Unfortunately I'm not quite sure exactly what fixed it, but I think I have enough that anyone else who encounters this will be able to retrace my steps.
It appears that the problem was the newer kernel's initrd was missing some crucial module.
The two changes I made were:
It's been so long since I messed with any of this stuff that I'm hazy on how it works. This makes me sorta happy, really -- I ought not to need to know. Though it makes me even happier that I still have the opportunity to be able to fix it.
Unable to find volume group "hda2"
ALERT! /dev/hda2 does not existAnd then I'd be dropped to a Busybox shell.
Lots of looking around on Google produced nothing. Some people had similar problems but they all came back to lilo, and I wasn't using lilo. I finally subscribed to the ubuntu-users mailing list and sent out my info, and this morning I was given the pointer that lead to fixing it.
Unfortunately I'm not quite sure exactly what fixed it, but I think I have enough that anyone else who encounters this will be able to retrace my steps.
It appears that the problem was the newer kernel's initrd was missing some crucial module.
/etc/mkinitrd/mkinitrd.conf says MODULES=most but I'm not sure where that list is defined, but if you run mkinitrd with the -k it leaves its temporary files around you can see the modules.most file it left behind.The two changes I made were:
- Adding
reiserfsto/etc/mkinitrd/modules - Copying
reiserfs.koandatiixp.ko(gimme a break, I was just guessing) to/lib/modules/2.6.12-9-686-smp/initrd
initrd properly -- the problem was that you have to use an absolute path for the output file when you run mkinitrd, like this: mkinitrd -o /boot/initrd.img-2.6.12-9-686-smp 2.6.12-9-686-smp .It's been so long since I messed with any of this stuff that I'm hazy on how it works. This makes me sorta happy, really -- I ought not to need to know. Though it makes me even happier that I still have the opportunity to be able to fix it.
the kind of comment jwz hates.
The purpose of initrd's seems even more ridiculous these days, with few limits on the size of the kernel, no downside to having a large kernel, and drivers that don't crash things with probing. And initrd's have only gotten more complicated. (And it takes, what, 45 seconds to recompile an entire kernel now?)The only case that ever made sense was getting rid of ipautoconfig (the DHCP/BOOTP implementation in the kernel) for nfsroot, and replacing it with an initrd that has dhclient, but everyone that's ever used ipautoconfig protested about its removal, because initrd's are a pain in the ass and ipautoconfig is totally easy.
So, I don't get it.
Re: the kind of comment jwz hates.
You can end up in screwed up situations where you need access to tools in your filesystem to bootstrap your real filesystem (let's say you want to put your root partition in a logical volume using lvm). To activate the "real" root partition, you need the lvm tools, but to get the tools, you need root mounted, thus you need an initrd to hold them temporarily. There might be another way to do it, but that's the only one I know of.Now why you'd want to do such a thing, I don't know...