Summary: | initramfs :: start-stop-daemon: error while loading shared libraries: libcap-ng.so.0, Starting udev | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Chicago <chicago> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | chicago |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Emerge --info output |
Description
Chicago
2016-12-05 08:06:56 UTC
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. |