| Summary: | sys-kernel/dracut-044 and sys-devel/prelink-20151030: /usr/sbin/prelink: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
| Component: | Current packages | Assignee: | Patrick McLean <chutzpah> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, floppym, nrndda, plevine457 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/dracutdevs/dracut/issues/152 https://github.com/gentoo/gentoo/pull/7320 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | dracut patch for prelink | ||
I've just reported this upstream at GitHub: https://github.com/dracutdevs/dracut/issues/152 Is dracut currently working for Gentoo in this state? dracut development does not care much about Gentoo and even less about OpenRC, reading the upstream ticket neither about prelink. But there is already a patch provided upstream, just not pulled yet. I adapted that patch to Gentoo, tested and working. Could we already apply that? Created attachment 499518 [details, diff]
dracut patch for prelink
Running with DRACUT_RESOLVE_DEPS=1 works for me on sys-kernel/dracut-046.
I.e., something like:
> DRACUT_RESOLVE_DEPS=1 dracut --kver 4.14.8-gentoo-r1 -f --early-microcode --strip --prelink -H
(In reply to Peter Levine from comment #4) > Running with DRACUT_RESOLVE_DEPS=1 works for me on sys-kernel/dracut-046. > > I.e., something like: > > > DRACUT_RESOLVE_DEPS=1 dracut --kver 4.14.8-gentoo-r1 -f --early-microcode --strip --prelink -H Actually, I can confirm that https://github.com/dracutdevs/dracut/commit/ed9281d6d13b6250e3f12408366fca46bc3384ce fixes the aforementioned error message. The only message I get now is about e2fsck, but I don't think it's fatal. > dracut: *** Pre-linking files *** > /usr/sbin/prelink: /sbin/e2fsck: COPY relocations don't point into .bss or .sbss section > dracut: *** Pre-linking files done *** The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c3cc2518e9a02a232005dda2f4f136e7c008475 commit 4c3cc2518e9a02a232005dda2f4f136e7c008475 Author: Alexander Tsoy <alexander@tsoy.me> AuthorDate: 2018-03-06 16:40:24 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-03-09 19:08:31 +0000 sys-kernel/dracut: bump to 047 Closes: https://bugs.gentoo.org/585106 Closes: https://bugs.gentoo.org/648508 Closes: https://github.com/gentoo/gentoo/pull/7320 sys-kernel/dracut/Manifest | 1 + sys-kernel/dracut/dracut-047.ebuild | 151 ++++++++++++++++++++++++++++++++++++ 2 files changed, 152 insertions(+) |
Dracut fails to prelink the initramfs on my system, because the prelink binary requires libelf.so.1 which is not installed by the dracut script. dracut: *** Resolving executable dependencies *** dracut: *** Resolving executable dependencies done*** dracut: *** Pre-linking files *** /usr/sbin/prelink: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory dracut: *** Pre-linking files done *** dracut: *** Stripping files *** dracut: *** Stripping files done *** The corresponding dracut code reads thus: dinfo "*** Pre-linking files ***" inst_multiple -o prelink /etc/prelink.conf /etc/prelink.conf.d/*.conf chroot "$initdir" "$PRELINK_BIN" -a rm -f -- "$initdir/$PRELINK_BIN" rm -fr -- "$initdir"/etc/prelink.* dinfo "*** Pre-linking files done ***" So apparently it lists the files prelink will probably need, does the prelink step, then uninstalls said files again. But it misses the libelf reported by ldd: # ldd /usr/sbin/prelink linux-vdso.so.1 (…) libelf.so.1 => /usr/lib64/libelf.so.1 (…) libc.so.6 => /lib64/libc.so.6 (…) libz.so.1 => /lib64/libz.so.1 (…) /lib64/ld-linux-x86-64.so.2 (…) I think `dracut-install --ldd` (or some shell function invoking this, e.g. `DRACUT_RESOLVE_DEPS=1 inst_multiple`) should be able to install the prelink binary with all accompanying files. But cleaning that up again might be tricky. So I'm not sure this can reasonably be addressed at the distribution level. Let me know whether I should forward this issue upstream, and if so, which upstream channel you'd suggest.