We need to have this fixed for 18.10, either via some SRU or via a workaround that we publish in the release notes.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T134 18.10 stuff to clean up | ||
| Open | None | T117 Must haves for 19.04 release | ||
| Open | tsimonq2 | T136 Fix EFI/encryption | ||
| Open | wxl | T97 Cala doesn't do 32-bit UEFI |
Event Timeline
Comment Actions
My current hunch is that Adam is right, and we just shouldn't mess with /etc/default/grub.
I'll take this.
Comment Actions
Heeeeey so in dev versions of Neon they're using Calamares. We should check to see if it works there and if so steal their config!!!
Comment Actions
I have investigated a bit on this issue:
I set up two virtual machines with UEFI enabled: one with Lubuntu 18.10 and the other with Xubuntu 18.10.
On vm1 with Lubuntu I did an automatic installation with encryption. After reboot, it ends in the Grub shell.
On vm2 with Xubuntu I did an automatic installation with encryption. After reboot, it just works.
Xubuntu, and I guess also the other flavours, do an installation with an LVM/LUKS container for /, an unencrypted partition for /boot and an ESP.
Lubuntu creates an ESP and an LVM/LUKS container for everything and sets the Grub variables GRUB_ENABLE_CRYPTODISK and GRUB_CMDLINE_LINUX_DEFAULT in the right way. Afaik, this does not match the "official" Ubuntu way to do it and leads to two problems:
- The $ESP/EFI/ubuntu/grub.cfg is wrong
- Important Grub modules are not installed in $ESP/EFI/ubuntu
A possible workaround to boot the encrypted Lubuntu from a live system:
sudo cryptsetup luksOpen /dev/sda2 lukslvm sudo mount /dev/mapper/lukslvm /mnt sudo mount /dev/sda1 /mnt/boot/efi cd /mnt/boot/grub sudo cp grub.cfg ../efi/EFI/ubuntu/grub.cfg sudo cp -r x86_64-efi/ ../efi/EFI/ubuntu/
After a reboot and entering the LUKS passphrase, Lubuntu should start. Maybe there are other configuration issues. And I am not sure, if this will also work with Secure Boot enabled.