udev rules don't trigger properly

[udeved]

Hi,

I am on Arch Linux, and I use a separarte /usr partition.

I compile eudev with following configuration:

./configure  \
            --prefix=/usr \
            --sysconfdir=/etc \
            --sbindir=/sbin \
            --bindir=/bin \
            --libdir=/usr/lib \
            --enable-libkmod \
            --enable-modules \
            --enable-gudev \
            --enable-introspection \
            --with-modprobe=/sbin/modprobe \
            --with-rootprefix=/usr \
            --with-firmware-path=/usr/lib/firmware/updates:/lib/firmware/updates:/usr/lib/firmware:/lib/firmware

I update initrd after eudev install, I boot, openrc takes over, udev-init-scripts start up, but no additional kernel modules are loaded besides the ones loaded by initrd.

It doesn't make a difference if I set "enable-split-usr", the result is the same.

The bin dirs go on root partition so udev-init-scripts can run, since they don't like symlinks.

In summary, I end up with a booting system, mounted partitions, but for some reason, no additional kernel modules are loaded.

Here is a screenshot:

http://openrc4arch.site40.net/pool/archlinux/eudev.png

http://openrc4arch.site40.net/pool/archlinux/eudev1.png

http://openrc4arch.site40.net/pool/archlinux/eudev2.png

[williamh]

Hi, I am the udev-init-scripts maintainer.
Doesn't archlinux hav the /usr merge? e.g. /bin, /sbin and /lib are actually symlinks to /usr/bin, /usr/sbin and /usr/lib respectively?

[udeved]

Hi William,

yes, arch have a planned /usr merge. Atm, there are still binaries installed on root partition.
/lib is already a symlink to /usr/lib
Your scripts work perfectly well with systemd provided udev on Arch.
Btw, is it necessary the udev script checks for symlinked binary?

[udeved]

Consider it solved. My last hope and try did the trick.
The udevd binary must not reside on root partition for uevents to trigger properly.

Leaves my question to William concerning the symlink check in udev runscript.
Could you possibly implement a prefix make arg for udev-init-scripts?
I sed them with the pkgbuild atm.

[williamh]

I may be able now to drop the test that requires the path to point to the real binary, but that should be a udev-init-scripts bug since you found another resolution for your issue.

[udeved]

I think its both, initscript and eudev related.

I played with various combinations.
If the prefix is set to /usr in eudev configure, udevd binary needs to reside in /usr/sbin.
This is eudev issue I think.
That udev-init-scripts, ie udev runscript expects certain binary paths and can't react to a prefixed openrc install is another issue.

Where can I report or propose udev-init-scripts issues? Simply file gentoo bug?

[williamh]

Yes, you would file a gentoo bug. Make sure udev-init-scripts is in the title.
Be aware though that the udev init scripts will work as they are on a usr merged and non usr merged distro, since /{bin,sbin,lib} are the same as /usr/{bin,sbin,lib} on a distro where the /usr merge has been done.

[udeved]

I noticed one thing after having installed eudev on Arch.
The uevents are being processed very very slowly.
It takes about 30 secs to finish processing.

Thanks William, I will file a bug report on gentoo concerning udev-init-scripts.
As said, the scripts run nicely with a prefixed /usr openrc install. Everything else on the bug report.

[fluxer]

I confirm the slow uevents processing, not on Arch Linux tough so this is not just Arch Linux related problem and is introduced in recent commits.

[blueness]

If the prefix is set to /usr in eudev configure, udevd binary needs to reside in /usr/sbin.
This is eudev issue I think.

To be clear, does the problem occur when --prefix=/usr and --bindir=/bin ?

[blueness]

I confirm the slow uevents processing

I'm not seeing that, can you give me a specific example so I can try to reproduce.

[udeved]

To be clear, does the problem occur when --prefix=/usr and --bindir=/bin ?

Correct. If prefix (rootprefix) is set to /usr, then uevents won't trigger if sbindir=/sbin.
Could be intended though.

I'm not seeing that, can you give me a specific example so I can try to reproduce.

I can't give you on my end much info, other than a quite big delay before uevents finished processing.
I installed and tested it on a laptop(x86_64) and a vbox(i686) setup. Both have the same delay, build from yesterday's git.
When I first encountered it, I expected more a time out error, but then uevents finished suddenly.
There is no error message thrown during the delay.

[fluxer]

Here is my boot log: http://pastebin.com/gt3Wbue2. It seems that this happens after the first "validate module index" message is printed. Hope this helps.

[udeved]

For what is worth,

And here some logs...
dmesg, kern.log and udevmonitor.log
udevdebug.log is empty file.

http://openrc4arch.site40.net/pool/archlinux/log

It is between 30 secs up to 1 min delay.

[blueness]

The problem is some kind of race. Since I can't reproduce it, I havent been able to git disect it down to the commit that introduced it. The problem is obvioius in -> http://openrc4arch.site40.net/pool/archlinux/log/dmesg.log.

I hate to ask you guys to do my job, but if you can do a git bisect that would help. I'll keep trying at my end.

[fluxer]

I checked my package manager log file and my previous build of eudev was dating from 18/03/2013. I'm currently using a package build on 05/04/2013. Both are from master checkout.

[blueness]

Okay, I finally hit this but only on an i686 virtual machine. Right now I'm very confused because the identical amd64 works fine but the i686 stutters. At least now I can reproduce it and trace it down.

[fluxer]

I'm using amd64/x86_64 OS, so it's not only a i686 problem.

[blueness]

Okay thanks fluxer, so its something about my i686 vm which is not there in the amd64 vm. Still I have a handle on it and can start tracing it down.

[udeved]

I can also confirm that this issue extends to amd64.
I have tested it on a VM i686, and on a laptop "live" amd64.

The build on the laptop amd64 dates 6.4.2013.

[fluxer]

It's cool, at least you can reproduce it now. if I had the time for it I would experiment with different checkouts myself but I don't unfortunately.

[blueness]

Please test head for this issue. Its fixed. I'm going to close this bug after I get confirmation. Unfortunately we had two issues here, and I'm not sure I want to "fix" the first one, but its still important to remember.

[fluxer]

Nope, it's worse than before - now even stopping eudev is slow (udevadm control --exit).

[udeved]

Nope, it's worse than before - now even stopping eudev is slow (udevadm control --exit).

It starts nicely now for me on VM i686 just built from today's git.

https://github.com/udeved/pkgbuilds/blob/master/openrc-extra/eudev-git/PKGBUILD

dmesg
http://justpaste.it/2dkt

[blueness]

Nope, it's worse than before - now even stopping eudev is slow (udevadm control --exit).

We may have two issues going on. Can you see if anything on http://forums.gentoo.org/viewtopic-t-955682-highlight-udev+200.html helps. If you can't get anywhere, open a second bug and reference this one --- we already had two issues going on here and I don't want to polute the bug with more different issues.