So I had a further look into the dropbear initramfs issue. The code
where the breakage occurs is dropbear's hook:
| LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* =>
\(/lib.*\)/libc\.so\..*,\1,p')
| for so in $(find "${LIBC_DIR}" -name 'libnss_compat*'); do
| copy_exec "${so}" "${LIBC_DIR}"
| done
The error lies in the innocent looking copy_exec line. The target is a
directory here, but the documentation of copy_exec says it should be a
file:
| # $1 = file to copy to ramdisk
| # $2 (optional) Name for the file on the ramdisk
| # Location of the image dir is assumed to be $DESTDIR
| # We never overwrite the target if it exists.
| copy_exec() {
So if the target directory happens to not exist which is the case for
LIBC_DIR=/lib/i386-linux-gnu/i686/cmov in my case, the source will be
copied to that name. So "cmov" ends up being a regular file and not a
directory containing the file.
Now really whose bug is this? Let us have a look at other users that
pass a second parameter to copy_exec.
Those that pass a directory:
/usr/share/initramfs-tools/hooks/keymap:copy_exec /bin/loadkeys /bin
/usr/share/initramfs-tools/hooks/keymap: copy_exec /usr/bin/kbd_mode /bin
/usr/share/initramfs-tools/hooks/dropbear: copy_exec
"/usr/sbin/dropbear" "/sbin/"
/usr/share/initramfs-tools/hooks/dropbear: copy_exec
"${so}" "${LIBC_DIR}"
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevd /sbin
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevadm /sbin
/usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/$program /lib/udev
/usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/blkid /sbin
/usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/vio_type /lib/udev
/usr/share/initramfs-tools/hooks/mdadm:copy_exec $MDADM /sbin
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec "/lib/cryptsetup/scripts/$KEYSCRIPT" /lib/cryptsetup/scripts >&2
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec "$KEYSCRIPT" /lib/cryptsetup/scripts >&2
/usr/share/initramfs-tools/hooks/cryptroot:
copy_exec "${KSTYPE#"$KEYSCRIPT" is }" /lib/cryptsetup/scripts >&2
The one gets it right:
/usr/share/initramfs-tools/hooks/busybox: copy_exec ${BUSYBOXDIR}/busybox
/bin/busybox
It seems like most users actually get this wrong. Out of sheer (bad)
luck this has not been discovered thus far.
How do we proceed now? The current API of copy_exec is bad, because it
relies on auxiliary state (the target being a directory or not). It
should be fixed, but this is likely too late for wheezy, given the
number of packages that need to be changed as well.
The particular dropbear issue can be avoided by actually omitting the
second parameter and letting copy_exec sort it out correctly. I believe
that this change should fix both bugs #682964 and #630581.
Thanks to Tino Keitel for assisting in sorting this out.
Helmut
--
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/20121108085157.GA19423@localhost
