Debian 64bit get a "Volume vg0 not found" message

Hiya

Im wondering if someone could help share some light or a particular problem im struggling with.

Here where I work, we make use of pxe to boot and install our servers (32 bit), Im now trying to build a 64bit. On boot, after grub, the kernel loads and it leads to a message of

Volume vg0 not found.

And then just defaults to busybox.

I mounted, and chrooted, and from all that I can see ... all looks good (checked /etc/fstab and in grub.cfg I see 'insmod lvm'). I cant see what I may and am missing.

If someone would be so kind as to help and share some pointers it would be appreciated.

Kind Regards
Brent Clark

Hi,

Brent Clark wrote on 20.09.2011 at 10:11:01 [[linux-lvm] Debian 64bit get a "Volume vg0 not found" message]:

what are you passing to the kernel as root= parameter (in grub.cfg)? For me, root=/dev/mapper/vg-lv (replace 'vg' and 'lv' by the corresponding names) works just fine - root=/dev/vg/lv may or may not work just as well. You can experiment with different values at the grub command prompt without changing grub.cfg. What kernel version are you using?

Hope that helps.

Regards,
Holger

Hi,

if we keep this on-list, there's a greater chance of someone with more knowledge of LVM being able to help you (though it really doesn't strike me as an LVM problem - more of an initrd problem involving LVM, though that might be splitting hairs).

Brent Clark wrote on 20.09.2011 at 15:57:15 [Re: [linux-lvm] Debian 64bit get a "Volume vg0 not found" message]:

* The first screenshot shows the tail of a boot attempt, in particular:

Volume group "vg0" not found
Skipping volume group vg0
Unable to find LVM volume vg0/root
Volume group "vg0" not found
Skipping volume group vg0
Unable to find LVM volume vg0/swap
Gave up waiting for root device. Common problems:
[...]
ALERT! /dev/mapper/vg0-root does not exist. Dropping to a shell!

(which then, in fact, happens).

* The second screenshot shows a 'vgdisplay' of vg0 from *a different system* (apparently a live rescue CD or something similar). This is basically meaningless. We know the VG exists. The question is why *the initrd used to boot* doesn't find it. You could try investigating from the initrd shell you end up in.

* The third screenshot shows the grub stanza used for booting, apparently at boot time and displayed by grub.

All of this seems to be happening inside a virtual machine, if I interpret the window decoration in your screen shots correctly. I don't expect that to matter, but I'll mention it for the sake of completeness.

Concerning the third screenshot, I don't think this matter has anything to do with grub. grub's job is to load the kernel and the initrd - apparently it can do so from RAID and LVM devices nowadays. In your case, /boot seems to reside on /dev/md0 (which works for me even without RAID support in grub - it simply reads one of the member devices of my RAID1 array; for other RAID levels, this obviously wouldn't work without special support ;-).

Now it's up to the initrd to set up access to the root device, which could potentially be accessed over NFS, be part of a RAID, or - in your case - LVM VG, or need some special drivers (e.g. SCSI) that are not compiled into the kernel. For some reason, this does not work for you. Actually, I've seen exactly that same problem myself on a Debian etch system with root on LVM, where I tried to install the squeeze kernel (both the etch and lenny kernels find the root LV and mount it). I tried manually updating the initrd. For some reason, this didn't work (or rather, it didn't solve the problem). It wasn't that urgent for me, so I haven't looked into it any further until now, but I'm still interested in a solution, so if somebody has one (or a pointer in the right direction), I'd be grateful, too. Otherwise, I'll investigate once I find some time. I'd also be grateful for corrections of any misconceptions I might have.

One additional data point: a clean squeeze installation with root on LVM works as expected, so [in my case] it's probably the combination of etch userland and squeeze kernel that causes problems, not the squeeze kernel per se.

So, the question remains: which Debian distribution and which kernel are you using? Also, of what PVs does your VG consist? Assuming you are probably using RAID devices there, too, the initrd could potentially activate RAID and LVM in the wrong order or fail to activate RAID at all (it apparently *did* try to activate LVM).

Hope some of that helps.

Regards,
Holger

Thank you so much for you help and replies.

I ended, up taking a initrd.img-2.6.32-5-amd64 from another server and placing it in /boot. And that worked.

But what I dont understand is, in the chroot environment, I restalled the kernel, lvm2 packages, ran mkinitramfs and update-initramfs. Nothing would work.

So ultimately, I still dont have the solution. :)

Thank again
Brent

A chroot doesn't have enough info to reliably run mkinitrd on RedHat. I'm assuming the same is true for Debian and mkinitramfs. Things like volumegroups work fine - the usual problem is device drivers.

Mkinitrd has --with to include specific drivers. For instance,

mkinitrd -v --omit-scsi-modules --with=xenblk --with=xennet initrd-2.6.9-100.ELxenU.img 2.6.9-100.ELxenU

To include xen drivers for a virtual machine or

mkinitrd -v --with=megaraid ...

--

	      Stuart D. Gathman <[email protected]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154

"Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.