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. > By the way, I didn't find a /dev/VG/ directory either. No /dev/lovesong/ ? Assuming your VolumeGroup is actually called lovesong. -- Mike Williams -- [EMAIL PROTECTED] mailing list
