On Wed, 2019-05-08 at 00:27 +0200, Axel Beckert wrote:
> Hi,
>
> > cp: failed to access '/var/tmp/mkinitramfs_mSMoqa//usr/bin/busybox': Too many levels of symbolic links
> > E: /usr/share/initramfs-tools/hooks/zz-busybox failed with return 1.
>
> I'm having a very similar issue which makes me think that this is a
> more generic issue and not necessarily busybox-specific:
>
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-4.19.0-4-686-pae
> cp: failed to access '/var/tmp/mkinitramfs_URATxd//usr/bin/touch': Too many levels of symbolic links
> E: /usr/share/initramfs-tools/hooks/fsprotect failed with return 1.
> update-initramfs: failed for /boot/initrd.img-4.19.0-4-686-pae with 1.
> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
> dpkg: error processing package linux-image-4.19.0-4-686-pae (--configure):
> installed linux-image-4.19.0-4-686-pae package post-installation script subprocess returned error exit status 1
>
> Note that it's /usr/bin/touch and
> /usr/share/initramfs-tools/hooks/fsprotect, but otherwise looks like
> the same issue.
>
> From my point of view this looks like either an issue in
> initramfs-tools or in both, busybox and fsprotect (and maybe more)
> packages not having adapted to breaking changes in initramfs-tools.
[...]
This is a bug in initramfs-tools. The copy_file function applies two
transformations to the target filename:
1. If it matches /bin/*, /lib*, or /sbin/*, add /usr to the beginning
since the initramfs is usrmerged.
2. If it refers a directory, add the basename of the source filename.
These need to be done in the opposite order, to handle a target
filename of "/bin" correctly.
But this is a very different problem from the one Chris Lamb reported.
Ben.
--
Ben Hutchings
The most exhausting thing in life is being insincere.
- Anne Morrow Lindberg
Attachment:
signature.asc
Description: This is a digitally signed message part