Since grml-debootstrap v0.116 there's a reworked GRUB setup, to support
installing both BIOS and UEFI bootloaders, and manage its updates via
grub-cloud-amd64 (see
2891f1730f
for details).
Now that we're shipping grml-debootstrap v0.119 in our latest
Grml-Sipwise deployment ISO, we're making use of its new behavior.
As it turned out, when deploying a SW-RAID based NGCP system, we invoke
grml-debootstrap with incomplete `--grub /dev/`. This is of course
incomplete and unexpected, but only started to fail with the more recent
grml-debootstrap version.
The underlying issue is grml-debootstrap setting GRUB's debconf
configuration to:
grub-cloud-amd64/install_devices: /dev/
And if we're installing grub-cloud-amd64 (or its not an EFI system),
then grml-debootstrap also executes:
grub-install --no-floppy --target=i386-pc "${device}"
Which of course won't work with the device being set to `/dev/`:
| Setting up grub-cloud-amd64 (0.0.5) ...
| Skipping installation without enable flag for cloud.
| Processing triggers for libc-bin (2.36-9+deb12u10) ...
| Installing grub on /dev/:
| Installing for x86_64-efi platform.
| Installation finished. No error reported.
| Installing for i386-pc platform.
| grub-install: error: cannot read `/dev': Is a directory.
| Error: failed to execute 'grub-install --no-floppy --target=i386-pc /dev/'.
To avoid any such failure, make sure grml-debootstrap's --grub option
uses a valid block device, also when installing SW-RAID (and even if it
actually shouldn't matter for EFI environments).
See https://github.com/grml/grml-debootstrap/issues/339 for further
details.
Change-Id: I6b839f708806c5107a1c86adbee1407cbeadddcc
mr13.4
parent
e2db6df5d0
commit
001c9c6073
Loading…
Reference in new issue