I could use some help installing QEMU or setting up a VM.
QEMU is installed and running:
I can also set up a VM:
However, after it starts, the message “No bootable option or device was found” appears and nothing happens.
I’ve already spent the entire weekend troubleshooting online, but I’m not getting anywhere.
I suspect the problem is not QEMU but whatever it is that you use to drive QEMU.
I’m successfully using QEMU (including kvm acceleration) on all MNT platforms.
From the error message I suspect that the problem might be that the OS you are installing doesn’t do the right thing for QEMU on ARM or, alternatively, that whatever you are using is not doing the right thing to start QEMU in a way that the OS in your VM expects.
If you can give me a raw QEMU command line that works or does not work I might be of help. I’m working with multiple tools in Debian that drive QEMU+kvm.
Thanks, Josch, for the offer—I’ll be happy to get back to you on that.
I’m using Virtual Machine Manager 5.1.0.
I created a new VM using the WIN11-Arm64 ISO.
After the VM was created, it booted up and the following error message appeared:
I’d do the whole thing in the console, too, but I don’t know how …
Sorry, I fear I cannot help with Windows problems. I don’t know anything about the requirements that that operating system has on the VM.
That error is the EDK2 UEFI boot manager telling you that it looked through the boot options and attached devices, but did not see anything with a bootable EFI loader.
A few things could be wrong:
For #1, I think the GUI will tell you somewhere what the architecture is, but you can also check in the terminal:
virsh dumpxml <vm-name> | grep -E "arch|loader|machine"
Hopefully you’ll see something like:
<os>
<type arch='aarch64' machine='virt'>hvm</type>
<loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader>
</os>
For the other 2 issues might try this:
mkdir /tmp/winiso
sudo mount -o loop WIN11-Arm64.iso /tmp/winiso
ls /tmp/winiso/EFI/BOOT/
You should see BOOTAA64.EFI.
Caveat: My Windoze knowledge hasn’t been well tested in a decade or so. I do run a x86_64 Windows VM for the odd task like recovering the emmc on a bricked A311D. 
I’m not sure if it has anything to do with Windows. Any attempt to install Kali or Alpine ends the same way.
Thanks for the suggestion.
Here’s the result:
micha@mntremk:~/Downloads$ mkdir /tmp/winiso
mkdir: cannot create directory ‘/tmp/winiso’: Die Datei existiert bereits
micha@mntremk:~/Downloads$ sudo mount -o loop Win11_25H2_German_Arm64_v2.iso /tmp/winiso
[sudo] Passwort für micha:
mount: /tmp/winiso: /home/micha/Downloads/Win11_25H2_German_Arm64_v2.iso is already mounted.
micha@mntremk:~/Downloads$ ls /tmp/winiso/EFI/BOOT/
ls: Zugriff auf '/tmp/winiso/EFI/BOOT/' nicht möglich: Datei oder Verzeichnis nicht gefunden
micha@mntremk:~/Downloads$
Huh, normally I’d say you probably have a bad ISO but since you say this happens on Linux images as well, I’m less inclined to think that.
For the windows ISO there are a couple other tools for checking the contents…
sudo apt install xorriso # if not already installed
xorriso -indev ~/Downloads/Win11_25H2_German_Arm64_v2.iso -toc
Or…
7z l ~/Downloads/Win11_25H2_German_Arm64_v2.iso | less
If I were in your place I’d want to be sure I had a “known good setup” first. I’d download something commonly run in virtualization on Arm.
Debian 12 netinst (arm64) is small, minimal, very well-exercised on aarch64 KVM since Debian’s own builds are often arm64.
Canonical does a lot of Arm testing too. Look for ubuntu-24.04-live-server-arm64.iso. I often use this as a “does my VirtManager setup work” test on Arm.
If you can get that working in VirtManager then try debugging the issue with your Windows ISO. It’s still possible that image is bad.
Virtualization is a tricky thing to get right, especially with Windows. Viel Glück!
Thanks for the tip. I downloaded and installed Debian 13. It runs smoothly with the default settings. That’s nice, but it doesn’t make things any clearer.
Both the arm64 versions of Alpine and Windows 10 always display the message mentioned above. I’ve compared every setting in LibVirt, but I can’t find any differences.
I’m at a loss…
Right, sorry, I meant Debian 13. And that’s great! It tells us that the hypervisor, KVM, libvirt, and AAVMF firmware (ARM Architecture Virtual Machine) are fundamentally working. That rules out a lot of potential issues.
I’d start by comparing two ISO images: Debian & Windows:
xorriso -indev debian-13-arm64.iso -report_el_torito
xorriso -indev Win11_25H2_German_Arm64.iso -report_el_torito
On Debian you should see something like:
El Torito catalog : 1627 1
El Torito cat path : /boot.catalog
El Torito images : N
El Torito boot img : 1 UEFI
Boot image path : /boot/grub/efi.img
Platform Id : EFI
If that doesn’t work for some reason try 7 zip.
7z l debian-13.6.0-arm64-netinst.iso | less
7z l Win11_25H2_German_Arm64_v2.iso | less
That would give you something like this on Debian:
boot.catalog
EFI/
boot/
dists/
install.a64/
pool/
README.html
md5sum.txt
I honestly don’t know what you’ll get on Windows (or Alpine) but my gut says something different from Debian.
First of all, thanks for your patience!
Here’s the output:
xorriso -indev debian-13.6.0-arm64-netinst.iso -report_el_torito
xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1639 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'debian-13.6.0-arm64-netinst.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR cyl-align-all
Media summary: 1 session, 356864 data blocks, 697m data, 745g free
Volume id : 'Debian 13.6.0 arm64 n'
El Torito catalog : 1028 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 7744 1029
El Torito img path : 1 /boot/grub/efi.img
xorriso -indev Win11_25H2_German_Arm64_v2.iso -report_el_torito
xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and load size: 550 * 2048 , 3360 * 512
libisofs: NOTE : Roughly estimated EFI image size: 4294965248 bytes
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'Win11_25H2_German_Arm64_v2.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito
Media summary: 1 session, 3910832 data blocks, 7638m data, 745g free
Volume id : 'CCCOMA_A64FRE_DE-DE_DV9'
El Torito catalog : 22 1
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 3360 550
El Torito img blks : 1 3910282
Well, there goes my theory on the ISO being non-bootable. 
First, I’d try to mount the EFI system partition:
xorriso \
-osirrox on \
-indev Win11_25H2_German_Arm64_v2.iso \
-extract_boot_images ./bootimages
Then have a look at what was extracted:
file bootimages/*
sudo mount -o loop bootimages/... /mnt
find /mnt
My next guess would be that there’s a VM setting somewhere that is different.
Try this, replacing the name of the vm with your names:
virsh dumpxml debian-vm > debian.xml
virsh dumpxml windows-vm > windows.xml
diff -u debian.xml windows.xml
Lastly, where did the Windows ISO come from? I can try it on my system.
I’m not sure if I’m using the commands correctly. This is what I got:
xorriso \
-osirrox on \
-indev Win11_25H2_German_Arm64_v2.iso \
-extract_boot_images ./bootimages
xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
Copying of file objects from ISO image to disk filesystem is: Enabled
Drive current: -indev 'Win11_25H2_German_Arm64_v2.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 745g free
micha@mntremk:~$ file bootimages/*
sudo mount -o loop bootimages/... /mnt
find /mnt
bootimages/*: cannot open `bootimages/*' (No such file or directory)
mount: /mnt: failed to set up loop device for bootimages/....
/mnt
micha@mntremk:~$ virsh dumpxml debian-vm > debian.xml
virsh dumpxml windows-vm > windows.xml
diff -u debian.xml windows.xml
error: Abruf der Domain 'debian-vm' scheiterte
error: Abruf der Domain 'windows-vm' scheiterte
The ISO file comes from this source:
https://www.microsoft.com/de-de/software-download/windows11arm64
When I run this:
xorriso \
-osirrox on \
-indev Win11_25H2_German_Arm64_v2.iso \
-extract_boot_images ./bootimages
I get this output:
xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
Copying of file objects from ISO image to disk filesystem is: Enabled
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and load size: 550 * 2048 , 3360 * 512
libisofs: NOTE : Roughly estimated EFI image size: 4294965248 bytes
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'Win11_25H2_German_Arm64_v2.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito
Media summary: 1 session, 3910832 data blocks, 7638m data, 1146g free
Volume id : 'CCCOMA_A64FRE_DE-DE_DV9'
/home/stephano/Downloads/bootimages/eltorito_catalog.img : offset=45056 size=2048
/home/stephano/Downloads/bootimages/eltorito_img1_uefi.img : offset=1126400 size=8008257536
xorriso : UPDATE : 935730 blocks read in 1 seconds , 1383.6xD
xorriso : UPDATE : 1296034 blocks read in 2 seconds , 528.8xD
xorriso : UPDATE : 1498034 blocks read in 3 seconds , 296.4xD
xorriso : UPDATE : 1700194 blocks read in 4 seconds , 298.9xD
xorriso : UPDATE : 1903554 blocks read in 5 seconds , 271.7xD
xorriso : UPDATE : 2136114 blocks read in 6 seconds , 340.7xD
xorriso : UPDATE : 2354146 blocks read in 7 seconds , 321.1xD
xorriso : UPDATE : 2564290 blocks read in 8 seconds , 310.7xD
xorriso : UPDATE : 2788530 blocks read in 9 seconds , 327.7xD
xorriso : UPDATE : 3001714 blocks read in 10 seconds , 315.2xD
xorriso : UPDATE : 3294914 blocks read in 11 seconds , 433.5xD
xorriso : UPDATE : 3555906 blocks read in 12 seconds , 384.4xD
xorriso : UPDATE : 3772722 blocks read in 13 seconds , 320.6xD
So my guess is that your image has something wrong with it.
I would redownload it and try these commands:
[stephano@daisuke Downloads]$ ls -lh Win11_25H2_German_Arm64_v2.iso
-rw-r--r-- 1 stephano stephano 7.5G Jul 14 07:23 Win11_25H2_German_Arm64_v2.iso
[stephano@daisuke Downloads]$ file Win11_25H2_German_Arm64_v2.iso
Win11_25H2_German_Arm64_v2.iso: ISO 9660 CD-ROM filesystem data 'CCCOMA_A64FRE_DE-DE_DV9' (bootable)
[stephano@daisuke Downloads]$ sha256sum Win11_25H2_German_Arm64_v2.iso
844d9ee8413874b2f1fccad2222222d5bf138fa07511edd22bb4acdd17895ede Win11_25H2_German_Arm64_v2.iso
You should get similar output to what I have. Especially the SHA checksum should be the same.
I’d be happy to download the ISO file again.
Here are the results using the existing file:
ls -lh
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 7,5G 12. Jul 17:02 Win11_25H2_German_Arm64_v2.iso
micha@mntremk:~/Downloads$ file Win11_25H2_German_Arm64_v2.iso
Win11_25H2_German_Arm64_v2.iso: ISO 9660 CD-ROM filesystem data 'CCCOMA_A64FRE_DE-DE_DV9' (bootable)
micha@mntremk:~/Downloads$ sha256sum Win11_25H2_German_Arm64_v2.iso
844d9ee8413874b2f1fccad2222222d5bf138fa07511edd22bb4acdd17895ede Win11_25H2_German_Arm64_v2.iso
You have indeed found some odd behavior here. Well done.
Since the file is the same as mine, but xoriso seems to think it is a blank piece of media, it stands to reason that something inside qemu is also making that mistake. But qemu doesn’t use the same libraries that xoriso does (for reading optical media), so I’d start with your settings:
virsh list --all
virsh dumpxml "<vm-name>" > windows.xml
virsh dumpxml "<vm-name>" > debian.xml
You’ll need to change those VM names to whatever your windows and debian vm instances are called.
Then send me those files via pastebin or the like. I’ll have a look.
I had no idea I could do something like that 
But I was immediately reminded of my limitations:
virsh list --all
virsh dumpxml debian13 > windows.xml
virsh dumpxml win10 > debian.xml
Id Name Status
---------------------
error: Abruf der Domain 'debian13' scheiterte
error: Abruf der Domain 'win10' scheiterte
I’m assuming the VMs have to be turned on for that?!
Try:
sudo virsh list --all
Then you should see something like:
Id Name State
----------------------------
- <some-vm> shut off
- <other-vm> shut off
Then just take those VM names and add them to the commands:
sudo virsh dumpxml "<some-vm>" > windows.xml
sudo virsh dumpxml "<other-vm>" > debian.xml
I’m almost too nervous to post the result:
sudo virsh list --all
[sudo] Passwort für micha:
Id Name Status
---------------------------------------
- alpinelinux3.21 ausgeschaltet
- debian13 ausgeschaltet
- win10 ausgeschaltet
micha@mntremk:~$ sudo virsh dumpxml "<win10>" > windows.xml
error: Abruf der Domain '<win10>' scheiterte
micha@mntremk:~$ sudo virsh dumpxml "<debian13>" > debian13.xml
error: Abruf der Domain '<debian13>' scheiterte