UTM
UTM copied to clipboard
ARM64 Linux VMs stuck on 'EFI stub: Exiting boot services and installing virtual address map...'
I've tried installing Debian 10.9, 9.13 and openSUSE 15.3 on ARM64 virt machine following the instructions in the gallery and this related issue, but all of them end up stalling when selecting the 'install' option from the installation media, with Debian 9.13 and openSUSE 15.3 showing this before stalling:
Configuration
- UTM Version: 2.1.2
- OS Version: 11.4
- Intel or Apple Silicon? Apple Silicon M1
openSUSE log: debug.log
openSUSE config: config.plist
Update: Ubuntu 20.04.2 and Kali 2021.2 for Apple M1 work fine. Seems to be a problem with the OSes not supporting M1 processors.
To confirm it is an M1 incompatibility, you could check the box "Force slower emulation even when hypervisor is available" in UTM Preferences (Menu UTM => Preferences…).

After checking the box, all VMs will be forced to run using QEMU TCG software emulation instead of using Apple's M1 Hypervisor.
Same problem with Ubuntu 20.04.2 Server, even with 'Force slower emulation even when hypervisor is available' enabled.

MacBook Air M1 running macOS 11.5.1.
@cseelus On my M1 MacBook Pro I wa danke to install Ubuntu Server ARM 20.04 just fine, following the instructions. How did you install it?
Weird, also followed the instructions one by one. Using Debian for now, which works fine (including networking).
I've faced this issue while attempting a fresh install of a ubuntu xenial vm. Changing the Display mode to "Console Only" has solved it.

I recorded the step-by-step in order to provide some evidence on how to reproduce this error:
- full graphics
https://user-images.githubusercontent.com/8990515/130292869-cf15948b-e074-45fb-a805-bc311764ddde.mp4
i did stop the video as soon as the message pops up but it stays stuck in this state forever
- console only (same vm, simply changed display mode)
https://user-images.githubusercontent.com/8990515/130292886-2507f581-4a8e-4e1b-b3e4-5f8bff1637b3.mp4
the iso image i'm using is the following: https://cdimage.ubuntu.com/releases/16.04.7/release/ubuntu-16.04.4-server-arm64.iso
the sha256sum matches with the checksum available at https://cdimage.ubuntu.com/releases/16.04.7/release/SHA256SUMS


i'm no expert but it looks like the problems is related to the distro version that might be missing some video drivers or something... ubuntu 18 and 20 works fine when display mode is set up to full graphics mode
EDIT: i don't have the "Force slower emulation even when hypervisor is available" enabled
EDIT2: i'm using a macbook pro m1

@jeffersfp Indeed it has been reported previously that versions of Ubuntu older than 20 don't work with recent UTM/QEMU (I have not looked into it).
One thing you could try is to play around with the graphics cards choices available and see if any of them allow you to install it.
Same issue. How can I solve it....?
Same issue with Fedora 35. Has anyone created an issue for this problem over att Fedora? Ubuntu 21.10 works perfect with macOS Monterey, UTM 2.4.0 on my M1 Mac.
same on Macbook air M1 and Monterey (Ubuntu server)
Same on 2021 MacBook Pro M1 and Monterey (ubuntu-20.04.3-live-server-arm64, UTM 2.4.1). It booted once, but is now failing.
EDIT: After a complete reinstall it is working for now. The previous install locked up and did not respond to keyboard or mouse, requiring a hard reboot, this may have corrupted the system.
Note for Ubuntu users: I've been using Multipass to run Ubuntu server instances. UTM works great but if all you need is a quick way to spin up Ubuntu instances on the m1 mac, then Multipass is the solution at the time of this message. I was also able to use Vagrant with Multipass as a provider by using this plugin. If you need Ubuntu with GUI or any other linux distro then UTM is the way to go.
I struggled with Fedora 35 ARM installation in M1.
Solution was:
- Disable graphics console, go text only, as suggested above
- Configure Fedora to be installed via VNC, in order to use UTM window as text only and have graphics over VNC
- Use your macOS Screen Sharing app to connect via VNC to the graphical installation (use VM declared IP and port 5901 to connect).
Result is like the screen shot. Notice that this is the Screen Sharing app (a VNC client), not UTM's window.
After installed, this is how Fedora 35 ARM boots in text only:
After successful installation, shutdown the VM and re-enable graphics mode to get all Spice and host USB access. You'll get an EFI error message right after boot, but the VM is booting silently and you'll finally get a text login.
I'm seeing the same issue here. I had a working NixOS VM running (aarch64 guest, aarch64-darwin host). Rebooting the machine from inside the guest got stuck and now I have this forever EFI stub: issue.
Any known workarounds/fixes? I tried the "Force slower emulation..." option to no avail. That option just gives me a forever black screen... no UTM splash screen at boot, etc.
I don't know if this is relevant but at the time that it hangs there is a "QEMULauncher" processes spinning like crazy at constant 100% CPU.
Another thing that doesn't work: deleting/backing up the efi_vars.fd file
https://github.com/albertyw/albertyw.com/blob/dbf68c6b5939e05b5f2ab86288b75c32b323c3c5/app/notes/20211211-1933.md appears to be relevant
Solution that worked for me:
- Attach an installer ISO and boot into it.
- Run
sudo fsck /dev/disk/by-label/<your disk> - Shut down, disconnect the ISO, and reboot into your VM.
- Always always always perform shutdowns from within the guest VM itself!
I have the same problem. I am using a Ubuntu 20.04.3 LTS VM. It worked fine for three months or so until it crashed on me one time.
I tried displaying it in console-mode and this is what I get when booting:
It seems a system file is corrupted.
I tried sudo fsck /dev/mapper/ubuntu--vg-ubuntu--lvwhich seems to be my ubuntu disk partition. (Like it said in the solution note that @samuela posted)
But it gave me
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/mapper/ubuntu--vg-ubuntu--lv is mounted.
e2fsck: Cannot continue, aborting.
Then umount fails when I try unmounting it (giving a 'target is busy' error).
This looks bad, how can I fix it?
Edit:
I managed to run fsck on the next boot using shutdown -rF now
Unfortunately it gave me an Error that looked something like this:
EXT4-fs error ... bad block bitmap checksum ... : Filesystem failed CRC
Sadly I don't think there is much hope for me at this point
Having the same issue as the user https://github.com/utmapp/UTM/issues/2682#issuecomment-987204910 Running Mac Pro 14' M1 with Monterey 12.1, UTM: 3.0.4-2 installed via brew. The difference for me is that after following the installation process, I press Reboot now, it gets stuck with black screen and unresponsive '_' (underscore). After forcing the VM shutdown via UTM interface, detaching the Installer ISO, starting the VM shows again the 'Start boot option' and after a while 'EFI stub: Exiting boot services and installing virtual address map...' frozen screen.
Folks, this problem has a palliative solution just to get you going.
I wrote about it here a few comment above.
Basically you have to disable graphics in your VM.
I've been trying to get a LUKS full disk encryption setup working with UTM on an M1 MacBook. If I use the text only console it works and will boot, but am unable to get it working with graphics at all. It almost seems like the normal boot logs you would see before it enters graphics mode don't show up and that's where I need to type the disk encryption password... =(
Hello guys I had similar issue and what helped is converting image and then importing again as new utm machine..
Something like:
qemu-img convert /Users/
So I guess the problem is in efi_vars.fd or something like that as image itself is fine if you import it again..
Hello guys I had similar issue and what helped is converting image and then importing again as new utm machine.. Something like: qemu-img convert /Users//Library/Containers/com.utmapp.UTM/Data/Documents/Linux.utm/Images/data.raw ~/Documents/data.raw
So I guess the problem is in efi_vars.fd or something like that as image itself is fine if you import it again..
I try this but no luck for me. I have an image named disk-0.qcow2 trying to qemu-img convert to .raw or also .qcow2 but can't import the vm after that UTM saying configuration pb no possible to import it....
I am seeing this as well. It was working for a couple of weeks, and then the network was gone, so I rebooted it, and now it does not boot at all.
Disabling graphics mode does not help, and fsck says that the disks are clean.
Ubuntu 20.04 VM, M1 Monterey.
I've root caused the issue: https://gitlab.com/qemu-project/qemu/-/issues/899
It is Linux 5.4.0-104. Here is a temporary workaround (skip steps 1-4 if the VM worked previously and only stopped booting recently):
- Open the VM settings and under QEMU -> Tweaks, uncheck "Use Hypervisor"
- Boot into Linux, but it will be VERY slow because it is using emulation instead of virtualization.
- Once inside, install the last version of Linux
sudo apt install linux-image-5.4.0-100-generic - Shut down the VM, open VM settings and under QEMU -> Teaks, check "Use Hypervisor" to re-enable virtualization.
- Start the VM and when the UTM logo shows up, hold "Shift" to enter the GRUB menu
- Select "Advanced Options for Ubuntu"
- Select "Ubuntu, with Linux 5.4.0-100-generic" (or anything lower than 5.4.0-104)
- You can now boot into Ubuntu again. You may choose to uninstall 5.4.0-104 and temporarily mask it from being updated in the future:
sudo apt-mark hold linux-image-$(uname -r)
Hopefully this issue can be fixed in QEMU and we can provide an update in the future.
I've root caused the issue: https://gitlab.com/qemu-project/qemu/-/issues/899
It is Linux 5.4.0-104. Here is a temporary workaround (skip steps 1-4 if the VM worked previously and only stopped booting recently):
- Open the VM settings and under QEMU -> Tweaks, uncheck "Use Hypervisor"
- Boot into Linux, but it will be VERY slow because it is using emulation instead of virtualization.
- Once inside, install the last version of Linux
sudo apt install linux-image-5.4.0-100-generic- Shut down the VM, open VM settings and under QEMU -> Teaks, check "Use Hypervisor" to re-enable virtualization.
- Start the VM and when the UTM logo shows up, hold "Shift" to enter the GRUB menu
- Select "Advanced Options for Ubuntu"
- Select "Ubuntu, with Linux 5.4.0-100-generic" (or anything lower than 5.4.0-104)
- You can now boot into Ubuntu again. You may choose to uninstall 5.4.0-104 and temporarily mask it from being updated in the future.
Hopefully this issue can be fixed in QEMU and we can provide an update in the future.
This was the furthest I got. I tried to use apt to install the linux image but I got errors because ports.ubuntu.com could not be reached. I pinged 8.8.8.8 and got network is unreachable. Then I pinged 127.0.0.1 and got replies. My network is shared network and virtio-net-pc. I tried emulated and bridged. None seem to work. It seems this VM is not working right with my guest network.

Hi! How do I uninstall 5.4.0-104 or temporarily mask it from being updated in the future?
I upgraded to ubuntu 21 some time ago and it works much better, for week no such issues.
For network issues see troubleshooting https://mac.getutm.app/gallery/ubuntu-20-04