On Fri, 2018-12-07 at 09:43 +0100, Chris Lamb wrote:
[...]
> $ sudo update-initramfs -u -k all -v
[...]
> Calling hook zz-busybox
> Adding binary-link /bin/busybox
> Adding binary /usr/bin/busybox
> 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.
> Removing /boot/initrd.img-4.18.0-2-amd64.dpkg-bak
> update-initramfs: failed for /boot/initrd.img-4.18.0-2-amd64 with 1.
>
> Adding a few debugging statements shows that:
>
> /var/tmp/mkinitramfs_mSMoqa/usr/bin/busybox -> busybox
>
> If it helps:
>
> $ ls -l /usr/bin | grep busybox
> -rwxr-xr-x 1 root root 654,048 2018-07-13 05:19 busybox
>
> $ ls -l /bin | grep busybox
> lrwxrwxrwx 1 root root 16 2018-11-26 17:23 busybox -> /usr/bin/busybox
>
> Any ideas? Sounds very usrmerge related... Setting severity to
> "important" as I'm a little worried to reboot. :)
Note that initramfs-tools started building usr-merged filesystems in
version 0.132. Thus, /bin/busybox and /usr/bin/busybox will always be
the same thing in the initramfs.
The file copying function it uses knows how to copy symlinks along with
their targets, but can't cope with a situation like this where the host
filesystem has a file symlink that parallels the directory symlink in
the skeleton initramfs. If necessary, I could probably change that.
Ben.
--
Ben Hutchings
Man invented language to satisfy his deep need to complain.
- Lily Tomlin
Attachment:
signature.asc
Description: This is a digitally signed message part