Make bootloader updates on UEFI-based systems work #299

ArrayBolt3 · 2025-01-10T06:44:06Z

Fixes #297. Quick summary of changes:

On all EFI-related grub-install calls, --bootloader-id=debian and --force-extra-removable are used. This ensures the bootloader is installed both to the distro-specific path (/boot/efi/EFI/debian) and to the removable media path. --removable is removed from these calls as it is no longer needed and in fact prevents the normal bootloader location from being installed to. Its job is done by --force-extra-removable now.
If --vmefi is enabled, grub-pc-bin is installed rather than grub-pc, allowing the BIOS bootloader to be installed but not allowing it to be automatically updated. This is to allow installing grub-efi-ARCH, which allows automatically updating the EFI bootloader. (Sadly the two cannot be installed at the same time, which is why this change is necessary. If they could be installed at the same time, that would be best, but Debian isn't capable of that at the moment.)
grub-efi-ARCH is installed along with grub-efi-ARCH-signed.
A debconf option is set to ensure that when the EFI bootloader is updated, the update is installed to both the normal and removable media paths. This option, grub2/force_efi_extra_removable, is documented at https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path.
I also cleaned up a trailing whitespace and a seemingly out-of-place newline while I was right here.

ArrayBolt3 · 2025-01-10T18:13:23Z

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.

zeha · 2025-01-11T08:56:46Z

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.

adrelanos · 2025-01-11T19:16:06Z

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.

ArrayBolt3 · 2025-01-11T23:25:52Z

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.

ArrayBolt3 · 2025-01-12T04:58:30Z

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

ArrayBolt3 · 2025-01-12T05:48:24Z

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.

adrelanos · 2025-01-12T18:06:24Z

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

adrelanos · 2025-01-12T18:08:16Z

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.

ArrayBolt3 · 2025-01-12T19:21:17Z

@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?

ArrayBolt3 · 2025-01-12T23:36:45Z

@adrelanos Some of the installation commands are order-dependent in the code, so I'm a bit leery of changing them. There's only three lines that are really repetitive, and deduplicating them would result in more code than is already there. I think for now leaving them as-is and working with them in a future PR would be a good idea.

I looked long and hard at the ARM_EFI_TARGET-related code, and was able to remove it entirely and reuse codepaths from when VMEFI=1 is set. This allows grml-debootstrap to rely solely on Debian package behavior for installing the EFI bootloader, which is what @zeha mentioned should happen.

Also got the simplification @adrelanos recommended integrated.

adrelanos · 2025-01-13T15:57:58Z

So this is the history prior to this pull request: First only grub-pc was supported. Then EFI support was added. Then VMEFI support was added. And finally, ARM64 (EFI only) support was added. This had resulted in a bit of overly complex code with the ARM_EFI_TARGET which was hard to follow and not easily extensible for additional architectures.

Now with the latest commit, after this refactoring, it looks much cleaner.

adrelanos · 2025-01-23T17:08:23Z

Ready for review. Could you kindly review please?

zeha · 2025-01-23T18:29:50Z

I'll try to take a look later

grml-debootstrap

zeha

looks promising, i think the efi-id stuff can fully go away though

ArrayBolt3 · 2025-01-26T01:13:30Z

I added the efi-id stuff because it's necessary for Kicksecure's use case (we can work around it if it doesn't exist, but it's preferable if it does exist). Are there problems with it existing? Would there be a different way of implementing it that would make it acceptable?

zeha · 2025-01-29T06:03:48Z

I added the efi-id stuff because it's necessary for Kicksecure's use case (we can work around it if it doesn't exist, but it's preferable if it does exist). Are there problems with it existing? Would there be a different way of implementing it that would make it acceptable?

So you're saying your usecase includes setting a different GRUB_DISTRIBUTOR, without setting a different os-release vendor name?

ArrayBolt3 · 2025-01-29T06:09:29Z

So you're saying your usecase includes setting a different GRUB_DISTRIBUTOR, without setting a different os-release vendor name?

Indeed it does.

mika · 2025-01-29T17:41:03Z

So you're saying your usecase includes setting a different GRUB_DISTRIBUTOR, without setting a different os-release vendor name?

Indeed it does.

Uff, that sounds very use case specific and like something that should be handled from within custom hooks/scripts instead?

We're trying to strip down on command line options rather than adding further ones. We need to keep grml-debootstrap and its code-base support- and maintainable, which also means that we should focus on having command line options that don't conflict with each other or one needs to figure out with lots of trial-and-error. Common use cases should all work out by default. (We'll try to document and verbalize our plans and vision in #311 BTW.)

I didn't manage to go through all the code change yet, but I think one approach to support BIOS/legacy next to EFI systems at the same time is to install grub-cloud-$(dpkg --print-architecture), which supports grub-efi vs. grub-pc with its dependencies just as needed. This might be useful for the VM use case?

We should rework/simplify/unify all the efi + arm related code path, this seems to get more and more complex :)

ArrayBolt3 · 2025-01-29T18:53:31Z

Uff, that sounds very use case specific and like something that should be handled from within custom hooks/scripts instead?

Yeah, that's an option. I can remove that bit if it's desirable, and then our custom scripts can work with it.

I didn't know about the grub-cloud stuff, I'll take a look at it.

adrelanos · 2025-01-30T13:32:38Z

So you're saying your usecase includes setting a different GRUB_DISTRIBUTOR, without setting a different os-release vendor name?

Indeed it does.

Uff, that sounds very use case specific

That might sound like it but it's really not that special. It's just the "simple" use case for a Debian derivative. Changing /etc/os-release breaks applications since scripts look at ID=debian. There's no way to express "a derivative, yes, but still Debian compatible" in that file. It's not a sophisticated standard supporting derivatives. Hence, that file is best left unmodified.

(For this reason, Qubes also decided not to touch /etc/os-release file.)

Changing GRUB_DISTRIBUTOR however makes sense to avoid pretending to be Debian, while actually being a derivative, to avoid breaking multi-booting.

adrelanos · 2025-01-30T13:55:50Z

Quote grub-cloud-amd64 packages.debian.org

You don't want to use this package outside of cloud images.

Quote list of files:

/etc/default/grub

grub-cloud source code

AMD64 /etc/default/grub contents:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --speed=115200"

Could package grub-cloud managing file /etc/default/grub cause issues?

Running debsums --changed --config would list /etc/default/grub as changed configuration file.
Setting GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0" can cause issues.
- Security issues?
- systemd log spam inside VirtualBox:

[email protected]: Succeeded.
[email protected]: Service RestartSec=100ms expired, scheduling restart.
[email protected]: Scheduled restart job, restart counter is at 625.
Stopped Serial Getty on ttyS0.
Started Serial Getty on ttyS0.
/dev/ttyS0: not a tty
[email protected]: Succeeded.
[email protected]: Service RestartSec=100ms expired, scheduling restart.
[email protected]: Scheduled restart job, restart counter is at 626.
Stopped Serial Getty on ttyS0.
Started Serial Getty on ttyS0.
/dev/ttyS0: not a tty

VirtualBox: Adding a virtual disconnected serial console does not help either. That makes grub boot menu invisible, super long no console output visible, ultra slow boot.

The serial console related issues I've run into ~ 5 years ago when I was also considering "why not enable a serial console by default inside VM images".

If going for a package grub-cloud based solution, it might be better to undo the serial console setup.

grub-cloud seems to support only a limited amount of architectures. (Intel/AMD64 and ARM64 at time of writing.) Depending on your plans for multiple architecture support (Debian is the universal operating system), it might be too limited.

adrelanos · 2025-01-30T14:07:38Z

grub-cloud also does not solve this.

grub-cloud debian/control file

Package: grub-cloud-amd64
...
Depends: ${misc:Depends}, grub2-common (>= 2.02+dfsg1-7), grub-efi-amd64-bin, grub-efi-amd64-signed, grub-pc-bin, shim-signed

Analysis:

grub-cloud also only Depends: on grub-pc-bin but not on grub-pc. Hence, grub-cloud would also suffer from missing grub-pc bootloader updates.
grub-cloud also only Depends: on grub-efi-amd64-bin, grub-efi-amd64-signed. It fails to Depends: on grub-efi-amd64. Hence, grub-cloud would also from missing grub-efi bootloader updates.

In conclusion,

grub-cloud won't be helpful for fixing this issue.
A perfect solution is impossible until Debian for grub-pc with grub-efi co-install-ability feature request Allow concurrent installation of grub-pc and grub-efi-amd64 2 gets implemented.
grub-cloud seems like a worse solution than the implementation being suggested here in this pull request.

mika · 2025-01-30T14:49:29Z

grub-cloud also does not solve this.

Are you sure? Should be as simple as touch /etc/grub.d/enable_cloud, when looking into /var/lib/dpkg/info/grub-cloud-amd64.postinst:

root@f680422b300d:/# cat /var/lib/dpkg/info/grub-cloud-amd64.postinst 
#!/bin/sh

set -eu

install_i386_pc() {
    local basedev=$(grub-probe -t device /boot/ | sed -Ee 's/[0-9]+$//' -e 's/([0-9])p$/\1/')
    grub-install --target=i386-pc "$basedev"
}

install_x86_64_efi() {
    # Install into removable location, we don't have boot entries
    # Install into normal location, grub requires it
    grub-install --target=x86_64-efi --no-nvram --uefi-secure-boot --force-extra-removable
}

install() {
    install_i386_pc
    install_x86_64_efi
}

if ! [ -e /etc/grub.d/enable_cloud ]; then
    echo "Skipping installation without enable flag for cloud." >&2
    exit 0
fi

case "$1" in
    configure)
        install
        update-grub
    ;;

    triggered)
        install
    ;;
esac



exit 0

Am I missing something? 🤔

adrelanos · 2025-01-30T16:14:11Z

grub-cloud seems like a hack working around the non-existence of the Allow concurrent installation of grub-pc and grub-efi-amd64 feature.

If you look at /var/lib/dpkg/info/grub-pc.postinst (and/or /var/lib/dpkg/info/grub-efi.postinst) (which are both based on the postinst.in template), you'll see that the "real" / "full" Debian GRUB package postinst does a lot more, is a lot more sophisticated than `grub-cloud''s postinst.

Real GRUB postinst.in:

    case @PACKAGE@ in
      grub-pc)

Real GRUB grub-pc.postinst:

    case grub-pc in
      grub-pc)

This means, only if grub-pc is installed, all of the code that follows is being executed.

It does a lot of complex stuff. Some examples...

          grub2_disks=
          for disk in $(all_disks); do
            if scan_grub2 "$disk"; then
              grub2_disks="${grub2_disks:+$grub2_disks }$(readlink -f "$disk")"
            fi
          done

Lots of debconf...

        elif running_in_container; then
          # Skip grub-install in containers.
          :

Line 444 to line 711.

But all of that happens only if grub-pc package is installed as per above case statement.

grub-cloud is condensing all of that to a single grub-install command. Line 444 to line 711 from grub-pc.postinst would not be executed.

For package grub-efi-amd64 the situation is similar. By using grub-cloud, we'd miss out of all the code from grub-efi.postinst, from line 713 up to line 746. It contains important code snippets such as:

        if type update-secureboot-policy >/dev/null 2>&1; then
          update-secureboot-policy || true
        fi

ArrayBolt3 · 2025-01-31T06:03:07Z

It's worth noting some of the old grub-pc installation code had to do with things like migrating from grub-legacy to grub2, fighting with RAID devices, multi-OS support, Wubi handling (Wubi was an old way of running Ubuntu as a full operating system from a file on a Windows machine), etc., etc. Lots of legacy and edge case handling. A VM doesn't have pretty much any of those edge cases, so a much simpler solution may be perfectly fine there.

One thing interesting to note is that the grub-cloud package claims # No support for shim yet, install also into removable location. This is strange though because if I create a minimal Debian VM using debootstrap, chrooting, and apt, and use grub-cloud in lieu of grub-efi-amd64 and grub-pc, it seems to install the shim just fine, and I can boot the resulting image in VirtualBox in BIOS and UEFI modes, and in virt-manager in UEFI + Secure Boot mode. (I couldn't test UEFI + Secure Boot with VBox because VBox decided to arbitrarily refuse to let me enable Secure Boot on this one specific VM.)

ArrayBolt3 · 2025-02-06T01:50:44Z

@zeha, @mika Is there more that needs done on this? I believe the consensus is that using grub-cloud as-is is preferable (which is done), and that the --efi-id switch should be fully removed (still needs done, I'll do that once I have confirmation that's correct). Is there anything else that needs done for this to be mergable?

grml-debootstrap

mika · 2025-02-10T08:50:01Z

@zeha, @mika Is there more that needs done on this? I believe the consensus is that using grub-cloud as-is is preferable (which is done), and that the --efi-id switch should be fully removed (still needs done, I'll do that once I have confirmation that's correct). Is there anything else that needs done for this to be mergable?

Yes, the grub-cloud way is the one we should follow, and it seems to be relevant only for amd64 anyways (not supported on i386 and arm64).

The --efi-id option and GRUB_DISTRIBUTOR should be removed, yes.

Please also squash your commits/changes once you're done, provide a good and verbose commit message which clarifies the changes and the overall picture, thanks. :)

mika · 2025-02-10T08:51:28Z

Oh and @ArrayBolt3 please be aware that there's also grub magic in chroot-script (and we want to get rid of this anyways, so everything related to GRUB should be handled by grml-debootstrap and not via chroot-script!).

ArrayBolt3 · 2025-02-11T01:47:37Z

Oh and @ArrayBolt3 please be aware that there's also grub magic in chroot-script (and we want to get rid of this anyways, so everything related to GRUB should be handled by grml-debootstrap and not via chroot-script!).

To be clear, it would be desirable to merge the entirety of the grub configuration/installation block from chroot-script into grml-debootstrap itself, ensuring the grub_install function there does the job of both functions in the end? I think that's what you're saying, just want to make sure so I don't do something wrong.

ArrayBolt3 · 2025-02-11T02:01:17Z

I think I probably misunderstood the above - the two different grub_install functions in grml-debootstrap and chroot-script are pretty different, and while I'm not scared to merge them, I think that's a substantial enough change it should wait for a future PR. For now I'll make the code in chroot-script also able to install the correct bootloaders, so I don't end up overloading this PR.

ArrayBolt3 · 2025-02-11T06:36:25Z

Alright, there's the squashed commit. There's one possible problem left here, which is that for some reason when doing an arm64 EFI install onto a physical drive on an amd64 BIOS system, shim isn't installed into the ESP. I don't know why yet.

ArrayBolt3 · 2025-02-12T03:14:16Z

Fixed the UEFI bootloader on arm64 physical disk installs, and fixed a couple of other issues too (I had a known-buggy line of code in one spot that needed replaced, and I had a placeholder left around).

ArrayBolt3 · 2025-02-13T02:28:29Z

fyi, I believe this is ready for review again, whenever someone wants to take a look at its current state.

adrelanos · 2025-02-21T11:43:21Z

Friendly ping?

chroot-script

grml-debootstrap

mika

So @zeha, @jkirk and myselfl looked into this together, adding my comments additionally to @zeha. Looks much better from my PoV now, thx! Some comments/questions from my side also hereby

chroot-script

grml-debootstrap

ArrayBolt3 · 2025-02-25T01:16:09Z

Force-push to rebase changes on tip of master.

zeha · 2025-02-25T13:05:33Z

ARM still seems to have problems in CI

zeha · 2025-02-27T09:57:14Z

ARM still seems to have problems in CI

please rebase, the general CI problem should be fixed on master

ArrayBolt3 · 2025-02-27T15:34:42Z

Rebased, also fixed the unneeded !efi_support codepath issue.

Previously, it was possible to install both BIOS and UEFI bootloaders at the same time when creating VM images with grml-debootstrap. In this setup however, the UEFI bootloader would not be automatically updated, due to the absence of a grub-efi-ARCH package on the installed system. It also was not possible to install both bootloaders using grml-debootstrap on a physical disk, and arm64 VM images could not be built with full UEFI support as enabled by the --vmefi argument (these builds would fail). To rectify these issues: * Use grub-cloud-amd64 to install both BIOS and UEFI bootloaders and manage updates. * Add support for installing BIOS and UEFI bootloaders simultaneously on physical disk installations. * Get rid of the ARM_EFI_TARGET variable and make ARM64 VM builds use VMEFI=1 by default. Fixes grml#297, grml#257

ArrayBolt3 · 2025-02-28T06:40:23Z

Image build test results for #299

All image builds were done twice, once on a VM using BIOS firmware, and once
on a VM using UEFI firmware. The host's hardware can have an effect on the
build result, so this was necessary to ensure that things worked as expected.

All of the following options were tested in all possible combinations:

Architectures: amd64, arm64
Distributions: Bullseye, Bookworm, Trixie
Firmware types: BIOS, EFI
Image generation methods: Manual, Automatic

For "image generation", manual image generation is defined as generating a VM
image by creating the disk image, attaching it as a physical disk using
qemu-nbd, and then partitioning, formatting, and installing onto it as if it
were a physical disk. The exact code to do this is provided here (this is
the script used to automate the builds). Automatic image generation is
generating a VM image by using the --vm, --vmfile, and sometimes --vmefi
arguments to grml-debootstrap to get it to do this part automatically.

arm64 BIOS images were not generated because BIOS firmware is not supported
for the arm64 architecture.

Each image was checked by booting it using QEMU. The script used to automate
the QEMU launches is provided here. This document was then checked off
manually, as each point was checked.

Note: /boot/efi was not automatically mounted on some of the auto-built EFI builds. This is the same as the behavior prior to the refactor to my awareness, thus I do not consider this a problem for this PR, though it may be something to fix later.

Summary

Almost everything seems to be working as expected. Interesting observations were:

Automatically generated UEFI-enabled Trixie images seem to use /efi as the ESP mount point, rather than /boot/efi as expected.
The capitalization of Debian in the ESP mountpoints varies, depending on whether or not one uses automatic or manual image generation. Perhaps that should be fixed?
Manually generated images do not have a fallback EFI bootloader installed.
No testing was done to see how grml-debootstrap modified (or failed to modify) the host's UEFI variables. This should probably be tested prior to merge.

Details

[x] Builds on BIOS hardware
- [x] bullseye-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bullseye-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bullseye-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] bullseye-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] bullseye-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] bullseye-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
- [x] bookworm-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bookworm-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bookworm-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] bookworm-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] bookworm-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] bookworm-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Only the distro-specific (debian) bootloader is installed?
- [x] trixie-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] trixie-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] trixie-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [!] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
    - FAIL: EFI partition was located at /efi rather than /boot/efi! /efi/EFI/Debian contained both GRUB and SHIM binaries.
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] trixie-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] trixie-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [!] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
    - FAIL: EFI partition was located at /efi rather than /boot/efi! /efi/EFI/Debian contained both GRUB and SHIM binaries.
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] trixie-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Only the distro-specific (debian) bootloader is installed?
[x] Builds on EFI hardware
- [x] bullseye-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bullseye-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bullseye-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] bullseye-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] bullseye-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] bullseye-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Only the distro-specific (debian) bootloader is installed?
- [x] bookworm-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bookworm-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] bookworm-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] bookworm-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] bookworm-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] bookworm-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Only the distro-specific (debian) bootloader is installed?
- [x] trixie-amd64-bios-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] trixie-amd64-bios-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (Single ext4 partition)
  - [x] /boot/grub/i386-pc exists and contains module files?
- [x] trixie-amd64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [!] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
    - FAIL: EFI partition was located at /efi rather than /boot/efi! /efi/EFI/Debian contained both GRUB and SHIM binaries.
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
  - [x] Boots in EFI mode?
- [x] trixie-amd64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in BIOS mode?
  - [x] Expected partition layout present? (ESP, BIOS boot, ext4 root)
  - [x] /boot/grub/i386-pc exists and contains module files?
  - [x] /boot/grub/x86_64-efi exists and contains module files?
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] Only the distro-specific (debian) bootloader is installed?
  - [x] Boots in EFI mode?
- [x] trixie-arm64-efi-auto.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [!] /boot/efi/EFI/Debian contains both GRUB and SHIM binaries?
    - FAIL: EFI partition was located at /efi rather than /boot/efi! /efi/EFI/Debian contained both GRUB and SHIM binaries.
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Both distro-specific (Debian) and generic (BOOT) bootloaders are installed?
- [x] trixie-arm64-efi-manual.img
  - [x] Build succeeded?
  - [x] Boots in EFI mode?
  - [x] Expected partition layout present? (ESP, ext4 root)
  - [x] /boot/efi/EFI/debian contains both GRUB and SHIM binaries?
  - [x] /boot/grub/arm64-efi exists and contains module files?
  - [x] Only the distro-specific (debian) bootloader is installed?

zeha · 2025-02-28T10:37:47Z

Would be good to have these tests in the CI

mika

I'd like to have @zeha's +2 for this, but basically LGTM. Thx!

chroot-script

ArrayBolt3 · 2025-02-28T21:38:23Z

Alright, I've now done the last bit of testing I wanted to do, which was make sure grml-debootstrap is able to edit the host's UEFI variables when doing a physical hardware install. I installed Lubuntu into a VM, provided the VM with a secondary blank disk, then installed grml-debootstrap into Lubuntu and used it to deploy Debian to the secondary disk. The Debian installation shows up in the boot menu as expected after installation.

adrelanos mentioned this pull request Jan 13, 2025

drop legacy support: stop supporting oldstable and older #282

Closed

adrelanos mentioned this pull request Jan 23, 2025

Remove legacy PC boot support? #304

Open

zeha reviewed Jan 23, 2025

View reviewed changes

grml-debootstrap Outdated Show resolved Hide resolved

zeha reviewed Jan 23, 2025

View reviewed changes

grml-debootstrap Outdated Show resolved Hide resolved

zeha reviewed Jan 23, 2025

View reviewed changes

grml-debootstrap Outdated Show resolved Hide resolved

zeha reviewed Jan 23, 2025

View reviewed changes

mika reviewed Feb 10, 2025

View reviewed changes

grml-debootstrap Outdated Show resolved Hide resolved

grml-debootstrap Outdated Show resolved Hide resolved

grml-debootstrap Show resolved Hide resolved

ArrayBolt3 mentioned this pull request Feb 11, 2025

VM build failing if combining --vmefi with --arch arm64 #257

Open

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from 51825d5 to c407ca7 Compare February 11, 2025 06:35

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from c407ca7 to 34b42c1 Compare February 12, 2025 03:13

zeha reviewed Feb 24, 2025

View reviewed changes

chroot-script Outdated Show resolved Hide resolved

zeha reviewed Feb 24, 2025

View reviewed changes

grml-debootstrap Show resolved Hide resolved

mika reviewed Feb 24, 2025

View reviewed changes

chroot-script Show resolved Hide resolved

chroot-script Show resolved Hide resolved

grml-debootstrap Outdated Show resolved Hide resolved

grml-debootstrap Show resolved Hide resolved

grml-debootstrap Show resolved Hide resolved

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from 34b42c1 to 5f5f588 Compare February 25, 2025 01:15

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from 5f5f588 to 04b3553 Compare February 25, 2025 02:15

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from 04b3553 to 8bc6a8b Compare February 27, 2025 15:34

mika mentioned this pull request Feb 27, 2025

Drop support for Debian's "i386" port #324

Open

ArrayBolt3 force-pushed the arraybolt3/better-grub-efi branch from 8bc6a8b to 2891f17 Compare February 27, 2025 18:32

mika reviewed Feb 28, 2025

View reviewed changes

chroot-script Show resolved Hide resolved

Make bootloader updates on UEFI-based systems work #299

Are you sure you want to change the base?

Make bootloader updates on UEFI-based systems work #299

Conversation

ArrayBolt3 commented Jan 10, 2025

ArrayBolt3 commented Jan 10, 2025

zeha commented Jan 11, 2025

adrelanos commented Jan 11, 2025

ArrayBolt3 commented Jan 11, 2025 • edited Loading

ArrayBolt3 commented Jan 12, 2025

ArrayBolt3 commented Jan 12, 2025

adrelanos commented Jan 12, 2025

adrelanos commented Jan 12, 2025

ArrayBolt3 commented Jan 12, 2025

ArrayBolt3 commented Jan 12, 2025

adrelanos commented Jan 13, 2025

adrelanos commented Jan 23, 2025

zeha commented Jan 23, 2025

zeha left a comment

Choose a reason for hiding this comment

ArrayBolt3 commented Jan 26, 2025

zeha commented Jan 29, 2025

ArrayBolt3 commented Jan 29, 2025

mika commented Jan 29, 2025

ArrayBolt3 commented Jan 29, 2025

adrelanos commented Jan 30, 2025

adrelanos commented Jan 30, 2025

adrelanos commented Jan 30, 2025

mika commented Jan 30, 2025

adrelanos commented Jan 30, 2025

ArrayBolt3 commented Jan 31, 2025

ArrayBolt3 commented Feb 6, 2025 • edited Loading

mika commented Feb 10, 2025

mika commented Feb 10, 2025

ArrayBolt3 commented Feb 11, 2025

ArrayBolt3 commented Feb 11, 2025

ArrayBolt3 commented Feb 11, 2025

ArrayBolt3 commented Feb 12, 2025

ArrayBolt3 commented Feb 13, 2025

adrelanos commented Feb 21, 2025

mika left a comment

Choose a reason for hiding this comment

ArrayBolt3 commented Feb 25, 2025

zeha commented Feb 25, 2025

zeha commented Feb 27, 2025

ArrayBolt3 commented Feb 27, 2025 • edited Loading

ArrayBolt3 commented Feb 28, 2025 • edited Loading

Image build test results for #299

Summary

Details

zeha commented Feb 28, 2025

mika left a comment

Choose a reason for hiding this comment

ArrayBolt3 commented Feb 28, 2025

ArrayBolt3 commented Jan 11, 2025 •

edited

Loading

ArrayBolt3 commented Feb 6, 2025 •

edited

Loading

ArrayBolt3 commented Feb 27, 2025 •

edited

Loading

ArrayBolt3 commented Feb 28, 2025 •

edited

Loading