Running into a weird one with Proxmox 9.2.3.
I have a Win Server 2025 template (UEFI, virtio-scsi-single, 90G disk on
LVM-thin, sysprepped with /generalize). Template itself is fine - if I
strip the template flag and boot it as a regular VM, it comes up at OOBE
no problem.
But every full clone from this template fails to boot:
BdsDxe: failed to load Boot0004 "UEFI QEMU QEMU HARDDISK" : Not Found
BdsDxe: No bootable option or device was found.
Booted a Windows install ISO on the clone, loaded vioscsi.inf with
drvload, ran diskpart. Disk is there (90GB Online), but:
list partition
Partition 1 Primary 2047 GB Offset 512 B
A 2047GB partition on a 90GB disk - GPT is clearly mangled. "There are
no volumes" confirms it. Source template disk has a perfectly valid GPT
with ESP + Windows partition.
Template config (no CDROMs, no TPM, no unused disks):
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: nvme-2tb:base-9000-disk-0,efitype=4m,pre-enrolled-keys=0,size=4M
machine: pc-q35-11.0
memory: 4096
ostype: win11
scsihw: virtio-scsi-single
scsi0: nvme-2tb:base-9000-disk-1,iothread=1,size=90G
template: 1
Already ruled out:
- Secure Boot (recreated efidisk with pre-enrolled-keys=0)
- TPM (removed entirely)
- Stale CDROMs / unused disks on template (cleaned up before re-templating)
- VirtIO driver missing in WinPE (loaded manually, same result)
lvs after clone shows data% close to source on both volumes, so bytes
appear to get copied - but the partition table on the destination is
garbage.
Workaround that works every time: skip qm clone, dd the volumes directly.
qm create 103 --name test --ostype win11 --machine pc-q35-11.0 \
--bios ovmf --memory 4096 --cores 4 --sockets 1 --cpu host \
--scsihw virtio-scsi-single --net0 virtio,bridge=vmbr0 \
--agent enabled=1 --boot 'order=scsi0'
qm set 103 --efidisk0 nvme-2tb:0,efitype=4m,pre-enrolled-keys=0
qm set 103 --scsi0 nvme-2tb:90,iothread=1
dd if=/dev/nvme-vg/base-9000-disk-0 of=/dev/nvme-vg/vm-103-disk-0 bs=4M
dd if=/dev/nvme-vg/base-9000-disk-1 of=/dev/nvme-vg/vm-103-disk-1 bs=4M
qm start 103
Boots straight to OOBE, GPT intact, all volumes present.
So the template is good, the storage is good, dd works - but qm clone
ends up with a corrupted partition table on the destination. Anyone seen
this on LVM-thin with UEFI Windows guests? Worth a Bugzilla?
pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.6-2
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
ceph-fuse: 19.2.3-pve4
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.13
libpve-guest-common-perl: 6.0.3
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.5
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.1-1
proxmox-backup-file-restore: 4.2.1-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.3
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.7.5
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.16
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
I have a Win Server 2025 template (UEFI, virtio-scsi-single, 90G disk on
LVM-thin, sysprepped with /generalize). Template itself is fine - if I
strip the template flag and boot it as a regular VM, it comes up at OOBE
no problem.
But every full clone from this template fails to boot:
BdsDxe: failed to load Boot0004 "UEFI QEMU QEMU HARDDISK" : Not Found
BdsDxe: No bootable option or device was found.
Booted a Windows install ISO on the clone, loaded vioscsi.inf with
drvload, ran diskpart. Disk is there (90GB Online), but:
list partition
Partition 1 Primary 2047 GB Offset 512 B
A 2047GB partition on a 90GB disk - GPT is clearly mangled. "There are
no volumes" confirms it. Source template disk has a perfectly valid GPT
with ESP + Windows partition.
Template config (no CDROMs, no TPM, no unused disks):
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: nvme-2tb:base-9000-disk-0,efitype=4m,pre-enrolled-keys=0,size=4M
machine: pc-q35-11.0
memory: 4096
ostype: win11
scsihw: virtio-scsi-single
scsi0: nvme-2tb:base-9000-disk-1,iothread=1,size=90G
template: 1
Already ruled out:
- Secure Boot (recreated efidisk with pre-enrolled-keys=0)
- TPM (removed entirely)
- Stale CDROMs / unused disks on template (cleaned up before re-templating)
- VirtIO driver missing in WinPE (loaded manually, same result)
lvs after clone shows data% close to source on both volumes, so bytes
appear to get copied - but the partition table on the destination is
garbage.
Workaround that works every time: skip qm clone, dd the volumes directly.
qm create 103 --name test --ostype win11 --machine pc-q35-11.0 \
--bios ovmf --memory 4096 --cores 4 --sockets 1 --cpu host \
--scsihw virtio-scsi-single --net0 virtio,bridge=vmbr0 \
--agent enabled=1 --boot 'order=scsi0'
qm set 103 --efidisk0 nvme-2tb:0,efitype=4m,pre-enrolled-keys=0
qm set 103 --scsi0 nvme-2tb:90,iothread=1
dd if=/dev/nvme-vg/base-9000-disk-0 of=/dev/nvme-vg/vm-103-disk-0 bs=4M
dd if=/dev/nvme-vg/base-9000-disk-1 of=/dev/nvme-vg/vm-103-disk-1 bs=4M
qm start 103
Boots straight to OOBE, GPT intact, all volumes present.
So the template is good, the storage is good, dd works - but qm clone
ends up with a corrupted partition table on the destination. Anyone seen
this on LVM-thin with UEFI Windows guests? Worth a Bugzilla?
pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.6-2
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
ceph-fuse: 19.2.3-pve4
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.13
libpve-guest-common-perl: 6.0.3
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.5
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.1-1
proxmox-backup-file-restore: 4.2.1-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.3
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.7.5
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.16
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1