How to test on Gentoo?

[onimatrix81]

Is there anybody who has got vdevd working on their gentoo systems? At the moment I have got vdevd, hwdb and udevlib-compat compiled fine and now I'm painfully slowly going to test not starting udev in sysinit and putting vdevd there.
I don't use an initrd myself and I was wondering if I could just switch from udev to vdev on the fly and if it is so, how to do that? /etc/init.d/udev stop (stop udev) followed by make -C libudev-compat install (replace the libudev sos in /lib64) and vdevd -c /etc/vdev/vdevd.conf /dev (start vdev) doesn't quite work, but I won't elaborate on the problems if I'm going all wrong about this.

[jcnelson]

Hi @onimatrix81,

I haven't tested on Gentoo yet, but if you're not using an initrd, I think the following guide should get you started:

• build and install vdevd (make -C vdevd; sudo make -C vdevd install)
• build and install vdevd's hardware database (make -C hwdb; sudo make -C hwdb install)
• build and install vdevd's sample configuration (make -C example; sudo make -C example install). This will install a sysvinit-style script to /etc/init.d/vdev, since I haven't merged an OpenRC runscript yet. You may need to manually intervene here to ensure that it will start and stop with OpenRC.
• confirm that vdevd generates your /dev correctly (i.e. run something like mkdir /tmp/dev-test; sudo vdevd -c /etc/vdev/vdevd.conf -l /tmp/vdevd-test.log --once /tmp/dev-test). Inspect /tmp/dev-test to verify that all your device files are in place.
• build libudev-compat (make -C libudev-compat)
• back up your libudev .so files (in case you need to revert to udev/libudev)
• stop udevd
• stop any programs that link to libudev (i.e. Xorg, file managers, etc.).
• install libudev-compat (make -C libudev-compat install)
• start vdevd

Please let me know if you encounter any problems.

Thanks!

[jvvv]

This describes installing libudev-compat twice. Is that intended?

[jcnelson]

@jvvv Good catch; I updated the comment.

[onimatrix81]

Okay. I got some test results here right now if all these logs make sense to you. I quit Xorg and logged my normal user out, then stopped udev. Here's the output of ps afx at that time: http://pastebin.com/jKPZkyRG
After that I copied the libudev-compat/libudev.so* files to /lib64 overwriting the udev files.
Then I chmod -R 777 /dev (just in case, output of that in here: http://pastebin.com/Ribh4ZmD )
Then I mkdir /dev/metadata (just in case, I had a problem with that, once but can't recall details)
After checking again that /run/vdev exists, I ran
vdevd -c /etc/vdev/vdevd.conf /dev

No errors to be seen anywhere so I started X as my normal user. Heh, at this point mouse does work fine, but it's that it STILL works. If i plug in another usb mouse, it won't work.

The vdevd log of this can be found here: https://bpaste.net/show/f6d3861b29a8 (heh, pastebin felt no love for this 2 meg 15k line log :) )

Anyways, feeling pretty good here as the file doesn't contain ERRORs or even WARNs :)

[onimatrix81]

Thought maybe it was the dbus acting up, so I tried again killing xorg, logging out, killing vdevd, stopping dbus, starting vdevd, starting dbus, starting xorg as normal user, but the results are still the same.

[onimatrix81]

Yeah, I probably should've also included the info that i use evdev with xorg. Sidenote: I tested with an usb-memorystick and it worked just fine. Wife's digital camera on the other hand did not, but that's another story :).

[onimatrix81]

Yeah, "it's me again" :). Xorg logs might be also of some importance. Xorg.0.log ( http://pastebin.com/6TtG3ymn ) shows how evdev enables the devices it does enable and how it doesn't recognize the ones plugged in with just vdevd.

[onimatrix81]

I got me some sort of working openrc init script and I can start vdev instead of udev&udev-trigger at boot. Now I think this mouse/keyboard problem is with the libudev-compat scripts not creating correct files and whatnot into /dev/metadata/udev. This is what i have in /run/udev (link to /dev/metadata/udev) when running vdevd http://pastebin.com/sFDifjet and here's the /run/udev when running udev http://pastebin.com/SZNThQ3V Most of the /run/udev/links/ is missing =).

[jcnelson]

@onimatrix81 Wow, your tests are quite extensive! Thank you so much for your diligence!

Wife's digital camera on the other hand did not, but that's another story :).

Does your wife's digital camera usually show up as a removable USB disk, or as an MTP device? I haven't added support for the latter yet, but it's a known issue (#36).

Yeah, I probably should've also included the info that i use evdev with xorg.

It shouldn't make a difference--it looks like your Xorg is set up to communicate with udev, as per the lines:

[ 55251.807] (II) The server relies on udev to provide the list of input devices.
      If no devices become available, reconfigure udev or disable AutoAddDevices.

Thought maybe it was the dbus acting up, so I tried again killing xorg, logging out, killing vdevd, stopping dbus, starting vdevd, starting dbus, starting xorg as normal user, but the results are still the same.

Dbus shouldn't be on the critical path for propagating input device events, but you never know, given how many services route messages through it these days...

Most of the /run/udev/links/ is missing =).

That is concerning. Thank you for providing the /run/udev listings for both udev and vdev.

The code that generates everything in /dev/metadata/udev (which is symlinked to /run/udev) is in vdevd/helpers/LINUX/udev-compat.sh. In particular, it generates the symlinks for device $FOO by parsing /dev/metadata/dev/$FOO/links, which contains the list of all other symlinks the other helper scripts have created thus far (i.e. the file is maintained by the vdev_symlink function in vdevd/helpers/LINUX/subr.sh).

One of three things can be happening here: the helpers could be failing to create their symlinks (which can be confirmed by inspecting /dev for missing links), the links file is somehow being destroyed or corrupted, or udev-compat.sh is exiting before it processes the symlinks.

The third case is easy to verify: if you remove the async=true line from /etc/vdev/actions/zzz-udev-compat.act, the udev-compat.sh script will run synchronously with vdevd, causing vdevd to capture all of its output. Hopefully that will produce some useful error messages. I'm currently working on a patch that will make this step unnecessary--vdevd should capture all error messages regardless of whether or not the helper runs asynchronously.

[jcnelson]

Looking more closely at your logs, it looks like a lot of your installation's helper scripts are simply not running. The action files look like they're installed correctly, but can you verify that all the helpers are installed to /lib/vdev? Here's a listing of my /lib/vdev:

-rwxr-xr-x 1 jude jude   611 Jul  5 01:51 block.sh
-rwxr-xr-x 1 jude jude   608 Jul  5 01:51 char.sh
-rwxr-xr-x 1 jude jude  4134 Jul  7 10:48 daemonlet
-rwxr-xr-x 1 jude jude  6488 Aug 19 14:16 dev-setup.sh
-rwxr-xr-x 1 jude jude 17387 Aug  5 17:16 disk.sh
-rwxr-xr-x 1 jude jude  4309 Jul 18 09:30 dm-disk.sh
-rwxr-xr-x 1 jude jude 34472 Aug 19 14:30 echo_n
-rwxr-xr-x 1 jude jude   687 Jul  7 21:54 event-push.sh
-rwxr-xr-x 1 jude jude 46408 Aug 17 00:52 event-put
-rwxr-xr-x 1 jude jude  1748 Jul  5 16:34 firmware.sh
-rwxr-xr-x 1 jude jude   415 May 13 20:40 gen-ifnames.sh
drwxr-xr-x 2 root root  4096 Jul 21 15:53 hwdb
-rwxr-xr-x 1 jude jude  1494 Jul 31 11:18 hwdb-props.sh
-rwxr-xr-x 1 jude jude  5041 Aug 19 14:19 hwdb.sh
-rwxr-xr-x 1 jude jude  5244 Aug 19 14:21 ifname.sh
-rwxr-xr-x 1 jude jude  7642 Jul 18 09:33 input.sh
-rwxr-xr-x 1 jude jude   137 Aug 23 17:24 modprobe.sh
-rwxr-xr-x 1 jude jude  1527 Jul 31 11:22 netdev.sh
-rwxr-xr-x 1 jude jude  1877 Jul 18 09:35 optical.sh
-rwxr-xr-x 1 jude jude   848 Jul  5 01:51 power-switch.sh
-rwxr-xr-x 1 jude jude  2475 Jul 18 09:41 sound.sh
-rwxr-xr-x 1 jude jude 50592 Aug 17 00:52 stat_ata
-rwxr-xr-x 1 jude jude 37800 Aug 17 00:52 stat_bus
-rwxr-xr-x 1 jude jude 43328 Aug 17 00:52 stat_input
-rwxr-xr-x 1 jude jude 50336 Aug 17 00:52 stat_net
-rwxr-xr-x 1 jude jude 36768 Aug 17 00:52 stat_optical
-rwxr-xr-x 1 jude jude 60104 Aug 17 00:52 stat_path
-rwxr-xr-x 1 jude jude 65456 Aug 17 00:52 stat_scsi
-rwxr-xr-x 1 jude jude 48744 Aug 17 00:52 stat_usb
-rwxr-xr-x 1 jude jude 36664 Aug 17 00:52 stat_v4l
-rw-r--r-- 1 jude jude  3913 Aug 19 14:17 subr-event.sh
-rw-r--r-- 1 jude jude  3432 Jul  7 11:00 subr-hwdb.sh
-rw-r--r-- 1 jude jude 11633 Aug 19 16:06 subr.sh
-rwxr-xr-x 1 jude jude  1125 Jul  5 03:20 sysfs.sh
-rwxr-xr-x 1 jude jude 14898 Aug 19 14:23 udev-compat.sh
-rwxr-xr-x 1 jude jude   303 Aug 19 14:31 usb-name.sh
-rwxr-xr-x 1 jude jude  2852 Aug 19 14:21 v4l.sh
-rwxr-xr-x 1 jude jude  1571 May 30 14:49 VBoxCreateUSBNode.sh

[onimatrix81]

Hello again. Got my mouse working allright now! =)) I diddled with this and that ^n and here we are. As a matter of fact I had hacked so much stuff I started over and build me todays git version of vdevd/libudev-compat and it worked pretty much out of the box (edited the config file and added async=false to few of the .act files).

During all this, I'd pretty much say "don't" to whoever is going to try to test vdevd on a system started with udev in the init. After creating a openrc init script to replace udev alltogether, things went smooth(er). Anyways, now that I got MOST of stuff working I can start reporting some more "real" bugs I find and less pebkac material =).

[jcnelson]

Hi @onimatrix81

During all this, I'd pretty much say "don't" to whoever is going to try to test vdevd on a system started with udev in the init.

Yeah, getting vdev installed is a pretty involved process :/. Udev is pretty deeply ingrained into modern GNU/Linux these days. Soon, I hope to start packaging vdev, which will lower the barrier to entry somewhat.

Thanks again for all your hard work!

[onimatrix81]

Nooo. I knew I put it the wrong way. What I meant is that you don't boot your system with udev, stop it and run vdevd, it's too much hassle. You have to start vdev when you boot, not udev, or it'll get extra complicated. I personally am going to keep testing on and suggest other people with extra time do the same!

[jcnelson]

@onimatrix81 Thanks for your support!

[ghost]

I have an ebuild for Gentoo in my personal repository. https://github.com/grknight/gentoo/tree/master/sys-fs/vdev
It should work as-is, but needs some testing and will evolve as the project does

[jcnelson]

@grknight This is really cool!