I've just been caught out by this when the EFI -signed- packages somehow got themselves installed - despite having been removed in the past when they appeared due to a change in the depends - and replaced the locally built grubx64.efi that contains the cryptodisk, luks, etc., modules, leaving the system unbootable.
On another (BIOS-based) system I started an LXD 18.04 container, installed grub-amd64-efi, and then built a custom core image to transfer to a USB stick and then used the the EFI boot manager to add that to the boot menu. Once that started I used the grub shell to unlock the encrypted /boot/ file-system, reset 'root' and 'prefix' and started the usual menu. Here's the commands I used to build the grubx64.efi inside the container. apt install grub-amd64-efi ## I added the following to /etc/default/grub (just in case - I think this is only noticed by grub-install though) GRUB_ENABLE_CRYPTODISK=y mkdir -p /boot/efi/EFI/UBUNTU grub-mkimage -v -p /boot -o /boot/efi/EFI/UBUNTU/grubx64.efi -O x86_64-efi part_gpt fat ext2 efi_gop cryptodisk luks gcry_rijndael gcry_sha1 usb usbms usb_keyboard efifwsetup efinet iso9660 help gcry_sha256 loopback lsefi lsefimmap lsefisystab lvm mdraid09 mdraid1x part_msdos ntfs ntfscomp squash4 tftp http udf ufs1 ufs2 exfat ehc i uhci cat Then from the host PC I wrote a GPT with a single 256MB partition to an memory card (SD-card in this case) and formatted it as FAT16 and copied the GRUB core image to it: mkfs.vfat -F 16 /dev/mmcblk0p1 mkdir -p /mnt/boot mount /dev/mmcblk0p1 /mnt/boot mkdir -p /mnt/boot/EFI/BOOT cp /var/lib/lxd/containers/u1804/rootfs/boot/efi/EFI/UBUNTU/grubx64.efi /mnt/boot/EFI/BOOT/BOOTX64.EFI umount /mnt/boot Then I rebooted the EFI PC with the SD-Card inserted in a USB card- adapter into its setup program and added a boot menu entry pointing to the BOOTX64.EFI, then booted to it. Once in the GRUB rescue shell I identified the partition containing encrypted GRUB root file-system (Known as /boot/ on Linux) using: > ls > ls (hd1,gpt2) Unknown filesytem And then did: > cryptomount hd1,gpt2 Typed the passphrase correctly and saw: slot 0 opened Then I did 'ls' to list the devices and saw a new (crypto0) device. I checked that GRUB could read the file-system inside it with: > ls (crpyto0)/ Then reset the environment variables: > set root=crypto0 > set prefix=($root)/grub > ls $prefix/ Having seen the files in the GRUB directory I then loaded the menu- generating module and executed it: > insmod normal > normal And booted normally. Lastly I identified and removed the grub*signed packages and those that depend on them, and regenerated the correct grubx64.efi core image. apt list --installed grub* apt list --installed shim* sudo apt remove shim shim-signed grub-efi-amd64-signed sudo grub-install /dev/sda sudo ls -latr /boot/efi/EFI/ubuntu/ I confirmed the EFI boot menu entry was now pointing to the newly generated grubx64.efi sudo efibootmgr -v -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1565950 Title: Grub 2 fails to boot a kernel on a luks encrypted volume with Secure Boot enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1565950/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
