It looks like everything I boot my system on a udev only (no TARBALLs), the system doesn't see the device-mapper and other lvm's related devices in time. I need to issue another udevstart to populate the required devices so checkfs runs correctly. This not only affect lvm devices, but also USB storage disks. This is with baselayout-1.9.4-r3 or with baselayout-1.10.4. Reproducible: Always Steps to Reproduce: 1. 2. 3. Here is a diff that actually allow everything to run fine: --- checkfs 2004-09-02 22:19:17.004671112 -0400 +++ /tmp/checkfs 2004-09-02 22:19:10.059726904 -0400 @@ -9,6 +9,9 @@ start() { local retval=0 + if [ "${udev}" = "yes" -a -x /sbin/udevstart ]; then + /sbin/udevstart + fi # Start software raid. # You need a properly configured /etc/raidtab for raidtools usage or a
Created attachment 38791 [details, diff] Simple patch to checkfs.
I can confirm this problem -- using LVM, kernel 2.6.9-rc1, and udev without a tarball -- and that the patch works splendidly (thankyouthankyouthankyou :)).
Can you tell me if you are using an initrd to boot?
> Can you tell me if you are using an initrd to boot? Yes. From genkernel.
and I *did* use a genkernel with the --udev option, for the record (genkernel-3.0.2f).
Can you please revert your change and test the /sbin/rc patch (and _only_ that patch) from the bug below please: http://bugs.gentoo.org/show_bug.cgi?id=43146 I beleive it to be a cleaner fix. Thanks, Rob
It doesn't fix it. /etc/init.d/checkfs fails at the same place. I drop into the shell, issue a udevstart, then I'm able to use vgchange -ay. So, no, the fix in that previous bug doesn't cure my problem. Either the first udevstart happens TOO soon, or I need another one at a later stage (before it goes into /etc/init.d/checkfs.
Hmm. I can't understand why that would be the case. udevstart doesn't create lvm mappings. Sorry to be a pain, but can you please get it to fail again then give me: ls -l /dev/mapper I'm not keen on re-running udevstart, that just doesn't seem right. Did this issue only appear after switching to 2.6.9?
Just to be clear, I mean running the ls after you've dropped to the shell from the checkfs failure.
udev-030 DO create the mapper dir and node. # dm devices (ignore them) KERNEL="dm-[0-9]*", NAME="" # 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" KERNEL="device-mapper", NAME="mapper/control" in /etc/udev/rules.d/50-udev.rules
Just a data point: Adding udevstart thing definitely works for me (I haven't changed anything else, so...), but strangely this also works (with the original checkfs): 1. Boot. Watch it fail to run vgchange -ay and fsck /dev/vg volumes. 2. Log in on the emergency login thingy which appears. 3. Run vgchange -ay Not even running udevstart is necessary for me in this situation. Very strange, but I just though I'd mention it in case it helps.
My feeling is that we are dealing with a race condition.
udevstart doesn't create the /dev/mapper/foo nodes for LVM or dm-crypt. udev handles their naming, but it does not create them, hence me needing the /sbin/rc patch to /sbin/rc to get dm-crypt working when using an initrd. udevstart never creates them. If this is a race condition, it is beyond my skill to fix I'm afraid. I can only offer my feeling that your fix is not "the right" one. I will leave this for people with more knowledge to look at. Sorry for not being able to help.
Here's a bit more input from testing: I changed to 2.6.7 and tried the following scenarios: 1) UNpatched checkfs, UNpatched /sbin/rc: Fails to boot, pgchange complains about /dev/mapper/control not existing. Doing an "ls -l /dev/mapper" IMMEDIATELY after being dumped to the shell shows that /dev/mapper does indeed exist and contains a file/socket/dir named "control". 2) UNpatched checkfs, patched /sbin/rc (patch from bug#43146): Fails to boot. Again, pgchange complains about /dev/mapper/control not existing. Forgot to do an "ls -l ...", but my money is on the "control" file existing. 3) patched checkfs (w/extra udevstart), UNpatched /sbin/rc: Works perfectly. 4) patched checkfs, patched /sbin/rc: Didn't try this as it's quite pointless when using only the udevstart patch for checkfs works. (Oh, and I'm NOT using an initrd) I hate to say it, but this is looking more and more like some sort of weird race condition -- even though just adding a delay to the pgchange *doesn't* work (which it might if it were a simple race condition where the device node just isn't created early enough). I haven't tried adding the "pchange --mknodes" command from the /sbin/rc patch to the checkfs script, although that might work (and be sligtly cleaner than calling udevstart, I suppose).
Should be fixed in the latest verion of udev (and udevstart). We now process the devices in the proper order for lvm2 to work.
