[SOLVED] Auto-Install fetching FQDN through DHCP does not set search domain correctly.

P

PartitionPrankster

New Member
Jul 11, 2025
3
0
1
Hey,
I am trying to install the latest PVE automatically.
I don't want to set FQDNs in my answer.toml file, but instead want the nodes to obtain their hostname via DHCP.

I therefore added this to my answer file:
Code: 
fqdn.source = "from-dhcp"

If I set anything as fqdn.domain:
Code: 
fqdn.domain = "example.com"
Then I would expect the installer to only use this search domain, if none is returned by DHCP.

Instead, the installer seems to append the search domain I specify to the search domain I receive from DHCP.
At least I then end up with an /etc/resolv.conf looking like this:
Code: 
search proxmox.internal.example.com.example.com

If instead I don't specify "fqdn.domain" at all, then somehow I end up without a search domain at all.
My node then is only called "pve" and the search domain becomes "search example.invalid".

My DHCP config:

Code: 
host n-1.proxmox.internal.example.com {
    option domain-name "proxmox.internal.example.com";
    hardware ethernet <my mac address>;
    fixed-address 192.168.1.25;
}

I would expect PVE to either only use the domain I define in my toml-file, or to only use the search domain from DHCP, but it somehow concats them with a ".".


Am I using it wrong, or did I somehow run into a bug?

Thanks a lot upfront :)
 
PartitionPrankster said:
My DHCP config:
Click to expand...
I assume VyOS? (Or some proprietary fork?)

Does the machine have multiple network interfaces?
Are multiple connected and can potentially get a DHCP lease?

Can you maybe boot into the debug mode (Advanced Options > Install Proxmox VE (.., Debug Mode)), press Ctrl+D at the first shell prompt (may need to press enter to see it) and then at the second prompt run dhclient -v; cat /var/lib/dhcp/dhclient.leases, and post the output of that?

This prints the actual lease information as received, maybe there is something funky going on there.

I did the following tests with the latest 8.4-1 ISO and the DHCP server serving test as hostname and localdomain as domain:
- fqdn.source = "from-dhcp", -> hostname -f reported test.localdomain
- fqdn = { source = "from-dhcp", domain = "example.com" } -> hostname -f reported test.example.com
 
cheiss said:
I assume VyOS? (Or some proprietary fork?)
Click to expand...
It's a DHCP-Server running on an Ubuntu machine called "isc-dhcp-server".
cheiss said:
Does the machine have multiple network interfaces?
Are multiple connected and can potentially get a DHCP lease?
Click to expand...
There are multiple network interfaces, but only one can get a lease, as the DHCP is configured to only hand out IPs where Reservations based on the Mac Adress were done.
cheiss said:
Can you maybe boot into the debug mode (Advanced Options > Install Proxmox VE (.., Debug Mode)), press Ctrl+D at the first shell prompt (may need to press enter to see it) and then at the second prompt run dhclient -v; cat /var/lib/dhcp/dhclient.leases, and post the output of that?
Click to expand...
Sure:
Code: 
type
'exit' or press CTRL + D to continue and start the installation wizard
root@proxmox:/# dhclient -v; cat /var/lib/dhcp/dhclient.leases
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium
All rights reserved.
For into, please visit https://www.isc.org/software/dhcp/

[179.605410] bnxt_en 0000:06:00.1 ens3f1np1: NIC Link is Up, 10000 Mbps (NRZ) full duplex, Flow control: none
[179.606384] bnxt_en 0000:06:00.1 ens3f1np1: FEC autoneg off encoding: None
[179.790800] bnxt_en 0000:06:00.0 ens3f0np0: NIC Link is Up, 10000 Mbps (NRZ) full duplex, Flow control: none
[179.791806] bnxt_en 0000:06:00.0 ens3f0np0: FEC autoneg off encoding: None
istening on LPF/ens3f1np1/5c:6f:69:f1:0a:a1
Sending on LPF/ens3f1np1/5c:6f:69:f1:0a:a1
istening on LPF/ens3f0np0/5c:6f:69:f1:0a:a0
Sending on LPF/ens3f0np0/5c:6f:69:f1:0a:a0
istening on LPF/eno2p1/38:68:dd: 77:32:79
Sending on LPF/eno2p1/38:68:dd: 77:32:79
Listening on LPF/eno1p0/38:68:dd: 77:32:78
Sending on LPF/eno1p0/38:68:dd: 77:32:78
sending on Socket/fallback
DHCPDISCOVER on ens3f1np1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on ens3f1np1 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eno2np1 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eno1np0 to 255.255.255.255 port 67 interval
DHCPOFFER of 10.12.249.122 from 10.12.249.251
DHCPREQUEST for 10.12.249.122 on eno1np0 to 255.255.255.255 port 67
DHCPACK of 10.12.249.122 from 10.12.249.251
bound to 10.12.249.122 -- renewal in 172448 seconds.
lease {
  interface "eno1np0";
  fixed-address 10.12.249.122;
  filename "undionly.kpxe";
  option subnet-mask 255.255.255.0;
  option routers 10.12.249.1;
  option dhcp-lease-time 432000;
  option unknown-208 f1:0:74:7e;
  option dhcp-message-type 5;
  option loader-configfile "pxelinux.cfg/menu";
  option domain-name-servers 10.0.0.53;
  option dhcp-server-identifier 10.12.249.251;
  option broadcast-address 10.12.249.255;
  option host-name "n-1.proxmox.internal.example.com";
  option domain-name "proxmox.internal.example.com";
  renew 4 2025/07/17 08:32:05;
  rebind 6 2025/07/19 17:37:50;
  expire 0 2025/07/20 08:37:50;
}
root@proxmox: /#

I got that by doing text-recognition on a screenshot of the output. So it could be, that there are some typos in, but I gave my best to correct all typos in the text above.
 
PartitionPrankster said:
I got that by doing text-recognition on a screenshot of the output. So it could be, that there are some typos in, but I gave my best to correct all typos in the text above.
Click to expand...
Thanks! (In circumstances like this, a readable photo or screenshot can also work :))

PartitionPrankster said:
Code: 
option host-name "n-1.proxmox.internal.example.com";
option domain-name "proxmox.internal.example.com";
Click to expand...
This seems to be the culprit. ISC is apparently sending the hostname including the search domain. According to RFC 2132 Section 3.14, the host name can include the local domain name, it seems. But the current behaviour is to rely on that it doesn't include it, definitely a oversight/bug.

I could reproduce it using OPNsense, by manually setting the hostname to the FQDN as isc-dhcp-server does it. I'll work on a fix.

PartitionPrankster said:
If instead I don't specify "fqdn.domain" at all, then somehow I end up without a search domain at all.
My node then is only called "pve" and the search domain becomes "search example.invalid".
Click to expand...
That also shouldn't happen - in this case, at least the hostname should be carried over IMO. I'll work on a fix for that too.

If you need an immediate workaround - you can include a small (probably one-line) shell script using the First Boot Hook, setting the correct hostname/domain name combo on the very first boot after installation.

Thanks for the report and the debugging!

And just FWIW: the original isc-dhcp-* packages are deprecated and effectively dead, having been replaced by Kea: https://www.isc.org/dhcp/
So you might want to migrate.
 
Amazing. Thank you so much for fixing it already.

Until the fix is released, I actually worked around it, by having my webserver generate the answers-file on the fly.
I do a DNS-Reverse-Lookup of the requesting IP and place that hostname as "fqdn" in the answers file for now.

Thanks a lot for the hint on the deprecation of isc-dhcp-server too. As it currently runs on Ubuntu 20.04, which also reached EOL, an upgrade should happen rather soon ;)
 
You must log in or register to reply here.
Top Bottom