When we run current versions of deployment.sh, which include the fix from commitmr10.0f9aea18c, in combination with grml-debootstrap <=0.96 (as shipped by our Grml deployment ISO version sipwise20210511), deployments using EFI might fail with: | Mounting /dev/nvme0n1p2 on /boot/efi | Invoking efibootmgr | EFI variables are not supported on this system. | -> Failed (rc=1) | [...] | Mounting /dev (via bind mount) | Mounting efivarfs on /sys/firmware/efi/efivars | Invoking grub-install with proper EFI environment | chroot: failed to run command 'grub-install': No such file or directory | -> Failed (rc=127) This is caused by a failing invocation of efibootmgr from within grml-debootstrap (versions <=0.96 and running with Debian kernel >=5.10), causing grml-debootstrap to exit then. As a result, the EFI specific GRUB steps in grml-debootstrap's grub_install() from within chroot-script doesn't get executed. Therefor the grub-efi-amd64 package is missing for usage by our efivarfs post-script. By re-introducing the efivarfs pre-script from commit535e6df3we can work around this bug. Furthermore, when /boot/efi should be mounted within the target system by our efivarfs post-script, it might fail when /proc isn't available, like: | # chroot /mnt mount /boot/efi | mount: /boot/efi: can't find UUID=FE60-5B75. This can be fixed by ensuring to mount /proc, /sys etc *before* /boot/efi. Then scanning for the UUID device (as configured in /etc/fstab) works as expected. While at it fix a comment regarding grml-debootstrap >=v0.97 vs >=v0.99, as only v0.99 behaves as expected with our EFI requirements. Change-Id: I9db677a06f7e161f971743fc18b034ad3191a449 (cherry picked from commit9ec2c3d459)
parent
c354c120b2
commit
87b408b49b
Loading…
Reference in new issue