On Sun, 15 Jul 2007 19:37:57 +0000, Hendrik Boom wrote: > On Sat, 14 Jul 2007 20:00:47 +0100, Mike Williams wrote: > >> On Saturday 14 July 2007 18:53:27 Hendrik Boom wrote: >>> Very interesting. It gets further with the dolvm2 pernel option (I >>> specified udev first for good measure, as indicated in the howto, and it >>> got further. However, it still fails to handle >>> /dev/mapper/lovesong-gentoo properly. fsck complains about it, and I get >>> to type "shell" for a shell. There I find that >>> /dev/mapper/lovesong-mapper does not exost (as testified by ls), but that >>> it is nonetheless mounted on / (as testified by mount). >> >> OK, that's not exactly what I expected to happen, but I guess the >> initrd/ramfs >> has the same udev setup as the full system so either the udev and >> the "proper" LVM path could be used. >> I prefer using the "proper" LVM paths, as early udevs won't create the other >> nodes and later ones may also not do so (udev is pretty stable now, so I >> realise it's highly unlikely). >> >> udev path == /dev/mapper/VG-LV >> "proper" LVM path == /dev/VG/LV >> >>> This suggests that (a) it was mounted, and (b) something else was mounted >>> over the path to /dev/mapper/lovesong-mapper afterward. So something is >>> clearly finding /dev/lovesong/mapper, and then making it inaccessible. >> >> a and b, the initrd/ramfs is mounted as / from ram by the kernel after it's >> booted, the initrd/ramfs does it's stuff, then "pivots" the / device to the >> real_root device on the kernel command line. >> The / device you specify in fstab is never actually mounted, as to read it / >> needs to be mounted, so the kernel or initrd/ramfs does it based on the >> kernel arguements. >> As a workaround you can make checkfs not attempt an fsck on the / device. In >> fstab set the final column on the / entry to 0, it's almost certainly 1. >> This >> number defines the order in which devices are fsck'd, 0 means don't do >> anything. > > As another workaround I could just continue using Debian etch. I probably > have the time to get it fixed right. > >> >>> By the way, I didn't find a /dev/VG/ directory either. >> >> No /dev/lovesong/ ? Assuming your VolumeGroup is actually called >> lovesong. > > Yes, there is a /dev/lovesong, on both Debian and gentoo, and even a > /dev/lovesong/gentoo! (confusion existed because I once installed a > Debian system that actually called its newly created volume group "VG".) So > I have changed all references to /dev/mapper/lovesong-gentoo in the > menu.lst so they say /dev/lovesong/gentoo. I *still* get fsck complaining > about /dev/mapper/lovesong-gentoo, which still does not exits. > Where is it getting that name? > > (thinks) > > AH! From gentoo's /etc/fstab! Will fix and report back.
Fixed /etc/fstab so that it now refers to /dev/lovesong/gentoo. And fstab gets the message, because it now complains that there's no /dev/lovesong/gentoo. And when I get a shell, I discover that it's right. There is now no /etc/lovesong at all. /dev/mapper exists, but it contains only /dev/mapper/control. using your workaround of changing the pass from 1 to 0 in the /etc/fstab file, it boots. But I still have no access to the other partitions on the disk. I still have no /dev/lovesong. except of course that /dev/lovesong/gentoo has been mounted. And /dev/mapper still contains only /dev/mapper/control. -- hendrik -- [EMAIL PROTECTED] mailing list
