Hi,
I've identified the root cause of this issue: busybox hook is called
_before_ klibc one. This ends up with /bin/sh binary in the generated
initrd.img being a copy of (or a symlink to) system
/usr/lib/klibc/bin/sh binary whereas it is expected to be a copy of
(or a symlink to) system /bin/busybox binary.
The explanations in details.
Up to initramfs-tools 0.98.8, an error message should have warn us.
When running e.g. dpkg -i initramfs-tools_0.98.8_all.deb, the
following error is displayed on console:
ln: failed to create symbolic link
`/tmp/mkinitramfs_o2WpcY/bin/sh': File exist
Following commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2
(mkinitramfs: copy over on
build instead of using symlink tree) from maximilian attems, this
error has disappeared in initramfs-tools 0.99. More on this later.
So, why are we getting this ln error with initramfs-tools 0.98.8?
Tracing an initramfs-tools run reveals that busybox hook is called
first, most notably executing:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
ln -s ${BUSYBOXDIR}/busybox ${DESTDIR}/bin/sh
initrd.img correctly has /bin/sh being a symlink to /bin/busybox
binary, the latter being a copy of system /bin/busybox binary.
But next klibc hook is called:
ln -s /usr/lib/klibc/bin/* ${DESTDIR}/bin
ln -s /lib/klibc-*.so ${DESTDIR}/lib
The problem lies in the first line: indeed, system /usr/lib/klibc/bin
directory _contains_ a sh binary. But since busybox hook already
created a symlink with the same name /bin/sh in initrd.img, system
/usr/lib/klib/bin/sh binary can't be copied over the /bin/sh symlink,
hence the ln error on the console.
Now, why is this error disappearing with initramfs-tools 0.99 and why
is the generated initrd.img unbootable?
Since maximilian commit, busybox hook now executes:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/sh
System /bin/busybox binary is thus copied as /bin/sh binary into initrd.img.
But then, klibc hook is called:
cp -pL /usr/lib/klibc/bin/* ${DESTDIR}/bin
cp -pL /lib/klibc-*.so ${DESTDIR}/lib
The problem still lies in the first line, but since these are no more
symlinks but file copies, (i) /bin/sh binary in initrd.img is
overwritten with system /usr/lib/klibc/bin/sh binary and (ii) there's
obviously no more ln error.
I've looked at current initramfs-tools git repository. The problem is
still there, with a subtle difference.
Now, busybox hook executes:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
ln -s busybox ${DESTDIR}/bin/sh
A copy of system /bin/busybox binary is thus put into initrd.img, with
a /bin/sh symlink pointing to it.
However, klibc hook still runs:
cp -pL /usr/lib/klibc/bin/* ${DESTDIR}/bin
cp -pL /lib/klibc-*.so ${DESTDIR}/lib
Because of system /usr/lib/klibc/bin/sh binary, this ends up by
overwriting the _target_ of /bin/sh (symlink previously created by
busybox hook), thus replacing /bin/busybox binary in initrd.img by
system /usr/lib/klibc/bin/sh binary, making initrd.img unbootable.
I've checked that simply replacing /bin/busybox binary in initrd.img
(being in fact a copy of system /usr/lib/klibc/bin/sh binary) by real
system /bin/busybox binary solves the issue.
Now, how to fix this properly? I haven't found where the hook calls
ordering is done. But busybox hook definitely has to be called _after_
klibc one.
I don't know for the other Debian architectures, but if busybox hook
is also called _before_ klibc one, then all the initrd.img are either
wrong (at the best, since /bin/sh binary is thus not a copy of or a
symlink to system /bin/busybox binary as it should) or broken as on
ia64.
Émeric
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caa9xbm532dhrepdoay28aq+flh7ux1jfukfxzhepficucuu...@mail.gmail.com
