Instead of sanboot (which can't pass kernel params for automation),
switch back to kernel/initrd boot. The ISO is embedded in the initrd
as a CPIO append. A pxe-init wrapper script loop-mounts the ISO
before handing off to the original init, so the installer finds it
as a block device. Uses rdinit=/pxe-init kernel parameter.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Proxmox has no kernel parameter for HTTP ISO fetch. Instead, use
iPXE's sanboot command to present the ISO as a virtual CD over HTTP.
The installer finds it as a block device and boots normally.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Proxmox installer needs the full ISO to access packages and
installer data. Previously the ISO was deleted after extracting
kernel+initrd. Now we keep it as original.iso and serve it via HTTP.
The iPXE script passes proxmox-iso-url=<url> so the installer
fetches the ISO over the network instead of scanning block devices.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
iPXE needs --name on the initrd command and initrd=<name> on the
kernel line to properly pass the initrd to the kernel. Without this,
the kernel never receives the initrd, causing VFS mount failure.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Proxmox initrd is too large for the default ramdisk allocation,
causing VFS to fail mounting root. Add ramdisk_size=16777216 (16GB)
along with rw, quiet, and splash=verbose for proper installer boot.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
iPXE was stuck in a loop: boot iPXE -> DHCP -> get ipxe.0 again ->
boot iPXE -> repeat. Add tag:!ipxe to pxe-service directives so
iPXE clients get the HTTP script URL via dhcp-boot instead of being
served the bootloader again.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dhcp-boot alone does not send PXE vendor extensions (option 43) that
PXE clients need in proxy DHCP mode. Switch to pxe-service directives
for initial PXE boot, keep dhcp-boot only for iPXE chainloading.
Create .0 symlinks for pxe-service filename convention. Restore
dhcp-ignore=tag:!known filtering.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dnsmasq sees PXE requests but never responds. Remove the known-host
filter to determine if tag matching is the issue or if the problem
is elsewhere in the proxy DHCP flow.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bare MACs in dhcp-hostsfile were not auto-setting the known tag in
proxy DHCP mode, causing dhcp-ignore=tag:!known to drop all requests.
Explicitly write set:known per host entry.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove tag:known filter from dhcp-range — in proxy DHCP mode the tag
filter prevents responses. dhcp-ignore=tag:!known still filters
unknown hosts. Also copy ipxe.efi and undionly.kpxe from the system
ipxe package into the TFTP root at startup so clients can actually
download the bootloader.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dnsmasq exited with status 3 because the tftp-root directory didn't
exist at startup. Also replaced hardcoded 192.168.1.0 in dhcp-range
with the configured subnet value.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Upload Proxmox ISOs via API or dashboard UI, extract kernel+initrd
using pure-Go iso9660 library, store on disk, and serve over HTTP
for PXE booting. Dynamic kernel/initrd filenames per image replace
the previous hardcoded paths.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Generate a fresh ed25519 key pair at rebuild time, inject the public key
into the Proxmox answer file, use the private key for cluster join over
SSH, then remove the key from both the remote host and the database.
This eliminates the need to manage static SSH keys in config/secrets.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
josh