Package: initramfs-tools
Version: 0.98.8
Severity: normal
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch natty

We had a rather obscure Ubuntu bug
(https://bugs.launchpad.net/bugs/728611) which presented as Plymouth not
being able to display text at boot time, which of course is nasty in
cases where the user needs to answer a prompt in order for boot to
complete. This turned out to be restricted to configurations where
Plymouth is built into the initramfs, so I chased this down.

The problem is that /lib/plymouth/label.so now transitively links to
libGL, which (on Ubuntu, at least) lives in /usr/lib/mesa/libGL.so.1 or
some other subdirectory of /usr/lib depending on the GL implementation
in use (fglrx, nvidia, etc.). This directory isn't on the linker's
default search path; instead, it relies on /etc/ld.so.cache having been
built appropriately from a configuration including
/etc/ld.so.conf.d/GL.conf, which is managed by update-alternatives. The
thing that's going wrong here is that /usr/lib/mesa/libGL.so.1 is copied
into the initramfs, but it isn't on the linker's search path so
/lib/plymouth/label.so fails to load.

I looked at fixing this by copying in /etc/ld.so.conf* and running
ldconfig, but this turned out to be very difficult due to the way
mkinitramfs symlinks libraries during initramfs creation, and I ended up
giving this up as infeasible for the time being. I think it's better to
have copy_exec check whether the target directory name is only on the
linker search path by virtue of /etc/ld.so.conf*, and if so, install to
/lib or /usr/lib as appropriate instead.

I don't know whether you'll want to take this patch exactly, or refine
it, or do something else entirely; but I've tried to make it relatively
safe and it may be worth it for robustness even if you aren't running
into this problem in Debian right now.

* If copy_exec finds libraries to copy which are only accessible to the
runtime linker by virtue of being listed in /etc/ld.so.conf*, then
install those libraries to /lib or /usr/lib as appropriate instead
(LP: #728611).

=== modified file 'hook-functions'
--- hook-functions 2011-02-09 18:05:28 +0000
+++ hook-functions 2011-03-26 00:44:38 +0000
@@ -151,6 +151,21 @@ copy_exec() {
libname=$(basename "${x}")
dirname=$(dirname "${x}")

+ # Avoid installing to directories which require ld.so.conf
+ # in order to work. (Running ldconfig over the initramfs
+ # would be better, but the way we symlink libraries during
+ # creation stymies that.)
+ if grep -qsx "${dirname}" /etc/ld.so.conf /etc/ld.so.conf.d/*; then
+ case ${dirname} in
+ /usr/lib/*)
+ dirname=/usr/lib
+ ;;
+ /lib/*)
+ dirname=/lib
+ ;;
+ esac
+ fi
+
# FIXME inst_lib
mkdir -p "${DESTDIR}/${dirname}"
if [ ! -e "${DESTDIR}/${dirname}/${libname}" ]; then

Thanks,

--
Colin Watson [cjwatson@ubuntu.com]



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110326011258.GE9163@riva.ucam.org">http://lists.debian.org/20110326011258.GE9163@riva.ucam.org

On Sat, 26 Mar 2011, Colin Watson wrote:

>
> I looked at fixing this by copying in /etc/ld.so.conf* and running
> ldconfig, but this turned out to be very difficult due to the way
> mkinitramfs symlinks libraries during initramfs creation, and I ended up
> giving this up as infeasible for the time being. I think it's better to
> have copy_exec check whether the target directory name is only on the
> linker search path by virtue of /etc/ld.so.conf*, and if so, install to
> /lib or /usr/lib as appropriate instead.

There is a branch out there that gives up that symlink mess and runs
ldconfing on the built initramfs. I intent to upload it for 0.99.
It was prompted due to a similar long bug search #612633
http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/maks/mkinitramfs_cp

currently a bit frustrated as the review of initramfs-tools branches
got stalled. (we'd only merge branches if other maintainer has reviewed
it). It paid of for squeeze as never had so less bug reports on a release,
but still currently too many branches and stuff pilling up, see bottom
http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary

> I don't know whether you'll want to take this patch exactly, or refine
> it, or do something else entirely; but I've tried to make it relatively
> safe and it may be worth it for robustness even if you aren't running
> into this problem in Debian right now.

Thanks a lot for the submisson, as mentioned running ldconfig is
considered better.

--
maks



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110327082341.GA22891@stro.at">http://lists.debian.org/20110327082341.GA22891@stro.at