I don't like that I have the bootloader ID hardcoded to debian. I originally went with that since it looked like how things were done previously, but I will probably add a follow up commit that adds an --efi-id argument or similar to allow customizing that.

but I will probably add a follow up commit that adds an --efi-id argument or similar to allow customizing that.

please don't. we should figure out how to get the debian packages to do the right thing, without grml-debootstrap starting grub commands.

Which grub command are you referring to? The grub-install command?

I think SystemBuildTools are supposed to run that command.

calamares installer runs grub-install. live-build has extensive code to set up grub and other bootloaders. mkosi uses grub-mkimage.

Therefore, I am pretty sure only the system build tool is responsible for setting up the bootloader, which requires running bootloader installation commands.

please don't. we should figure out how to get the debian packages to do the right thing, without grml-debootstrap starting grub commands.

The postinst used by grub-efi-amd64 autodetects the bootloader ID from the GRUB_DISTRIBUTOR variable from GRUB's configuration (not sure if it only relies on /etc/default/grub or if it also parses through /etc/default/grub.d). So if the user was to be allowed to customize the ID without running grub-install explicitly any longer, it would require adjusting that variable in GRUB's configuration, creating the relevant directories under /boot/efi, and then running dpkg-reconfigure --priority=critical grub-efi-amd64.

I'm not quite sure how grub-pc works yet, will have to study that further.

Based on my research, you can only install GRUB on legacy BIOS systems without running grub-install manually if you have grub-pc installed. That isn't possible with this PR since you can't have grub-pc and grub-efi-ARCH co-installed, so my PR will have to leave the grub-install commands that install the legacy BIOS bootloader. However, I think I can get the EFI bootloader to be handled automatically by the Debian package, without having to explicitly call grub-install. So I'll do that.

(I should also be looking into how to allow grub-pc and grub-efi-ARCH to be co-installed, but that's a potentially large task that has to be handled in Debian upstream.)

Alright, this works on my system. I didn't touch the grub-install command for when installing the EFI bootloader when ARM_EFI_TARGET is set, since I didn't understand exactly what was happening there. For the EFI bootloader installation done when using --vmefi though, the bootloader now is auto-installed by the Debian package.

Please use, review the following simplification, if sane

    if [ -z "$VMEFI" ]; then
      grub_pc_package_name=grub-pc
    else
      # We install grub-pc-bin instead of grub-pc when EFI is enabled, because
      # otherwise the EFI bootloader won't be automatically updated when GRUB
      # packages are uploaded. Doing this means that the BIOS bootloader won't
      # be automatically updated, which stinks, however the BIOS bootloader
      # doesn't have the same security concerns as the EFI bootloader (there's
      # no Secure Boot to grapple with when using legacy BIOS boot) so it's
      # better to let the BIOS bootloader lag behind and update the EFI one
      # than to let the EFI bootloader lag behind and update the BIOS one.
      grub_pc_package_name=grub-pc-bin
    fi

    if ! clean_chroot "${MNTPOINT}" dpkg --list "$grub_pc_package_name" 2>/dev/null | grep -q '^ii' ; then
      echo "Notice: '$grub_pc_package_name' package not present yet, installing it therefore."
      # shellcheck disable=SC2086
      clean_chroot "$MNTPOINT" DEBIAN_FRONTEND=$DEBIAN_FRONTEND apt-get -y --no-install-recommends install $DPKG_OPTIONS "$grub_pc_package_name"
    fi

ARM_EFI_TARGET: Assume that works similarly, use the new debconf-set-selections method?

Avoid repetitive clean_chroot "$MNTPOINT" DEBIAN_FRONTEND=$DEBIAN_FRONTEND apt-get -y --no-install-recommends install $DPKG_OPTIONS command in source code, only set package name so the source code has this command only once to install the GRUB package? Not sure it is a good idea to mix this refactoring into this pull request. Might be better to do that later in a follow-up pull request once that one was merged.

@zeha Looking through the code, I can't figure out why ARM_EFI_TARGET is a thing. Wouldn't it be easier to just make VMEFI=1 if building an ARM64 image?