Bug 40056 – Mounting ramfs on /dev (for udev) breaks volumes evms_activated in initrd -> fsck of the root device fails

• Product: Gentoo Linux
• Status: VERIFIED NEEDINFO

[Description Ari Rahikkala 2004-02-01 03:39:47 UTC]

I have a system running EVMS 2.2.1 with an EVMS root. My initrd is basically  the same as the official evms-2.2.1-initrd.gz. Its job is to run evms_activate on the volume given as the root= argument to the kernel. This initrd can deal with devfs - that is, it can mount devfs and start up devfsd if needed.

With devfs (automounted by the kernel), the /dev in the initrd is the same as the /dev after init. This means that the device node set up by evms_activate is always available after initrd.

With a static /dev, EVMS volume devices are remembered over reboots. evms_activate still needs to be done in initrd to set up internal kernel state, although the device that initrd sees is not the same as the one seen later.

udev, however, is a bit problematic. The initrd nicely sets up the device nodes, yes, but they're retained neither from the initrd by way of devfs nor from before last reboot by way of being static files. *Using /lib/udev-state/devices.tar.bz2 is a simple workaround for this* but AFAIK that's meant to be a temporary hack. udev can create the EVMS device nodes, AFAIK, but not set them up. Because of this, checkroot fails - it's unable to fsck an un-activated EVMS volume.

Reproducible: Always
Steps to Reproduce:
1. Set system up for EVMS, with an EVMS root
2. Set system up for udev, with the normal procedures *except* without using /lib/udev-state/devices.tar.bz2
3. Reboot

Actual Results:  
Everything works normally except for one thing: "Checking root filesystem" fails
with error 6. This drops me to a sulogin console.

Expected Results:  
It should have had an activated EVMS volume to check. This could be accomplished
by, say, moving EVMS activation before checkroot in the boot process. If there's
some way to let initrd take care of setting up udev and just move its /dev over
to the real /dev, well, that might work, too.

[Comment 1 Martin Schlemmer (RETIRED) 2004-02-19 11:04:57 UTC]

Maybe bug the EVMS guys to get sysfs support added?

[Comment 2 Greg Kroah-Hartman (RETIRED) 2004-02-19 13:07:11 UTC]

evms uses dm, which shows up properly in sysfs.  So udev can name all dm devices just fine.

You can use the following rule in udev.rules to handle dm devices properly:

# create a symlink named after the device map name
# note devmap_name comes with extras/multipath
KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"

[Comment 3 Martin Schlemmer (RETIRED) 2004-02-19 13:14:42 UTC]

Ok, being a total evms noob, I did not know.  Thanks! Ill add to our
rules.

[Comment 4 Martin Schlemmer (RETIRED) 2004-02-22 02:01:59 UTC]

Greg, I prob miss something here - how do you get multipath compiled?  I
tried to install device-mapper, but no go.  Do you need kernel side changes?

[Comment 5 Greg Kroah-Hartman (RETIRED) 2004-02-23 10:54:33 UTC]

I do not know, as I have never tried to build it.

I'll work on trying to fix that for the next release.

[Comment 6 Andreas Simon 2004-04-29 10:42:59 UTC]

It looks like the kernel needs patching for multipath.

I found this at http://christophe.varoqui.free.fr/multipath.html :
This last policy is the core component of the multipath tool chain. It is not included in the main kernel tree as of linux-2.6.5. It is part of a patchset maintained by Joe Thornber (thornber at redhat dot com) that can be downloaded at http://people.sistina.com/~thornber/dm/


And the README from evms-2.3.2 also states that patches are needed for multipath:
Thus, you need to have the appropriate Device-Mapper patches applied to your kernel in order to use multipath.

[Comment 7 Greg Kroah-Hartman (RETIRED) 2004-11-10 11:26:05 UTC]

Closing due to lack of interest.

[Comment 8 Greg Kroah-Hartman (RETIRED) 2005-08-16 11:52:00 UTC]

Closing due to lack of info.