utmapp / UTM

Virtual machines for iOS and macOS
https://getutm.app
Apache License 2.0
27.23k stars 1.35k forks source link

Ubuntu desktop LUKS install stuck at boot splash screen #3555

Open tcrgit opened 2 years ago

tcrgit commented 2 years ago

I have successfully installed Ubuntu Desktop Aarch64 builds (both 20.04 LTS and 21.10). I have also done this successfully with an unencrypted LVM install.

However when choosing to encrypt with LUKS the install fails to reboot. I have rebooted choosing recovery from grub for a console display. Same failure without any opportunity to enter the password.

When booting from usb/the live Ubuntu iso, the encrypted partition is visible and mountable/decryptable using gParted.

Configuration: UTM Version: 3.04 OS Version: 12.1 Monterey M1 (Arm v8/Aarch64)

Debug log attached LUKS_debug.log

tcrgit commented 2 years ago

Have now confirmed same problem with LUKS install script on UTM in Aarch64 Jammy Desktop Live build (22.04).

adespoton commented 2 years ago

Seems to me this would be related to the UEFI variables. Have you tried doing the same thing on vanilla qemu-system-x86_64?

tcrgit commented 2 years ago

Thanks. Over the last 24 hours, I found a workaround, detailed below. I have not tested an emulated x86_64 LUKS/LVM ubuntu install on the M1 mac, nor have I tested that sort of install on a virtualized x86_64 on an Intel Mac with UTM. Those are reasonable ideas to test. However, I don't think it is a problem with the UEFI variables.

I just finished testing fresh UTM installs with Ubuntu server 20.04 (& 21.10) Aarch64 and initially observed the same failure when in a full graphics display. On a hunch, I set the UTM display to the (serial) console mode. I was then able to see the prompt and enter the LUKS passphrase. I rebooted my former Ubuntu desktop VM installations in console display mode and observed the same was true for Desktop installations, though of course it can't continue to the GUI in console mode.

This insight enabled a workaround of redirecting the LUKS prompt from the serial console to the graphics console:

  1. After installation, don’t reboot and shut down the VM.
  2. Edit the VM in UTM. Eject the ISO installation disk or reorder the USB drive after the hard drive. (This is an unrelated issue/bug #3344.)
  3. Either edit the VM to change the display to console and reboot OR
  4. Press ESC when booting (may need to continue booting from QEMU EFI menu) and at the GRUB prompt press ‘e’ and edit the GRUB “linux” line to add “console=tty1” to after ${vt_handoff}. Hit F10 to continue booting to the GUI The LUKS password prompt should now appear. It will either boot to console mode to a full GUI.
  5. Login (and start a terminal if in the GUI).
  6. To make this change--or to make it permanent, edit the grub default file.

sudo nano /etc/default/grub

  1. Add “console=tty1” at the end of the GRUB_CMDLINE_LINUX_DEFAULT string. Save and exit.
  2. Update grub to make this change effective on boot.

sudo update-grub

  1. If you changed the UTM display to console mode, you still need to shutdown and change it back.

sudo shutdown now

  1. Edit in UTM back to full graphics display mode and reboot the VM.

Upon rebooting, it should show the LUKS passphrase prompt and boot to the GUI.

I do not believe this workaround is a proper bug fix, and I would leave it to someone smarter than me to determine whether this is:

Note that with a 22.04 (Jammy) Aaarch64 Live Desktop installation (as there doesn't appear to a Server ISO yet), this workaround only works for an encrypted LVM LUKS installation... While I have an unencrypted ZFS 22.04 installation working, an encrypted ZFS install will need not only redirecting the console as above but also a solution to a problem resulting in a message that it cannot find the LUKS keyfile during the boot process (after the passphrase is entered it fails to mount the encrypted root and drops into initramfs….).

adespoton commented 2 years ago

Hmm... could you get around this by putting GRUB on a different virtual disk image that also includes the EFI image? I'm thinking that what's really needed is the ability to do the keyboard interaction prior to booting into display mode -- like what Windows does (although to be fair, it boots into a "display mode" first for the password prompt, but that mode is part of the EFI bootloader and not part of the OS boot process.

Seems like the LUKS implementation never expected a situation where the end user would only be able to use TTY /or/ GUI in a single session, and not be able to dynamically switch between them.

tandon commented 2 years ago

I had the same issue, having encrypted the full disk using defaults provided by Ubuntu's installer. Booting in console-only mode, and amending the grub config as suggested by @tcrgit worked beautifully. Thanks.

zuzzurro commented 2 years ago

I tried installing Fedora 35 with LUKS encryption and I think the same issues applies there too. For the time being I reverted to an unencrypted install but I for sure would love to move to an encrypted setup sooner rather than later.

adespoton commented 2 years ago

Out of curiosity, what benefit does LUKS bring to a Linux server running on UTM? While it’s running it is accessible, and the host is already FV2 encrypted with the drive image limited by ACL to the user running the VM.

On Feb 7, 2022, at 9:25 AM, zuzzurro @.***> wrote:

 I tried installing Fedora 35 with LUKS encryption and I think the same issues applies there too. For the time being I reverted to an unencrypted install but I for sure would love to have move to an encrypted setup sooner rather than later.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

zuzzurro commented 2 years ago

Some vm privacy in a company managed notebook?

mrj001 commented 3 months ago

This issue happened with Debian 12 (Bookworm) as well.

My host configuration: UTM: 4.5.3 (99) MacOS: Sonoma 14.6.1 M1 Max processer

Guest is arm64 (machine virt7.2).

I followed the instructions in this issue and it fixed the problem for me too.

lclpsoz commented 1 month ago

The solution provided by tcrgit worked for me as well.

Environment Details