On Wed, Apr 08, 2026 at 03:16:26PM -0400, Noah Meyerhans wrote: > Control: tags -1 + patch > > On Mon, Mar 30, 2026 at 02:43:24PM -0400, Noah Meyerhans wrote: > > > The problem can be worked around by passing the `--force-extra-removable` > > > to > > > grub-install. This can be done after the upgrade (but before rebooting), > > > or > > > it'll happen automatically if the grub2/force_efi_extra_removable variable > > > to true before the upgrade, e.g. > > > > > > echo "grub-efi-arm64 grub2/force_efi_extra_removable boolean true" | \ > > > sudo debconf-set-selections > > > > > > With this option, grub-install updates the content of /boot/efi/EFI/BOOT, > > > which otherwise does not get updated. > > > > The cloud image build passes `--force-extra-removable` to grub-install > > to place grub in the fallback UEFI path.[1] This is necessary because > > we can't provide EFI boot order settings as part of the image. Thus, I > > think we also need to take care to ensure that these grub components are > > kept up-to-date through dist-upgrades. We can do that by setting > > grub2/force_efi_extra_removable=true in debconf in the images (i.e. in > > the same script in which we're calling grub-install) > > Fix is in > https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/496
Since the fix will only apply to newly launched VMs based on newer images, I've also prepared an update to release-notes describing how to avoid this issue for VMs based on older images. https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/345
