[gentoo-user] Re: Installation problems

[Hendrik Boom]

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

-- 
gentoo-user@g.o mailing list