Cyril Brulebois <kibi@debian.org> (2021-05-20): > Namely, rescue.d/80grub-reinstall gets this new code (excerpt): > > chroot /target mount /boot/efi || true > EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi" > trap "umount $EXTRA_PATHS" HUP INT QUIT KILL PIPE TERM EXIT > > The first line does generate an error/warning message that's harmless > (seen in /var/log/syslog, not in the interface) for BIOS systems. > > But the suspected culprit is the unconditional addition of > /target/boot/efi (that's unlikely to exist on such systems) to > EXTRA_PATHS, coupled with the trap call. Since the umount there isn't > guarded with a “|| true”, and since the trap is deployed for EXIT as > well, it might be that we're trying to exit successfully, but end up > triggering an error due to the ENOENT when unmounting. > > If that's confirmed, it might be better to guard this differently, e.g. > via: > > if [ -e /target/boot/efi ]; then > chroot /target mount /boot/efi || true > EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi" > fi That wouldn't be sufficient: umount would just get called with $EXTRA_PATHS as a parameter. In my purposefully-broken test setup, I do have a separate /boot partition on /dev/sda1 (encrypted LVM, without cryptodisk), but it seems /boot doesn't get handled via EXTRA_PATHS. With the if condition proposed above, we would just call “umount” without any parameters, and we would get an error message from busybox, telling us it expects at least one parameter… Anyway, hopefully the problem is obvious enough for anyone to propose and test proper solutions. :-) Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature