| 1 |
On Sat, 14 Jul 2007 20:00:47 +0100, Mike Williams wrote: |
| 2 |
|
| 3 |
> On Saturday 14 July 2007 18:53:27 Hendrik Boom wrote: |
| 4 |
>> Very interesting. It gets further with the dolvm2 pernel option (I |
| 5 |
>> specified udev first for good measure, as indicated in the howto, and it |
| 6 |
>> got further. However, it still fails to handle |
| 7 |
>> /dev/mapper/lovesong-gentoo properly. fsck complains about it, and I get |
| 8 |
>> to type "shell" for a shell. There I find that |
| 9 |
>> /dev/mapper/lovesong-mapper does not exost (as testified by ls), but that |
| 10 |
>> it is nonetheless mounted on / (as testified by mount). |
| 11 |
> |
| 12 |
> OK, that's not exactly what I expected to happen, but I guess the initrd/ramfs |
| 13 |
> has the same udev setup as the full system so either the udev and |
| 14 |
> the "proper" LVM path could be used. |
| 15 |
> I prefer using the "proper" LVM paths, as early udevs won't create the other |
| 16 |
> nodes and later ones may also not do so (udev is pretty stable now, so I |
| 17 |
> realise it's highly unlikely). |
| 18 |
> |
| 19 |
> udev path == /dev/mapper/VG-LV |
| 20 |
> "proper" LVM path == /dev/VG/LV |
| 21 |
> |
| 22 |
>> This suggests that (a) it was mounted, and (b) something else was mounted |
| 23 |
>> over the path to /dev/mapper/lovesong-mapper afterward. So something is |
| 24 |
>> clearly finding /dev/lovesong/mapper, and then making it inaccessible. |
| 25 |
> |
| 26 |
> a and b, the initrd/ramfs is mounted as / from ram by the kernel after it's |
| 27 |
> booted, the initrd/ramfs does it's stuff, then "pivots" the / device to the |
| 28 |
> real_root device on the kernel command line. |
| 29 |
> The / device you specify in fstab is never actually mounted, as to read it / |
| 30 |
> needs to be mounted, so the kernel or initrd/ramfs does it based on the |
| 31 |
> kernel arguements. |
| 32 |
> As a workaround you can make checkfs not attempt an fsck on the / device. In |
| 33 |
> fstab set the final column on the / entry to 0, it's almost certainly 1. This |
| 34 |
> number defines the order in which devices are fsck'd, 0 means don't do |
| 35 |
> anything. |
| 36 |
|
| 37 |
As another workaround I could just continue using Debian etch. I probably |
| 38 |
have the time to get it fixed right. |
| 39 |
|
| 40 |
> |
| 41 |
>> By the way, I didn't find a /dev/VG/ directory either. |
| 42 |
> |
| 43 |
> No /dev/lovesong/ ? Assuming your VolumeGroup is actually called |
| 44 |
> lovesong. |
| 45 |
|
| 46 |
Yes, there is a /dev/lovesong, on both Debian and gentoo, and even a |
| 47 |
/dev/lovesong/gentoo! (confusion existed because I once installed a |
| 48 |
Debian system that actually called its newly created volume group "VG".) So |
| 49 |
I have changed all references to /dev/mapper/lovesong-gentoo in the |
| 50 |
menu.lst so they say /dev/lovesong/gentoo. I *still* get fsck complaining |
| 51 |
about /dev/mapper/lovesong-gentoo, which still does not exits. |
| 52 |
Where is it getting that name? |
| 53 |
|
| 54 |
(thinks) |
| 55 |
|
| 56 |
AH! From gentoo's /etc/fstab! Will fix and report back. |
| 57 |
|
| 58 |
-- hendrik |
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-user@g.o mailing list |
Archives