Full clone of UEFI Windows template on LVM-thin results in unbootable VM with corrupted partition table

B

bozkalkan

New Member
May 22, 2025
2
2
3
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
 
Hi @bozkalkan

thanks for posting in the forum!

I just tried to reproduce your issue on my end, but in my case it worked perfectly.
Did you change anything in your /etc/lvm/lvm.conf? Especially the parameter thin_pool_zero

Can you also please share a little details on your storage and hardware configuration.

For reference there is already a similar bugreport, so feel free to attach to this one [1]

Yours sincerely
Jonas

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=7275
 
bozkalkan said:
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
Click to expand...


Just setting some background, we massively depend on deploying 200-600 VMs for Student Labs, sop dependant upon CLONE. (Full Clones).

When we were last deploying massive clones in May, Linux and Windows all was working fine.

But today we've had massive issues, templates created in May 2026, CLONE fine, and start fine.

Today creating a new Ubuntu 26 LTS Server, UEFI - Master Boots fine, BUT if we CLONE via GUI or CLI - it fails because the UEFI disk is not copied/cloned correctly, there is a mismatch in the resulting disk to original.

All datastores are NFS (NetApp), NFS (PowerStore)

This post, seems very similar, not tested any Windows 2025 yet.
 
You must log in or register to reply here.
Top Bottom
Back