[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#988826: grub-installer: reinstalling GRUB on a BIOS setup yields an error in rescue mode despite being successful

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"
> 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. :-)

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: