My genkernel-next generated an initramfs that would hang every time when trying to run "vgchange -aay" (my root partition is on an LVM). Browsing the net for similar issues (I found a few), it boiled down to the fact that the udev rules that create the devices (or links) are missing, and hence the process gets stuck there waiting for the devices to be created. I identified the problem in the following code in gen_initramfs.sh local udev_dir="$(pkg-config --variable udevdir udev)" udev_files=( $(qlist -e sys-fs/lvm2:0 | grep ^${udev_dir}/rules.d) ) On my system: > pkg-config --variable udevdir udev /lib/udev > qlist -e sys-fs/lvm2:0 | grep -F /rules.d/ /lib64/udev/rules.d/11-dm-lvm.rules /lib64/udev/rules.d/69-dm-lvm-metad.rules /lib64/udev/rules.d/10-dm.rules /lib64/udev/rules.d/13-dm-disk.rules /lib64/udev/rules.d/95-dm-notify.rules As you can see, the lib v.s. lib64 discrepancy is causing the grep populating the "udev_files" to not copy the files over. I would appreciate it if a fix could be put in place. > ls -gGd /lib* lrwxrwxrwx 1 5 Dec 13 17:18 /lib -> lib64 drwxr-xr-x 1 3154 Dec 18 00:03 /lib32 drwxr-xr-x 1 5282 Dec 24 04:33 /lib64 Reproducible: Always
Created attachment 366062 [details, diff] 0010-Sometimes-pkg-config-says-lib64-udev-qlist-says-lib-.patch This is the patch I use to fix the issue on my system.
commit 99d1ae9d8a10a39f5dec3aa6ad716af289df9928 Author: Fabio Erculiani <lxnay@sabayon.org> Date: Thu Dec 26 13:37:11 2013 +0100 gen_initramfs.sh: use realpath to ensure that udevdir files are grepped correctly See Gentoo bug #495194
