Summary: | system don't see my lvm2 disks unless I re-issue a udevstart in checkfs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Lebel <lebel> |
Component: | [OLD] baselayout | Assignee: | Greg Kroah-Hartman (RETIRED) <gregkh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs-gentoo.org |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Simple patch to checkfs. |
Description
David Lebel
2004-09-02 19:52:02 UTC
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. |