Automatic installation uses erratically different network device to fetch answer.toml via http

B

boulderproblem

New Member
Oct 14, 2025
4
0
1
Hi!
I'm trying to automate the installation of Proxmox VE following the instructions at https://pve.proxmox.com/wiki/Automated_Installation.

I encountered the following problem: The server on which proxmox should be installed has several network devices, each of which is assigned different address via DHCP. However, the answer.toml file is only accessible via http on eth0. Can I tell Proxmox (maybe via the proxmox-auto-install-assistant?) which network interface it should use? Currently, Proxmox seems to randomly use one or the other device during installation and cannot find the answer file.

Install log (similar to the log from this thread: https://forum.proxmox.com/threads/automated-install-never-makes-http-request-for-answer-file.161061/):

Code: 
Welcome to the Proxmox VE 9.0  (ISO 1) installer!                              |
initial setup startup                                                                                             |
mounting proc filesystem                                                                                          |
mounting sys filesystem                                                                                           |
EFI boot mode detected, mounting efivars filesystem                                                               |
boot comandline: BOOT_IMAGE=(tftp)os/proxmox/linux26 ramdisk_size=16777216 rw quiet splash=silent proxmox-start-auto-installer                                                                                     loading drivers:  nvidiafb ahci mac_hid acpi_pad wmi ipmi_si ipmi_ssif i2c_i801 ehci_pci intel_pch_thermal acpi_cp|
ufreq efi_pstore pcspkr intel_cstate rapl aesni_intel sha1_ssse3 sha256_ssse3 ghash_clmulni_intel polyval_clmulni |
crc32_pclmul crct10dif_pclmul kvm_intel intel_powerclamp x86_pkg_temp_thermal intel_rapl_common                   |
found proxmox ISO image inside initrd image                                                                       |
preparing installer mount points and working environment                                                          |
switching root from initrd to actual installation system                                                          |
Starting Proxmox installation                                                                                     |
EFI boot mode detected, mounting efivars filesystem                                                               |
Installing additional hardware drivers                                                                            |
Starting hotplug events dispatcher: systemd-udevd.                                                                |
Synthesizing the initial hotplug events (subsystems)...done.                                                      |
Synthesizing the initial hotplug events (devices)...done.                                                         |
Waiting for /dev to be fully populated...done.                                                                    |
mount: devpts mounted on /dev/pts.                                                                                |
/bin/dbus-daemon                                                                                                  |
starting D-Bus daemon                                                                                             |
Preparing DHCP as potential source to get location of automatic-installation answer file
Attempting to get DHCP leases... Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth3/0c:42:a1:19:a3:83
Sending on   LPF/eth3/0c:42:a1:19:a3:83
Listening on LPF/eth2/0c:42:a1:19:a3:82
Sending on   LPF/eth2/0c:42:a1:19:a3:82
Listening on LPF/eth1/0c:42:a1:19:a3:81
Sending on   LPF/eth1/0c:42:a1:19:a3:81
Listening on LPF/eth0/0c:42:a1:19:a3:80
Sending on   LPF/eth0/0c:42:a1:19:a3:80
Sending on   Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.48.100 from 192.168.48.1
DHCPREQUEST for 192.168.48.100 on eth1 to 255.255.255.255 port 67
DHCPOFFER of 192.168.48.200 from 192.168.48.1
DHCPREQUEST for 192.168.48.200 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.48.100 from 192.168.48.1
bound to 192.168.48.100 -- renewal in 129 seconds.
done

Thanks in advance!
 
Having a bunch of different interfaces on the same subnet with incomplete reachability between them is...sub-optimal. As you've noticed, since they are all on the same subnet the Linux kernel assumes they are equivalent and will just pick one to use for any given transaction.

Maybe disconnect all but the interface you want to use until it is installed?
 
Last edited:
Again, from your log it appears that there are multiple interfaces on the same subnet. If they are not actually all connected somehow, this can't work as you want it to (and is a bad idea to begin with). You can still do what you want by only connecting one interface during installation.

IOW, I don't think there is any magic kernel parameter or anything that will do what you want. I I'm wrong I'm sure somebody will correct me.
 
Code: 
DHCPOFFER of 192.168.48.100 from 192.168.48.1
DHCPREQUEST for 192.168.48.100 on eth1 to 255.255.255.255 port 67
DHCPOFFER of 192.168.48.200 from 192.168.48.1
DHCPREQUEST for 192.168.48.200 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.48.100 from 192.168.48.1

These two ports are getting an address from the same DHCP server, presumably they are both on the same /24 subnet. But if some things are reachable only from one of the interfaces, how is the kernel supposed to know that? Routing works on subnets, not on wishes.

If the same subnet does not mean same network, then you need to fix your network setup. Otherwise it is simply unworkable. Disconnect all but one interface or connect them all to the same switch, or set up correct routing.
 
  • Like
Reactions: cheiss
If I don't have physical access to the server, then I can't pull any cables during installation.
If the interfaces are connected to different subnets and there's a DHCP server in each one, then it would be the same, if the web server that provides the answer.toml via http is only accessible in one subnet?

Don't you think it would make sense to be able to specify the interface to use?
 
By having them on the same subnet you are telling the kernel routing that it doesn't matter which one it uses because they are all the same. If they aren't actually the same, then you will see what you are seeing. Kernel picks one arbitrarily, because you told it that it doesn't matter.
 
You must log in or register to reply here.
Top Bottom