| Summary: | udev and lvm2 dont work if I dont use RC_DEVICE_TARBALL | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bharath Ramesh <krosswindz> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED REMIND | ||
| Severity: | major | CC: | betelgeuse, gregkh, hoffbrinkle, jakub, kamensky.fb, m.debruijne, rockoo, ulmer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 126089 | ||
| Attachments: | Sleep loop for udev and loading lvm as a module | ||
|
Description
Bharath Ramesh
2004-11-28 10:30:17 UTC
use baselayout-1.11.6+ Just upgraded baselayout to baselayout-1.11.6-r1, sysvinit to sysvint-2.85-r1 and bash to bash-3.0-r7 I still have the same problem. Changing RC_DEVICE_TARBALL="yes" from no doesnt help. Everytime at boot I need to run vgchange -a y manually and then restart checkfs. Are you loading dm-mod as module? I do, and I found that checkfs had problems. It was associated with the amount of delay between when dm-mod gets loaded and when udev makes /dev/mapper available. In order to fix this I put a little sleep loop into /etc/init.d/checkfs. See the attached patch. It'll wait up to 10 seconds, which so far has been long enough on every system I've used it on (5 or 6 now). Created attachment 45993 [details, diff]
Sleep loop for udev and loading lvm as a module
Just an idea, and how I solved my problem. I'm sure others have experienced
this same issue.
Yes I have dm-mod compiled as a module. Probably should either use the sleep or just compile it into the kernel. busy/sleep loops wont be added to baselayout Seems like the only way to reslove this without using busy/sleep loops is probably to to add a comment in /etc/conf.d/rc would be to mention that dm-mod should be compiled into the kernel for you to use RC_DEVICE_TARBALL="no" It will be interesting to see if other distributions have the same problem. I know that debian doesnt use device tarball at all. I have compiled dm-mod into the kernel and it made not difference. Adding sleep looping was the only way I could get it to work. Compiling dm-mod into the kernel fixed my problems. No need for sleep loop. I can verify that for me on a P4 2,4 GHz, baselayout-1.11.10-r2 and udev-045 with no RC_DEVICE_TARBALL you need to have dm-mod compiled into the kernel or it will not work. I think that a comment in /etc/conf.d/rc would be nice. It works with multipath-tools emerged (see Bug 71703); well, except for a little bug caused by dynamic linking of /sbin/multipath to sysfsutils library placed in /usr/lib (see http://bugs.gentoo.org/show_bug.cgi?id=71703#c19) I have successfully tested with the following package versions: sys-fs/lvm2-2.00.33-r2 sys-fs/multipath-tools-0.4.2 sys-fs/device-mapper-1.00.19-r2 sys-fs/sysfsutils-0.4.0 (sys-fs/sysfsutils-1.2.0 works too) sys-fs/udev-056 (sys-fs/udev-054 works as well) gentoo-dev-sources-2.6.11-r4, dm-mod is compiled as a module. *** Bug 90567 has been marked as a duplicate of this bug. *** reopen this bug if its still an issue but this should have been resolved by now |
