udev rules don't trigger properly about eudev HOT 24 CLOSED

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?

from eudev.

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?

from eudev.

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.

from eudev.

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.

from eudev.

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?

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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 ?

from eudev.

I confirm the slow uevents processing

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

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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.

from eudev.

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

from eudev.

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

from eudev.

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.

from eudev.