Windows 11 25H2 ISO enters boot loop

[malaz]

Hello everyone,

I am unable to boot the official Windows 11 25H2 x64 ISO on Proxmox.

After starting the VM it displays the Proxmox Logo with "Start boot option" and it loads successfully, after that "Press any key to boot from CD or DVD..." gets displayed.
When I press a key, the prompt disappears, the Proxmox logo appears right after for around 30 seconds, after that it will load successfully again "Start boot option" and then shows the same prompt again (Press any key to boot from CD or DVD...). and the cycle continues in this way...

If I do not press a key, I get:



The keyboard input is definitely detected, because pressing a key immediately changes the boot behavior.

A Windows Server 2022 ISO boots successfully in the same VM.

The Windows 11 ISO is an official Microsoft ISO
SHA-256 is also correct.

What I already tested:
- OVMF/UEFI
- Secure Boot enabled and disabled
- New EFI disk (Pre-Enrolled Keys enabled and disabled)
- q35 and i440fx
- CPU type host, kvm64 and x86-64-v2-AES
- Windows ISO as IDE and SATA CD-ROM
- SCSI and SATA virtual disks
- New VM created from scratch
- Booting BOOTX64.EFI manually
- Booting cdboot_noprompt.efi manually (Starting BOOTX64.EFI or cdboot_noprompt.efi manually only causes a brief black screen and returns to the EFI file browser.)
- Only the Windows ISO enabled in the boot order (with the ISO being set as ide0)
- Direct keyboard input through qm sendkey (didn´t seem to work)

Current VM configuration:



I already found a couple if people who had the same issues but there were no clear solutions it looked like it worked somehow for them.

I am ready to test more suggestions. I may have already tried some of them, but I can test them again if needed.

Thank you for your help. I look forward to your replies.

 

[g.fiore]

A few things I don't see in your test list:

1) Try an older machine type. You're on pc-q35-11.0 which is very fresh. Try dropping to pc-q35-9.2+pve1 (or even 8.2) and see if the loop goes away. Recent q35 versions changed some IDE/OVMF emulation details and there are a couple of Windows bootloader regressions floating around.

qm set 102 --machine pc-q35-9.2+pve1

2) Where is the ISO stored? If iso-storage2 is a network share (NFS/CIFS/etc.), copy the ISO to local storage and mount it from there. UEFI bootloaders on large ISOs (25H2 is ~8GB) over network storage can time out during the initial payload load without surfacing an error — you just get the loop.

3) Test with a different ISO. Try the English 25H2 image, or an older Win11 24H2 image if you have one lying around. If English 25H2 works and German 25H2 doesn't, something's off with that specific image (even if SHA matches Microsoft's).

4) In the OVMF boot menu (Esc during early boot), select the CD as a one-time boot manually instead of going through the boot order. That bypasses some of the OVMF boot manager logic and sometimes works around exactly this loop.

If none of the above helps, worth reporting on the pve-devel mailing list — this feels like a real regression rather than a config issue, given how many things you've already ruled out.

 

[J-Rod]

I created a test VM and had no issues using the defaults presented by PVE 9.2.3. Here are the major differences from your setup:

cpu: x86-64-v2-AES
machine: pc-q35-11.0+pve1
Win11_25H2_English_x64.iso

Update: tested using English v2 ISO, German v2 ISO, host, pq-q35-11.0, and various other combinations of settings and still didn't have the issue. My host CPU is an older Xeon E3-1275 v5.

 

[g.fiore]

Good isolation test. Now the failing config differs from the working one in three places — CPU, machine type, and ISO — so at least one of those is the culprit. Easiest way to nail it down is to change one thing at a time on the failing VM:

1) First, try the English ISO on the broken VM. If it boots, the German v2 image is the problem (SHA matching Microsoft doesn't guarantee the release isn' buggy — the "v2" suffix means MS already re-released it once).

2) If English still fails, align the machine type to what the working VM has:

qm set 102 --machine pc-q35-11.0+pve1

pc-q35-11.0 and pc-q35-11.0+pve1 are actually different machine types — the +pve1 suffix means PVE patches are applied, and it's what PVE 9.2.3 assigns to new VMs by default. Yours is on the naked upstream one, which suggests the VM was created earlier and never migrated forward.

3) Only if both above still fail, switch CPU from host to x86-64-v2-AES.

CPU last because host is normally the more capable option and shouldn't cause boot loops on its own — it's the least likely of the three.

 

[MarkusKo]

If this is a vanilla Windows 11 iso you may have to use x86-64-v3 or newer due to Windows 11 cpu requirements ...

 

[_gabriel]

There was bug in PVE 9.0 with ISO uploaded to ZFS.

[SOLVED] Post in thread 'Proxmox VE 9.0 ISO Upload Corrupts Some Windows Server 2025 ISOs'

Aug 13, 2025

Okay I managed to reproduce the issue by producing a file with enough hole and large-enough filled extents. This seems to be an interaction between zfs and glibc (and the buggy behavior seems to be in glibc from initial analysis).
If you intend to upload more large files, you'll want to mount some non-ZFS file system on /var/tmp for the time being.

• wbumiller

•