iVentoy and Windows PXE setup notes

iventoy-vm-setup-instructions.md

iVentoy and Windows PXE Notes

Goal

Set up Windows network boot reliably on a proper VM after the current Alpine/LXC-style host proved unsuitable for iVentoy.

This file captures:

• what was learned from the current setup
• why the direct PXE attempts failed
• why iVentoy failed on this host
• the fastest clean setup path on a proper VM

Environment We Debugged

• PXE/TFTP/DHCP host IP: 172.15.2.2
• Test client MAC: bc:24:11:68:9b:d9
• Test client IP observed in logs: 172.15.2.178
• Existing services on host:
  • dnsmasq for DHCP/TFTP
  • apache2 on port 80
  • samba serving Windows install media
• Host OS characteristics:
  • Alpine userspace
  • Proxmox kernel
  • likely containerized or LXC-like restrictions

What Failed

1. Direct Microsoft UEFI PXE boot

UEFI PXE was initially pointed at Microsoft-style boot files such as:

• windows-secureboot/efi/boot/bootx64.efi
• Boot/BCD
• EFI/Microsoft/Boot/...

Symptoms:

• Windows error 0xc0000225
• blue Windows boot screen then shutdown
• repeated TFTP pulls followed by aborts

Host log pattern:

• client downloaded the Microsoft EFI loader
• client then requested BCD and multiple Secure Boot policy files
• transfer aborted during early boot chain

Conclusion:

Direct Microsoft UEFI PXE boot was not reliable in this environment. It kept failing before reaching a usable Windows setup environment.

2. UEFI HTTP boot from firmware

Symptoms from the VM firmware:

• Error: Could not retrieve NBP file size from HTTP server.
• Error: Server response timeout.

Conclusion:

UEFI firmware HTTP boot was not dependable here and was not the right path to continue.

3. netboot.xyz + iPXE on the current test VM

We changed UEFI PXE to iPXE and verified the VM did successfully load:

• ipxe/netboot.xyz-snponly.efi
• later ipxe/netboot.xyz.efi
• ipxe/autoexec.ipxe

That proves:

• DHCP was working
• TFTP was working
• iPXE did start

But Apache never saw any HTTP requests from the VM for:

• winpe.ipxe
• wimboot
• boot.wim

Conclusion:

The failure moved to the UEFI iPXE stage on the Proxmox VM. The client started iPXE but never completed the transition to HTTP. This looked like a guest firmware or NIC compatibility problem, not a Linux server problem.

4. iVentoy on the current host

We downloaded and unpacked iVentoy 1.0.21 and linked the Windows ISO into its iso directory.

Initial blockers on Alpine:

• BusyBox grep broke the launcher because it used grep -P
• missing runtime libs:
  • libevent
  • hivex
• missing glibc loader path until gcompat was installed

After fixing those, iVentoy still failed to start.

The key runtime log messages were:

• Failed to open file <./data/sys/class/dmi/id/product_uuid> errno:13
• read sys directory failed
• ### iVentoy start failed. ###

We also confirmed:

• /sys/class/dmi/id/product_uuid existed
• even root could not read it on this host
• file ownership looked container-restricted

Conclusion:

The current host is almost certainly containerized or LXC-restricted in a way that prevents iVentoy from reading DMI/sysfs data it expects. This is why iVentoy is a bad fit for the current host.

What Worked

Samba share for Windows media

This part was already correct and is still useful.

Share:

• [windows11]
• path: /srv/windows11
• guest-readable
• read-only

This matches the common Windows PXE pattern:

1. boot into WinPE
2. run wpeinit
3. map SMB share
4. launch setup.exe

ADK-built WinPE

The Windows ADK + WinPE add-on method succeeded on a Windows machine.

Artifacts copied back to Linux:

• /home/krad/tftp/BCD
• /home/krad/tftp/BOOTX64.EFI
• /home/krad/tftp/boot.sdi
• /home/krad/tftp/boot.wim

This remains the correct way to build a real WinPE image for network install workflows.

Important Conclusions

Secure Boot

Secure Boot was relevant to the earlier Microsoft boot-manager path, but it was not the reason iPXE failed later.

Why:

• when UEFI PXE was switched to iPXE, the VM successfully loaded the iPXE EFI binary and autoexec.ipxe
• if Secure Boot were blocking iPXE, it would have failed before that point

For iVentoy specifically:

• iVentoy does not support Secure Boot
• if using iVentoy, Secure Boot should be disabled

This host is the wrong place for iVentoy

The main reason is not PXE configuration anymore. It is host compatibility:

• Alpine/musl friction
• restricted sysfs/DMI access
• likely LXC/container limitations

Best practice:

• run iVentoy on a proper VM, not this current containerized host

Fastest Clean Path on a Proper VM

Use a dedicated Debian or Ubuntu VM on the same network and let iVentoy own the PXE service there.

Recommended VM

• Debian 12 or Ubuntu 22.04/24.04
• 2 vCPU
• 4 GB RAM
• 20 GB disk
• single NIC on the PXE VLAN/network
• Secure Boot disabled for client testing

Put this on the VM

1. The Windows ISO Example:

   • 26100.1_MULTI_X64_EN-GB.ISO

2. iVentoy Linux package Use the official release from:

   • https://github.com/ventoy/PXE/releases

Fast file source

There is an rsync server available to make copying the required files quick:

• 192.168.210.183::all

This can be used to pull:

• Windows ISO files
• WinPE artifacts
• any other staging files needed for the rebuild

Example browse:

rsync rsync://192.168.210.183/all

Example copy:

mkdir -p /srv/import
rsync -av 192.168.210.183::all/ /srv/import/

Basic setup on the proper VM

1. Install dependencies typically needed by iVentoy:

apt update
apt install -y wget tar

2. Download and unpack iVentoy:

cd /opt
wget https://github.com/ventoy/PXE/releases/download/v1.0.21/iventoy-1.0.21-linux-free.tar.gz
tar -xzf iventoy-1.0.21-linux-free.tar.gz
ln -sfn /opt/iventoy-1.0.21 /opt/iventoy

3. Put the Windows ISO into the iVentoy iso directory:

mkdir -p /opt/iventoy/iso
cp /path/to/26100.1_MULTI_X64_EN-GB.ISO /opt/iventoy/iso/

4. Start iVentoy:

cd /opt/iventoy
bash ./iventoy.sh start

5. Open the web UI:

• http://VM-IP:26000

6. Confirm it is listening:

ss -lntup

You should see iVentoy-related listeners, including the web UI and PXE-related services.

Network choices

You have two clean options:

Option A: Let iVentoy provide DHCP/PXE

Use this if the VM is isolated to the PXE network and there is no other DHCP server there.

This is the simplest iVentoy deployment.

Option B: Keep existing DHCP and use iVentoy as the boot server

Use this if DHCP already exists and should remain elsewhere.

In that case:

• leave DHCP on the existing server
• point PXE boot options at the iVentoy VM
• configure the boot filename according to the iVentoy documentation and client architecture

If you choose this option, keep only one active DHCP server on the PXE segment.

Suggested Client-Side Test Order

1. Disable Secure Boot in the test VM.
2. Use OVMF/UEFI firmware.
3. Prefer virtio NIC first for the test VM.
4. If virtio is problematic in firmware, try e1000 only as a fallback.
5. Boot by PXE from the iVentoy VM.
6. Select the Windows ISO from the iVentoy menu.

If You Stay With WinPE + SMB Instead of iVentoy

This is still a valid path.

High-level flow:

1. Build WinPE with Windows ADK + WinPE add-on.
2. Boot WinPE over PXE.
3. In WinPE shell:

wpeinit
net use F: \\172.15.2.2\windows11
F:\setup.exe

This path avoids some of the direct Microsoft PXE boot-manager issues.

Files and Config That Were Useful

On the Linux host

• dnsmasq config:
  • /etc/dnsmasq.d/netbootxyz-eth1.conf
• netboot.xyz local vars:
  • /opt/netboot.xyz/buildout/local-vars.ipxe
• WinPE iPXE script:
  • /opt/netboot.xyz/buildout/winpe.ipxe
• Samba config:
  • /etc/samba/smb.conf

WinPE artifacts copied from Windows

• /home/krad/tftp/BCD
• /home/krad/tftp/BOOTX64.EFI
• /home/krad/tftp/boot.sdi
• /home/krad/tftp/boot.wim

Windows install source

• /srv/windows11

ISO found on host

• /home/krad/26100.1_MULTI_X64_EN-GB.ISO

Final Recommendation

If the priority is speed and reliability:

1. Stop trying to run iVentoy on the current Alpine/LXC-style host.
2. Build a small Debian or Ubuntu VM on the PXE network.
3. Run iVentoy there with Secure Boot disabled on the client.
4. Keep the existing host only as a reference for the Windows files and WinPE artifacts if needed.

This is the shortest path to a clean retest.