search

jcnelson / vdev

A device-file manager for *nix
GNU General Public License v3.0
101 stars 13 forks source link

archlinux hook for vdev #74

Open Obarun opened 9 years ago

Obarun commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

fbt commented 9 years ago

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

fbt commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.

Obarun commented 9 years ago

@fbt i have followed you about the hook install with a little difference, i have keeped module : squashfs, loop, sd_mod, fuse. if i don't implement this the autodetect hook don't write these modules at /lib/module/$kernel/. erasing symlinks about libc stuff removed some errors i had for a time, thank for that. my pkgbuild was updated, take a look on it.

So with this hook i have no errors anymore on log(first time for me), but it seems not complete entirely the processus. vdev_action_loader debug things but doesn't load anything. i have already error on vdevd log from pid 1 like this : http://pastebin.com/QJXR7LBQ. Onemore, directories /dev/input/{by-id,by-path} doesn't exist (no mouse, no keyboard finded).

Now if i implement on my mkinitcpio.conf all the modules like @fbt said by this command echo "MODULES=\"$(lsmod | grep -v 'Module' | awk '{print $1}' | tr '\n' ' ')\"" >> /etc/mkinitcpio.conf, the processus is complete because i have this on my hook.log at the end : parent: all initial devices processed. i have already the same error on vdevd.log about VBoxCreateUSBNode.sh but the rest dissapear, no more error about eth or wlan. vdev_action_loader debug and load all. directories /dev/input/{by-id,by-path} appear but are not complete, i have only the keyboard, no mouse. if i run twice vdevd the mouse appear. So i think we have a trouble with module.

Onemore, vdevd on pid 1 take a very long time for finish the processus and the ram used is huge (320M under console). if i umount the loop device the ram go down to 100Mega. i think i don't understand correctly the function attach_hwdb() in particular this part :

if [ $_RC -ne 0 ]; then 

  if [ $_CREATED -ne 0 ]; then 
     /bin/rm -f "$VDEV_MOUNTPOINT/$_HWDB_LOOP"
  fi

  return $_RC

fi

and this part

if [ $_RC -ne 0 ]; then 

  /sbin/losetup -d "$VDEV_MOUNTPOINT/$_HWDB_LOOP"

  if [ $_CREATED -ne 0 ]; then 
     /bin/rm -f "$VDEV_MOUNTPOINT/$_HWDB_LOOP"
  fi

  return $_RC

fi

why do you erase and detach the loop device? Anyway this function seem to not run correctly because if i make a break in my init just after launched vdevd, the loop device is not detached. but certainly i don't understand this function.

sorry for my english guys :(

fbt commented 9 years ago

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).

Yeah, makes sense. I'll put --once back into the initramfs once that's implemented, as it seems like the best way to do early boot configuration device configuration :3

jcnelson commented 9 years ago

@Obarun

i have already the same error on vdevd.log about VBoxCreateUSBNode.sh but the rest dissapear.

This particular problem from your log usually arises when you don't have a vboxusers group. Can you confirm whether or not this is the case for you?

Onemore, vdevd on pid 1 take a very long time for finish the processus and the ram used is huge (320M under console). if i umount the loop device the ram go down to 100Mega.

That's strange...can you show me what it says from ps aux? For example, mine has this:

root     30737  0.0  0.0  82876  2336 ?        Sl   Oct04   0:04 /sbin/vdevd -c /etc/vdev/vdevd.conf /dev

i think i don't understand correctly the function attach_hwdb() in particular this part :

Vdev comes with a hardware database like udev, but vdev's is implemented as a squashfs image (which should only be 4.2MB) that gets mounted to /dev/metadata/hwdb. The hwdb.sh helper will query it using the modalias string of a device event, in order to extract extra information about a device.

The code in dev-setup.sh is executed by vdevd before it starts processing device events. In particular, the attach_hwdb() function allocates a loop device, associates it with the hwdb file, and mounts it. If any of those steps fail, attach_hwdb() tries to clean up after itself by disassociating the hwdb file and deleting the loop device. This is necessary for vdevd to discover it under /sys and set it up along with the rest of the loop devices.

The reason vdevd takes a while to start up is probably due to the fact that in some cases, pvs searches the mounted hardware database (which is time-consuming). This is a known problem, and is tracked in #37.

Obarun commented 9 years ago

@jcnelson sorry for my late answer, i was very busy. this is the output of ps aux :

root 6816 0.0 0.0 82724 2900 ? Sl 12:13 0:00 vdevd -c /etc/vdev/vdevd.conf /dev

This particular problem from your log usually arises when you don't have a vboxusers group. Can you confirm whether or not this is the case for you?

i don't have anymore this error and i don't have vboxusers group on my test system.

the loading procedure is as follows :

This procedure in pid 1 cause trouble. when vdevd is started before remounting rootfs an error appear and say me : / is busy. I don't understand why. Vdevd should be started in first place, right?

Well after several test with modules on hook , i look what happens in pid 2

However a have a readlink error on /dev/fd/, a symlink exist pointed at nowhere. i have a several line like this on the log :

00100:00007FF1A943B700: [ os/linux.c:1174] vdev_linux_sysfs_register_devices: DEBUG: Register device '/sys/devices/uncore_imc/uevent' 00100:00007FF1A943B700: [ os/linux.c:0832] vdev_linux_sysfs_register_device: DEBUG: Empty uevent file at '/sys/devices/uncore_imc/uevent'

Onemore, i big trouble occurs with modprobe.sh. The modalias seem to be not correct. One question about this, i'm finding this on sd-hwdb.c :

static const char hwdb_bin_paths[] = "/etc/systemd/hwdb/hwdb.bin\0" "/etc/udev/hwdb.bin\0" "/usr/lib/systemd/hwdb/hwdb.bin\0"

i haven't those files on my system. it can cause problem?

you can find log here : vdevd.log for hook : https://gist.github.com/Obarun/d5fda94aeeb0b7d6c4e7 modprobe.sh output : https://gist.github.com/Obarun/19b9a55e3aa444c94cf5 vdevd.log on pid 1 : https://gist.github.com/Obarun/09ad3d97e0087f6e0cc9