Hello, Within the past 10 days or so, I have begun to experience a boot issue where Starting udev complains with "start-stop-daemon: error while loading shared libraries: libcap-ng.so.0: cannot open shared object file: No such file or directory". I am using OpenRC 0.22.4. My process with genkernel for building the initramfs for the past year has been the following. ' genkernel --luks --zfs --disklabel --linuxrc=/root/linuxrc --mountboot initramfs ' I find, pressing "I" to interrupt startup and start services interactively will permit me to skip xdm and mythbackend which would ordinarily leave the system hanging since udev had not previously started. (no keyboard or mouse if xdm does start). Once local has started, I can login and start udev and udev-trigger and then start the rest of the services which failed because udev did not start normally. It seems to me as if perhaps udev tried to start too early and in the past, before the emergence of the above error - udev started at the right time. In an attempt to work through the above, I upgraded from udev to eudev - didn't make a difference. /usr/lib64/libcap-ng.so.0 does exist. What is happening here that either the initramfs is incomplete or OpenRC is not starting udev properly? How should I go about resolving this other than interactively starting the system until normal boot features are restored? Thanks for your support. Best Regards, -Chicago
Created attachment 455136 [details] Emerge --info output
Emerge --info output added as an attachment as the contents are > 16KiB and would not save as a regular comment.
I did test downgrading to sys-apps/openrc-0.21.7, no difference. Also, I tested an update of the dependency tree cache with 'rc-update --update', no difference with that change either. I see sys-fs/eudev depends on sys-apps/util-linux and because I have USE=caps, sys-libs/libcap-ng. There was a power outage here earlier this week -- I'm wondering now if it may be part of my problem. But, the thing which really seems to be more likely is the separate /usr partition. What do you think?
I am having the same issue. I suspect this used to link to libcap, but now links to libcap-ng. I copied my libcap-ng.so* files from /usr/lib to /lib, and this has (temporarily) gone away, but I think we need to have libcap-ng install into /lib.
Experienced very similar problem. My setup using separate /boot, /usr, /var, /home and genkernel for initramfs with /usr premount. In my case, on boot start-stop-daemon was unable to start udev/udev-trigger because it linked with /usr/lib64/libcap-ng.so.0 which cannot be found (but library exist and path is correct) so what's wrong? The answer was so simple. Incorrect mount option in fstab (nouser for reiserfs) which cause /usr premount stop working, but still successfully postmounted by localmount. So.. you can double-check your rc.log and dmesg, maybe this could help in your case too
I am closing this bug as invalid because it's not a genkernel bug.