FAI confused by DHCP on multiple network interfaces

[Steffen Grunewald]

Hi all,

I'm trying to install an old machine in the basement - from home office,
not having a simple means to pull network plugs, just a static BMC address...

The machine is booted via PXE on *-network:0 (in "lshw"'s terms), and gets
started properly. But then things go downhill a bit, although the install
is successful - it's IPADDR that gets mangled, resulting in a chain of
wrong network settings (and the machine won't boot properly into a state
I could connect to).

Here's the boot.log returned to the server after installation:

# cat boot.log
netdevices_all="eth0 eth1 "
netdevices_up="eth0 eth1 "
netdevices="eth0 eth1 "
BROADCAST='10.150.255.255'
DOMAIN='hypatia.local'
DNSSRVS='...'
DNSSRVS_1='...'
IPADDR='10.150.100.210'
NETWORK='10.150.0.0'
NTPSRVS='10.150.100.190'
NTPSRVS_1='10.150.100.190'
SERVER='faiserver'
NETMASK='255.255.0.0'
IPADDR=172.16.22.77
SERVER=
NETMASK=255.255.0.0
GATEWAYS=172.16.1.1
BROADCAST=172.16.255.255
CIDR=172.16.22.77/16
NIC1=eth1

All is fine (the DNS server is set by DHCP) - until the addition of the
second IPADDR entry (which indeed belongs to the second NIC).
Everything that sources boot.log afterwards gets affected by this mistake,
and variables.log reads a bit strange:

# cat variables.log | grep '^[A-Z].*\..*\..*\..*'
BROADCAST=172.16.255.255
CIDR=172.16.22.77/16
DNSSRVS=...
DNSSRVS_1=...
FAI_CONFIG_SRC=nfs://10.150.100.100/srv/fai/config/cluster-buster
GATEWAYS=172.16.1.1
IP1ADDR=172.16.22.77
IPADDR=172.16.22.77
NETMASK=255.255.0.0
NETWORK=10.150.0.0
NTPSRVS=10.150.100.190
NTPSRVS_1=10.150.100.190
SERVER=10.150.100.100

The FAI version in the Debian Buster NFSROOT is 5.9.4, the NFSROOT was
created (and copied to the non-X86_64 server) on Feb 11.

Is this a known problem? How can I force the setup back to using the initial
IPADDR, obtained from the DHCP/TFTP server that is used for the install?
(I vaguely remember there's a way to feed this into the pxelinux.cfg file
but ideally I should not need to know whether there are responses from other
DHCP servers, and if there are any, they should not overwrite IPADDR - with
a value identical to IP1ADDR.)

Patches (to be applied directly to the NFSROOT) are welcome!

Thanks,
 Steffen

 
-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany
~~~
Fon: +49-331-567 7274
Mail: steffen.grunewald(at)aei.mpg.de
~~~