Skip to contentSkip to conversation

mount root filesystem on lvm

linux-lvm Manfred Gschweidl 2 participants 13 messages May 9, 2003 – May 12, 2003

lore
Share & tools
lore
#0 lore raw

hello again,

now i solved the problems with "/dev/mapper/control".

it seems, that the kernel now finds all volumegroups, but now i get a kernel panic, that the kernel cannot mount my root filesystem within the lvm volumes. the message says, that i should append the correct "root=" boot option on startup??

with kernel 2.4.12 and lvm 1.x it was "/dev/progs/root". now i use kernel 2.4.20 with device-mapper and lvm2. as with kernel 2.4.12 i use a inital ramdisk.

how can i find out, what now is the correct option for "root="??

thanks for any help again.

manfred

#1 lore raw

hello once again,

i used the ls command within the "linuxrc" script of the initial ramdisk. "ls /dev/mapper/control" results only with "/dev/mapper/control"

"ls /dev/mapper results in following output:
control
...
progs-root
...

so i used "root=/dev/mapper/progs-root" as boot option, but i can still not mount the root filesystem.

was anyone successfull with booting the root-filesystem on am lvm-volume with lvm2 and device-mapper interface, using an initial ramdisk??

can anyone point me in the right direction??

thanks for any help in advance.

greetings from austria,

manfred

Quoted 28 lines · Manfred Gschweidl

hello again,

now i solved the problems with "/dev/mapper/control".

it seems, that the kernel now finds all volumegroups, but now i get a kernel panic, that the kernel cannot mount my root filesystem within the lvm volumes. the message says, that i should append the correct "root=" boot option on startup??

with kernel 2.4.12 and lvm 1.x it was "/dev/progs/root". now i use kernel 2.4.20 with device-mapper and lvm2. as with kernel 2.4.12 i use a inital ramdisk.

how can i find out, what now is the correct option for "root="??

thanks for any help again.

manfred

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

#2 lore raw

Am Fre, 2003-05-09 um 21.19 schrieb Manfred Gschweidl:

Quoted 4 lines

was anyone successfull with booting the root-filesystem on am lvm-volume with lvm2 and device-mapper interface, using an initial ramdisk??

can anyone point me in the right direction??

I built my own ramdisk for that purpose (loosely based on the old LVM1 ramdisk). It's contains the following files:

-rwxr-xr-x  1 root root  442740 Dec 13 00:48 bin/bash
-rwxr-xr-x  1 root root   17196 Nov  7  2002 bin/mknod
-rwsr-xr-x  1 root root   60896 Jan 20  2002 bin/mount
-rwxr-xr-x  1 root root   46692 Nov  7  2002 bin/sed
-rwxr-xr-x  1 root root    4948 Dec 25 18:02 bin/true
-rwsr-xr-x  1 root root   27524 Jan 20  2002 bin/umount
-rw-r--r--  1 root root      66 Jan 11 17:17 etc/fstab
-rw-r--r--  1 root root   16932 Dec 12 23:36 etc/modprobe.conf
-rw-r--r--  1 root root      24 Jan 11 17:17 etc/mtab
-rwxr-xr-x  1 root root   91790 Nov  7  2002 lib/ld-linux.so.2
-rwxr-xr-x  1 root root 1193240 Nov  7  2002 lib/libc.so.6
-rwxr-xr-x  1 root root   17300 Nov  7  2002 lib/libdevmapper.so.0.96
-rwxr-xr-x  1 root root    9140 Nov  7  2002 lib/libdl.so.2
-rwxr-xr-x  1 root root   23256 Dec 12 23:56 lib/libhistory.so.4
-rwxr-xr-x  1 root root  289484 Jan 20  2002 lib/libncurses.so.5
-rwxr-xr-x  1 root root  156144 Dec 13 00:39 lib/libreadline.so.4
-r-xr-xr-x  1 root root     433 Dec 25 18:24 linuxrc
-rwxr-xr-x  1 root root    5876 Jan 11 17:15 sbin/insmod
-r-xr-xr-x  1 root root  329956 Jan 11 17:13 sbin/lvm
-rwxr-xr-x  1 root root   18556 Jan 11 17:15 sbin/modprobe

Note: I'm using kernel 2.5.69, so instead of modprobe.conf you should use modules.conf, the only purpose of this file in conjunction with modprobe is to suppress a lot of kernel messages that say it couldn't load the module for major blabla). The shared libraries were used by my bash, you can check that with ldd.

The shell script /linuxrc looks like this (note: I removed the indentation to fit everything into one line, you might want to correct this):

#!/bin/sh
/bin/mount /proc
echo /sbin/modprobe > /proc/sys/kernel/modprobe
if test ! -e /dev/.devfsd ; then
set -e
MAJOR=$(/bin/sed -n 's/^ *\([0-9]\+\) \+misc$/\1/p' /proc/devices) MINOR=$(/bin/sed -n 's/^ *\([0-9]\+\) \+device-mapper$/\1/p' /proc/misc) if test -n "$MAJOR" -a -n "$MINOR" ; then

    /bin/mknod --mode=600 /dev/mapper/control c $MAJOR $MINOR

fi
fi
/sbin/lvm vgchange --ignorelockingfailure -a y
/bin/umount /proc

The other text files contain this:

chtephan:/mnt/tmp # cat etc/mtab
/dev/ram0 / ext2 rw 0 0
chtephan:/mnt/tmp # cat etc/fstab

/dev/ram0       /               ext2    defaults        0   0
proc            /proc           proc    defaults        0   0

You can also find this ramdisk under
http://www.saout.de/misc/initrd-2.5.67-lvm2-athlon.gz - as the name suggets my libc is athlon optimized, so you might want to replace some libraries or executables.

BTW: I've also got some lilo patches on that page (remove the filename after the last slash) that make it recognize device-mapper volumes.

Signature · 1 line
Christophe Saout <[email protected]>
#3 lore raw

hello,

thanks for your response. ;-)

i have one more question: what does your "lilo.conf" look like???
especially the "root=...." parameter ist he most interesting one. how does it need to be named with device-mapper???

thanks for any reply again,

manfred

Quoted 72 lines · Christophe Saout

Am Fre, 2003-05-09 um 21.19 schrieb Manfred Gschweidl:

Quoted 3 lines

was anyone successfull with booting the root-filesystem on am lvm-volume with lvm2 and device-mapper interface, using an initial ramdisk??

can anyone point me in the right direction??

I built my own ramdisk for that purpose (loosely based on the old LVM1 ramdisk). It's contains the following files:

(quoted diff) +0 -20
-rwxr-xr-x  1 root root  442740 Dec 13 00:48 bin/bash
-rwxr-xr-x  1 root root   17196 Nov  7  2002 bin/mknod
-rwsr-xr-x  1 root root   60896 Jan 20  2002 bin/mount
-rwxr-xr-x  1 root root   46692 Nov  7  2002 bin/sed
-rwxr-xr-x  1 root root    4948 Dec 25 18:02 bin/true
-rwsr-xr-x  1 root root   27524 Jan 20  2002 bin/umount
-rw-r--r--  1 root root      66 Jan 11 17:17 etc/fstab
-rw-r--r--  1 root root   16932 Dec 12 23:36 etc/modprobe.conf
-rw-r--r--  1 root root      24 Jan 11 17:17 etc/mtab
-rwxr-xr-x  1 root root   91790 Nov  7  2002 lib/ld-linux.so.2
-rwxr-xr-x  1 root root 1193240 Nov  7  2002 lib/libc.so.6
-rwxr-xr-x  1 root root   17300 Nov  7  2002 lib/libdevmapper.so.0.96
-rwxr-xr-x  1 root root    9140 Nov  7  2002 lib/libdl.so.2
-rwxr-xr-x  1 root root   23256 Dec 12 23:56 lib/libhistory.so.4
-rwxr-xr-x  1 root root  289484 Jan 20  2002 lib/libncurses.so.5
-rwxr-xr-x  1 root root  156144 Dec 13 00:39 lib/libreadline.so.4
-r-xr-xr-x  1 root root     433 Dec 25 18:24 linuxrc
-rwxr-xr-x  1 root root    5876 Jan 11 17:15 sbin/insmod
-r-xr-xr-x  1 root root  329956 Jan 11 17:13 sbin/lvm
-rwxr-xr-x  1 root root   18556 Jan 11 17:15 sbin/modprobe

Note: I'm using kernel 2.5.69, so instead of modprobe.conf you should use modules.conf, the only purpose of this file in conjunction with modprobe is to suppress a lot of kernel messages that say it couldn't load the module for major blabla). The shared libraries were used by my bash, you can check that with ldd.

The shell script /linuxrc looks like this (note: I removed the indentation to fit everything into one line, you might want to correct this):

#!/bin/sh
/bin/mount /proc
echo /sbin/modprobe > /proc/sys/kernel/modprobe
if test ! -e /dev/.devfsd ; then
set -e
MAJOR=$(/bin/sed -n 's/^ *\([0-9]\+\) \+misc$/\1/p' /proc/devices) MINOR=$(/bin/sed -n 's/^ *\([0-9]\+\) \+device-mapper$/\1/p' /proc/misc) if test -n "$MAJOR" -a -n "$MINOR" ; then

    /bin/mknod --mode=600 /dev/mapper/control c $MAJOR $MINOR

fi
fi
/sbin/lvm vgchange --ignorelockingfailure -a y
/bin/umount /proc

The other text files contain this:

chtephan:/mnt/tmp # cat etc/mtab
/dev/ram0 / ext2 rw 0 0
chtephan:/mnt/tmp # cat etc/fstab

/dev/ram0       /               ext2    defaults        0   0
proc            /proc           proc    defaults        0   0

You can also find this ramdisk under
http://www.saout.de/misc/initrd-2.5.67-lvm2-athlon.gz - as the name suggets my libc is athlon optimized, so you might want to replace some libraries or executables.

BTW: I've also got some lilo patches on that page (remove the filename after the last slash) that make it recognize device-mapper volumes.

#4 lore raw

Am Sam, 2003-05-10 um 18.02 schrieb Manfred Gschweidl:

Quoted 3 lines

i have one more question: what does your "lilo.conf" look like??? especially the "root=...." parameter ist he most interesting one. how does it need to be named with device-mapper???

It looks fairly simple:

boot = /dev/hda
vga = normal
read-only
lba32
prompt
timeout = 30
message = /boot/message

image = /boot/vmlinuz
label = linux
root = /dev/mapper/vg-root
initrd = /boot/initrd

But I think you can also use /dev/vg/root (in my case). I think lilo only uses this line to look up the device number (major, minor).

What's your problem?

Signature · 1 line
Christophe Saout <[email protected]>
#5 lore raw

the kernel always complaines, that he cannot mount the root fs...

when i use "/dev/progs/root" boot up ends with:
VFS: Cannot open root device "3a00" or 3a:00
Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 3a:00

when i use "/dev/mapper/progs-root" boot up ends with:
VFS: Cannot open root device "mapper/progs-root" or 00:00 Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 00:00

i use the append option for "/dev/mapper/progs-root", because i can't run lilo with it, because lilo says, that it doesn't find the device....

i want to upgrade from 2.4.12 LVM1 to 2.4.20 LVM2.... booting with 2.4.12 and LVM1 works now for nearly 2 years.

thanks again,

manfred

Quoted 27 lines · Christophe Saout

Am Sam, 2003-05-10 um 18.02 schrieb Manfred Gschweidl:

Quoted 2 lines

i have one more question: what does your "lilo.conf" look like???
especially the "root=...." parameter ist he most interesting one. how does it need to be named with device-mapper???

It looks fairly simple:

boot = /dev/hda
vga = normal
read-only
lba32
prompt
timeout = 30
message = /boot/message

image = /boot/vmlinuz
label = linux
root = /dev/mapper/vg-root
initrd = /boot/initrd

But I think you can also use /dev/vg/root (in my case). I think lilo only uses this line to look up the device number (major, minor).

What's your problem?

#6 lore raw

Am Son, 2003-05-11 um 04.05 schrieb Manfred Gschweidl:

Quoted 4 lines

when i use "/dev/progs/root" boot up ends with:
VFS: Cannot open root device "3a00" or 3a:00
Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 3a:00

0x3a is the LVM1 device major.

Quoted 4 lines

when i use "/dev/mapper/progs-root" boot up ends with:
VFS: Cannot open root device "mapper/progs-root" or 00:00 Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 00:00

Ok, 00:00 means that he didn't find anything there.

Quoted 2 lines

i use the append option for "/dev/mapper/progs-root", because i can't run lilo with it, because lilo says, that it doesn't find the device....

Yep.

It looks like you are currently running on LVM1 but want to switch to LVM2 after the next reboot, right?

LILO can only look at the device numbers currently in use in /dev, but when there is no device-mapper device there, he can't find the device number to use with LVM2.

I don't think you can't activate a volume group at the same time with LVM1 and LVM2, so you'll have to give it explicitly to the kernel "command line" on the next reboot.

Before reboot, can you find out what major device-mapper uses? Type "cat /proc/devices" and search for the line with device-mapper. My kernel is currently using the major 254, but I don't know if the numbers are allocated the same way with the 2.4 kernel.

Ok, then you'll have to translate the number to hexdecimal (e.g. using this command line where you should replace 254 with your major number if it differs: perl -e 'printf "%02x\n", 254).

After rebooting you interrupt lilo and append root=##00 to the command line, where ## is the major number in hex (so it looks like "linux root=fe00"). If he doesn't find the root device, try fe01, fe02, etc... until he finds the root device. The problem is that you can't know exactly which minor number the kernel number will assign the volume without having tested it first.

This should of course only work when the ramdisk has correctly activated the volume before the kernel tries to mount the root filesystem, there should be a message printed.

Signature · 1 line
Christophe Saout <[email protected]>
#7 lore raw

hello and thanks for your help.

i modified my linuxrc file on the ramdisk, so that it does a "cat /proc/devices" and "ls -l /dev/mapper". so i found out, that the device number is also 254 and with the ls-comand i get the information that the minor number was 6 (with the 2.4.12 kernel i couldn't find ot out, because there i was not using the device-mapper interface).

after appending this to the new kernel on startup, the root filesystem can now be found, and the system boots.

but now i have an problem... ;-)

when booting up with the initial ramdisk, and doing a "lvm vgscan" and "lvm vgchange -a y", all volume groups and logical volumes are found ("ls /dev/mapper" on the end of the linuxrc script shows all found logical volumes). but after freeing memory of the initial ramdisk and mounting of the root fs, now one of the entries in "/dev/mapper" exists, except the "control" entry. and "lvm vgscan" and "lvm vgchange -a y" does not help. so i cannot mount any other logical volumes????? the kernel complaines, that maybe a old kernel driver is using the volume groups, but how can that be???

cat /proc/devices show up, that there is still an entry for lvm, but also for device-mappper. is this maybe the error???

if you can't help me out with this, this is no problem, because you helped me a lot, since i can boot now...;-) but the "/usr", "/var".... directories are also residing on lvm volumes...

thanks for your detailed help,

manfred

Quoted 57 lines · Christophe Saout

Am Son, 2003-05-11 um 04.05 schrieb Manfred Gschweidl:

Quoted 4 lines

when i use "/dev/progs/root" boot up ends with:
VFS: Cannot open root device "3a00" or 3a:00
Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 3a:00

0x3a is the LVM1 device major.

Quoted 4 lines

when i use "/dev/mapper/progs-root" boot up ends with:
VFS: Cannot open root device "mapper/progs-root" or 00:00 Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 00:00

Ok, 00:00 means that he didn't find anything there.

Quoted 1 line

i use the append option for "/dev/mapper/progs-root", because i can't run lilo with it, because lilo says, that it doesn't find the device....

Yep.

It looks like you are currently running on LVM1 but want to switch to LVM2 after the next reboot, right?

LILO can only look at the device numbers currently in use in /dev, but when there is no device-mapper device there, he can't find the device number to use with LVM2.

I don't think you can't activate a volume group at the same time with LVM1 and LVM2, so you'll have to give it explicitly to the kernel "command line" on the next reboot.

Before reboot, can you find out what major device-mapper uses? Type "cat /proc/devices" and search for the line with device-mapper. My kernel is currently using the major 254, but I don't know if the numbers are allocated the same way with the 2.4 kernel.

Ok, then you'll have to translate the number to hexdecimal (e.g. using this command line where you should replace 254 with your major number if it differs: perl -e 'printf "%02x\n", 254).

After rebooting you interrupt lilo and append root=##00 to the command line, where ## is the major number in hex (so it looks like "linux root=fe00"). If he doesn't find the root device, try fe01, fe02, etc... until he finds the root device. The problem is that you can't know exactly which minor number the kernel number will assign the volume without having tested it first.

This should of course only work when the ramdisk has correctly activated the volume before the kernel tries to mount the root filesystem, there should be a message printed.

#8 lore raw

hello again,

when i do a vgscan, i always get some messages like ...

SystemID universe1010067245 on /dev/md11 differs from universe1010064286 for volume group

can anyone explain me, what this message means??? it seems that for all physical volumes, for which i get this message, the volume group, in which the pyhisical volume resides, cannot be activated.

thanks for any explanation in advance,

manfred

Quoted 100 lines · Manfred Gschweidl

hello and thanks for your help.

i modified my linuxrc file on the ramdisk, so that it does a "cat /proc/devices" and "ls -l /dev/mapper". so i found out, that the device number is also 254 and with the ls-comand i get the information that the minor number was 6 (with the 2.4.12 kernel i couldn't find ot out, because there i was not using the device-mapper interface).

after appending this to the new kernel on startup, the root filesystem can now be found, and the system boots.

but now i have an problem... ;-)

when booting up with the initial ramdisk, and doing a "lvm vgscan" and "lvm vgchange -a y", all volume groups and logical volumes are found ("ls /dev/mapper" on the end of the linuxrc script shows all found logical volumes). but after freeing memory of the initial ramdisk and mounting of the root fs, now one of the entries in "/dev/mapper" exists, except the "control" entry. and "lvm vgscan" and "lvm vgchange -a y" does not help. so i cannot mount any other logical volumes????? the kernel complaines, that maybe a old kernel driver is using the volume groups, but how can that be???

cat /proc/devices show up, that there is still an entry for lvm, but also for device-mappper. is this maybe the error???

if you can't help me out with this, this is no problem, because you helped me a lot, since i can boot now...;-) but the "/usr", "/var".... directories are also residing on lvm volumes...

thanks for your detailed help,

manfred

Quoted 56 lines · Christophe Saout

Am Son, 2003-05-11 um 04.05 schrieb Manfred Gschweidl:

Quoted 4 lines

when i use "/dev/progs/root" boot up ends with:
VFS: Cannot open root device "3a00" or 3a:00
Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 3a:00

0x3a is the LVM1 device major.

Quoted 4 lines

when i use "/dev/mapper/progs-root" boot up ends with:
VFS: Cannot open root device "mapper/progs-root" or 00:00 Please append s correct "root=" boot option

Kernel panic: VFS: Unable to mount root fs on 00:00

Ok, 00:00 means that he didn't find anything there.

Quoted 1 line

i use the append option for "/dev/mapper/progs-root", because i can't run lilo with it, because lilo says, that it doesn't find the device....

Yep.

It looks like you are currently running on LVM1 but want to switch to LVM2 after the next reboot, right?

LILO can only look at the device numbers currently in use in /dev, but when there is no device-mapper device there, he can't find the device number to use with LVM2.

I don't think you can't activate a volume group at the same time with LVM1 and LVM2, so you'll have to give it explicitly to the kernel "command line" on the next reboot.

Before reboot, can you find out what major device-mapper uses? Type "cat /proc/devices" and search for the line with device-mapper. My kernel is currently using the major 254, but I don't know if the numbers are allocated the same way with the 2.4 kernel.

Ok, then you'll have to translate the number to hexdecimal (e.g. using this command line where you should replace 254 with your major number if it differs: perl -e 'printf "%02x\n", 254).

After rebooting you interrupt lilo and append root=##00 to the command line, where ## is the major number in hex (so it looks like "linux root=fe00"). If he doesn't find the root device, try fe01, fe02, etc... until he finds the root device. The problem is that you can't know exactly which minor number the kernel number will assign the volume without having tested it first.

Quoted 4 lines

This should of course only work when the ramdisk has correctly activated the volume before the kernel tries to mount the root filesystem, there should be a message printed.

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

#9 lore raw
In reply to Manfred Gschweidl

Am Son, 2003-05-11 um 20.00 schrieb Manfred Gschweidl:

Quoted 12 lines

but now i have an problem... ;-)

when booting up with the initial ramdisk, and doing a "lvm vgscan" and "lvm vgchange -a y", all volume groups and logical volumes are found ("ls /dev/mapper" on the end of the linuxrc script shows all found logical volumes).
but after freeing memory of the initial ramdisk and mounting of the root fs, now one of the entries in "/dev/mapper" exists, except the "control" entry. and "lvm vgscan" and "lvm vgchange -a y" does not help. so i cannot mount any other logical volumes?????
the kernel complaines, that maybe a old kernel driver is using the volume groups, but how can that be???

When nobody created the /dev/control/mapper device on your root file system, it simply isn't there. ;-)

If you create it once it will stay there. "mknod /dev/mapper/control c 10 63" (or whatever the minor is, see cat /proc/misc)

My linuxrc script creates this dynamically in the ramdisk based on /proc, but later you'll also need it on the root filesystem. Usually it is not necessary to do it on every reboot, because the filesystems isn't deleted between reboots, so creating it once should do it. You also shouldn't need to run a vgscan in the boot scripts because the known volume groups are cached in /etc between reboots, you can run it manually if something changes. Creating /dev/mapper/control once and adding vgchange -a y to the init scripts is ok.

Quoted 2 lines

cat /proc/devices show up, that there is still an entry for lvm, but also for device-mappper. is this maybe the error???

No, I think they should coexist nicely.

Signature · 1 line
Christophe Saout <[email protected]>
#10 lore raw
Quoted 5 lines · Christophe Saout

Am Son, 2003-05-11 um 20.00 schrieb Manfred Gschweidl:

Quoted 2 lines

but now i have an problem... ;-)

Quoted 8 lines
Quoted 3 lines

when booting up with the initial ramdisk, and doing a "lvm vgscan" and "lvm vgchange -a y", all volume groups and logical volumes are found ("ls /dev/mapper" on the end of the linuxrc script shows all found logical volumes). but after freeing memory of the initial ramdisk and mounting of the root fs, now one of the entries in "/dev/mapper" exists, except the "control" entry. and "lvm vgscan" and "lvm vgchange -a y" does not help. so i cannot mount any other logical volumes????? the kernel complaines, that maybe a old kernel driver is using the volume groups, but how can that be???

When nobody created the /dev/control/mapper device on your root file system, it simply isn't there. ;-)

uupps...sorry, maybe i should carefully read my mails, after writing them. ;-) i mean only one entry exists in "/dev/mapper", and this is "control", but no other entry.

Quoted 13 lines

If you create it once it will stay there. "mknod /dev/mapper/control c 10 63" (or whatever the minor is, see cat /proc/misc)

My linuxrc script creates this dynamically in the ramdisk based on /proc, but later you'll also need it on the root filesystem. Usually it is not necessary to do it on every reboot, because the filesystems isn't deleted between reboots, so creating it once should do it. You also shouldn't need to run a vgscan in the boot scripts because the known volume groups are cached in /etc between reboots, you can run it manually if something changes. Creating /dev/mapper/control once and adding vgchange -a y to the init scripts is ok.

Quoted 5 lines
Quoted 1 line

cat /proc/devices show up, that there is still an entry for lvm, but also for device-mappper. is this maybe the error???

No, I think they should coexist nicely.

thanks again,

manfred

#11 lore raw

Am Son, 2003-05-11 um 21.38 schrieb Manfred Gschweidl:

Quoted 4 lines

uupps...sorry, maybe i should carefully read my mails, after writing them. ;-)
i mean only one entry exists in "/dev/mapper", and this is "control", but no other entry.

Ah, ok, I'm seeing. Well, I think that's a problem with LVM2. At the moment the device files are created either when a volume group gets activated or when it is already active and you add a logical volume.

But when the volume group got activated by the ramdisk and the system switches the root filesystem, you now don't have the devices files.

I think that's where "lvm mknodes" should kick it, but... not implemented yet. And you can't deactivate and reactivate the volume group because the root filesystem on it is mounted.

Great. :D

So it looks like you must create the device files manually.

cd /dev/mapper
mknod volumegroupname-logicalvolumename b 254 0
mknod volumegroupname-logicalvolumename b 254 1
...

After that you also should create the symlinks

cd /dev/volumegroupname
ln -s ../mapper/volumegroupname-logicalvolumename logicalvolumename
...

Since you already put an ls command into the ramdisk before you should know which minor got assigned to which volume.

Or, perhaps this should work: AFAIK if you have a directory /initrd on your root filesystem, the old ramdisk should be moved there after the root filesystem is mounted, so you can just copy the directories and device files that got create there in /dev (/initrd/dev/mapper and /initrd/dev/volumegroupname) to your /dev. But I have never tested this.

This sounds rather ugly and complicated, but it only occurs when switching from LVM1 to LVM2 while having it mounted (because you can't activate it via LVM2 while running on the real filesystem where the device nodes should be created correctly. Or wait until the mknodes command is finished or implement it yourself. ;-)

Signature · 1 line
Christophe Saout <[email protected]>
#12 lore raw

thanks for your help.

after more than one week, now my system boots cleanly without problems, and everything is ok now.

greetings from austria,

manfred

Quoted 48 lines · Christophe Saout

Am Son, 2003-05-11 um 21.38 schrieb Manfred Gschweidl:

Quoted 2 lines

uupps...sorry, maybe i should carefully read my mails, after writing them. ;-) i mean only one entry exists in "/dev/mapper", and this is "control", but no other entry.

Ah, ok, I'm seeing. Well, I think that's a problem with LVM2. At the moment the device files are created either when a volume group gets activated or when it is already active and you add a logical volume.

But when the volume group got activated by the ramdisk and the system switches the root filesystem, you now don't have the devices files.

I think that's where "lvm mknodes" should kick it, but... not implemented yet. And you can't deactivate and reactivate the volume group because the root filesystem on it is mounted.

Great. :D

So it looks like you must create the device files manually.

cd /dev/mapper
mknod volumegroupname-logicalvolumename b 254 0
mknod volumegroupname-logicalvolumename b 254 1
...

After that you also should create the symlinks

cd /dev/volumegroupname
ln -s ../mapper/volumegroupname-logicalvolumename logicalvolumename
...

Since you already put an ls command into the ramdisk before you should know which minor got assigned to which volume.

Or, perhaps this should work: AFAIK if you have a directory /initrd on your root filesystem, the old ramdisk should be moved there after the root filesystem is mounted, so you can just copy the directories and device files that got create there in /dev (/initrd/dev/mapper and /initrd/dev/volumegroupname) to your /dev. But I have never tested this.

This sounds rather ugly and complicated, but it only occurs when switching from LVM1 to LVM2 while having it mounted (because you can't activate it via LVM2 while running on the real filesystem where the device nodes should be created correctly. Or wait until the mknodes command is finished or implement it yourself. ;-)