archlinux hook for vdev

[Obarun]

you can find a pkgbuild providing hook for arch here : https://github.com/Obarun/obarun-pkgbuild/tree/master/vdev-obarun
work for me but need more test on another machine.
i suppose fbt will implement it on his pkgbuild but he wait for the pull request before doing it. So you can make test if you want

[Obarun]

i was updated the hook (error occurs on it) but for the moment it don't work correctly. i have mailed a complete file log at jcnelson. Waiting for news

[Obarun]

pkgbuild was updated once again.
i have made a stupid error on the hook install, i forgot the daemonlet. i have an error too about the link for lvs and pvs, fixed too. i have added gcc-libs on dependancies, needed for implement libgcc_s.so on the hook.

[suedi]

hey mate,

I took a look at your PKGBUILD.

Why are you cp in libudev.so.1.6.3

Is that libudev from libsystemd?

You should not rm the one from libudev-compat
instead symlink libudev.so.1.6.3 to the one created
by libudev-compat.

what I have

/usr/lib/libudev.so -> libudev.so.1
/usr/lib/libudev.so.1
/usr/lib/libudev.so.1.0.1 -> libudev.so.1.5.1
/usr/lib/libudev.so.1.5.1 -> libudev.so.1.5.2
/usr/lib/libudev.so.1.5.2 -> libudev.so.1
/usr/lib/libudev.so.1.6.0 -> libudev.so.1.6.4
/usr/lib/libudev.so.1.6.4 -> libudev.so.1

all symlinks except /usr/lib/libudev.so.1 which is the one built by libudev-compat

to be fair probably not all are needed but I just spammed those in on the off-chance it was
coupled with the USB Mouse issue.

[Obarun]

@suedi , libudev.1.6.3 provide by eudev gentoo.
many thank for the remarks i have updated the pkgbuild. i have added loop module and losetup binary on the hook.

[fbt]

Look at my PKGBUILD. As far as I see, only one link needs to be added:

# Missing solink
ln -s /lib/libudev.so.1 "$pkgdir/usr/lib/libudev.so"

This results in:

/usr/lib/libudev.so -> /lib/libudev.so.1
/usr/lib/libudev.so.1
/usr/lib/libudev.so.1.5.2 -> libudev.so.1

 . fbt@twilight ~/git/pkg/vdev-git (master[ok]) > pacman -Qo /usr/lib/libudev.so*
/usr/lib/libudev.so is owned by vdev-libudev-compat-git r683.9f910cf-1
/usr/lib/libudev.so.1 is owned by vdev-libudev-compat-git r683.9f910cf-1
/usr/lib/libudev.so.1.5.2 is owned by vdev-libudev-compat-git r683.9f910cf-1

Otherwise, ldconfig would create the /usr/lib/libudev.so link.

[suedi]

Are you saying libudev.so.1.5.2 symlink would be enough allthough systemd uses
libudev.so.1.6.4?

[fbt]

libudev-compat installs a libudev.so.1.5.2 symlink and everything seems to work on this end.

[fbt]

@Obarun what your hook does is basically load the modules that are needed to mount the rootfs on your system. With modprobe. From a hardcoded list of modules. You can achieve the same result by adding the modules to the MODPROBE variable in /etc/mkinitcpio.conf.

It's what I've been doing, essentially, when I was too lazy to build a custom kernel:
echo "MODULES="$(lsmod | grep -v 'Module' | awk '{print $1}' | tr '\n' ' ')"" >> /etc/mkinitcpio.conf

[Obarun]

@fbt , Certainly i misunderstand some stuffs. are you talking about all the hook or just the early hooks?
i have changed the hook order in my mkinitcpio.conf. so i place like that now :
base autodetect vdev.
so i don't need now the early_hook according of my understanding about your remarks.

Onemore, you said : "libudev-compat installs a libudev.so.1.5.2 symlink and everything seems to work on this end."
if a new version of libudev.so appears (for example libudev.so.1.7) vdev works anyway without symlink to the new version? I don't understand this concept.

[fbt]

so i don't need now the early_hook

Yep, it works after autodetect. Now I feel stupid.

if a new version of libudev.so appears (for example libudev.so.1.7) vdev works anyway without symlink to the new version? I don't understand this concept.

vdev-libudev-compat is supposed to be installed instead of libudev, not together with it. Those links are not supposed to be to a version of libudev from udev, it's just ldconfig stuff.

[fbt]

So. I've tested with the whole hook being:

run_hook() {
    /usr/bin/vdevd -c /etc/vdev/vdevd.conf -l /run/vdevd.hook.log -1 -v2 /dev
}

And it works perfectly, as long as it's after autodetect.
As it's being run with --once, you don't need any cleanup.
Also the /dev/metadata stuff is for libudev-compat, you don't need it in early boot.

[fbt]

So. I've cleaned up the install hook a bit (and went on a bit of a lazy path there for some stuff):
https://pkg.fleshless.org/vdev-git/tree/

You don't need to add all the libs your binaries depend on, add_binary does it for you.
As a bonus, my install hook produces a bit of a smaller initramfs.

Not going to push that to AUR yet as it's building from my vdev fork for the moment.

[fbt]

Hmmm. Update: on one of my systems, it's actually required to run vdevd twice in the initramfs for it to load all the modules properly. I've tried to figure out why, but I'm quite lost.

earlyhook log: http://sprunge.us/KjbD
hook log: http://sprunge.us/RcaB

There is a /dev listing and lsmod output in the end of both logs.

Both are run like this:

/usr/bin/vdevd -c /etc/vdev/vdevd.conf --foreground --once -v2 /dev &>/run/vdevd_(early)hook.log

It misses sd_mod on the first run, for example.

[fbt]

Actually, if I just start vdevd without --once, it works fine. --once does something wrong, it seems.

Or, if you're not supposed to use --once like thet, then how do we make sure vdevd finished settling the device nodes?
Oh. It actually only demonizes after the run.

[jcnelson]

The --once option will cause vdevd to exit once it finishes processing all device events generated by walking /sys/devices. I think what you're seeing is that loading a module in response to processing one device event can cause more device trees to appear in /sys/devices, which vdevd might skip. What needs to happen is vdevd should re-scan /sys/devices until no new devices are discovered (#78).

I hadn't noticed this earlier since my initramfs loads all modules before it starts vdevd.