Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 601652 - initramfs :: start-stop-daemon: error while loading shared libraries: libcap-ng.so.0, Starting udev
Summary: initramfs :: start-stop-daemon: error while loading shared libraries: libcap-...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-05 08:06 UTC by Chicago
Modified: 2020-06-23 18:51 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Emerge --info output (emerge-info.txt,23.48 KB, text/plain)
2016-12-05 08:08 UTC, Chicago
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chicago 2016-12-05 08:06:56 UTC
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
Comment 1 Chicago 2016-12-05 08:08:32 UTC
Created attachment 455136 [details]
Emerge --info output
Comment 2 Chicago 2016-12-05 08:09:07 UTC
Emerge --info output added as an attachment as the contents are > 16KiB and would not save as a regular comment.
Comment 3 Chicago 2016-12-05 09:48:08 UTC
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?
Comment 4 Jeremy Stent 2017-11-04 15:42:33 UTC
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.
Comment 5 Alex D-Bug 2019-07-21 18:31:31 UTC
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
Comment 6 Thomas Deutschmann (RETIRED) gentoo-dev 2020-06-23 18:51:21 UTC
I am closing this bug as invalid because it's not a genkernel bug.