Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi Ben, Ben Hutchings wrote: > > /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. [...] > 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. Thanks for the prompt analysis. > This is a bug in initramfs-tools. Ok. Since I can't see any such bug report against initramfs-tools, I will file one after this mail. > But this is a very different problem from the one Chris Lamb > reported. I disagree that it is _very_ different since it has very similar symptoms. The cause might be very differnt, though, indeed. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
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 signature.asc Description: This is a digitally signed message part
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
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. Chris Lamb wrote: > Whilst you could indeed change this, given that my attempt at usrmerge > failed for reasons unrelated to busybox and/or initramfs generation JFTR: My case is on a non-usrmerge i386 system running Sid. The issue shows up for at least a few weeks now if not longer (hadn't touched that system for a few weeks or so beforehand) and seemingly for all kernels installed or upgraded since it appeared the first time. > Thus, we should probably just close this bug. Huh? If I wouldn't have found this bug report, I'd have filed (and might still file) the above as at least severity serious as it breaks the installation/upgrade of more or less unrelated packages. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi Ben, > > Any ideas? Sounds very usrmerge related... Setting severity to > > "important" as I'm a little worried to reboot. :) After the aforementioned purge-and-reinstall I rebooted and everything appears to be fine. :) > 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. Whilst you could indeed change this, given that my attempt at usrmerge failed for reasons unrelated to busybox and/or initramfs generation (#914716 in molly-guard) the problem — if there was one to begin with! — is not here and is likely to just mask the underlying problem anyway. Thus, we should probably just close this bug. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
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 signature.asc Description: This is a digitally signed message part
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi Chris, > Well your symlink in /bin was dated 2018-11-26 17:23. Ah, good spot! > Your purge/reinstall could well fix it, just double-check you haven't > ended up with *both* /bin/busybox and /usr/bin/busybox. You should have > only the former and should be able to safely remove /usr/bin/busybox, > assuming /bin/busybox is not a symlink anymore. I had both (identical files). Very interesting... Feel free to close this now, I'm not sure what the next step would be. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
On 07/12/2018 12:27, Chris Lamb wrote: > tags 915830 + moreinfo > severity 915830 normal > thanks > > Chris Lamb wrote: > >> Well, I did attempt a usrmerge on this system; did it perhaps break >> halfway through? > > Purging and re-installing busybox fixed this for me; shall I close > this bug? > > (Downgrading and tagging for now...) Hi Chris, Well your symlink in /bin was dated 2018-11-26 17:23. If that sounds like the sort of time you attempted a usrmerge (and it failed) then I'd say the fingers point towards that indeed. Your purge/reinstall could well fix it, just double-check you haven't ended up with *both* /bin/busybox and /usr/bin/busybox. You should have only the former and should be able to safely remove /usr/bin/busybox, assuming /bin/busybox is not a symlink anymore. Best regards, Chris -- Chris Boot bo...@debian.org
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
tags 915830 + moreinfo severity 915830 normal thanks Chris Lamb wrote: > Well, I did attempt a usrmerge on this system; did it perhaps break > halfway through? Purging and re-installing busybox fixed this for me; shall I close this bug? (Downgrading and tagging for now...) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi Chris, > This is odd. The busybox package ships only a /bin/busybox binary, so > I'm surprised to see your symlink to /usr/bin/busybox and the binary in > there. Do you have any idea where that came from? Well, I did attempt a usrmerge on this system; did it perhaps break halfway through? (What should I be seeing?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
On 07/12/2018 08:43, Chris Lamb wrote: > 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. :) Hi Chris, This is odd. The busybox package ships only a /bin/busybox binary, so I'm surprised to see your symlink to /usr/bin/busybox and the binary in there. Do you have any idea where that came from? Cheers, Chris -- Chris Boot bo...@debian.org
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Package: busybox Version: 1:1.27.2-3 Severity: important Hi, Since a few days ago I am getting: $ sudo update-initramfs -u -k all -v Available versions: 4.18.0-2-amd64 Execute: /usr/sbin/update-initramfs -u -k "4.18.0-2-amd64" -b /boot -v Keeping /boot/initrd.img-4.18.0-2-amd64.dpkg-bak update-initramfs: Generating /boot/initrd.img-4.18.0-2-amd64 Copying module directory kernel/drivers/usb/host (excluding hwa-hc.ko sl811_cs.ko sl811-hcd.ko u132-hcd.ko whci-hcd.ko) Adding module /lib/modules/4.18.0-2-amd64/kernel/drivers/usb/common/usb-common.ko Adding module /lib/modules/4.18.0-2-amd64/kernel/drivers/usb/core/usbcore.ko […] Calling hook udev Adding binary /lib/systemd/systemd-udevd Adding library-link /usr/lib/x86_64-linux-gnu/libkmod.so.2 Adding library /usr/lib/x86_64-linux-gnu/libkmod.so.2.3.3 Adding library-link /lib/x86_64-linux-gnu/libacl.so.1 Adding library /usr/lib/x86_64-linux-gnu/libacl.so.1.1.0 Adding library-link /lib/x86_64-linux-gnu/libattr.so.1 Adding library /usr/lib/x86_64-linux-gnu/libattr.so.1.1.0 Adding binary /bin/udevadm Adding binary /lib/udev/ata_id Adding binary /lib/udev/scsi_id Adding binary /sbin/blkid 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. :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
