FAI confused by DHCP on multiple network interfaces

[Justin Cattle]

Hi,


I don't think you mentioned if you are using syslinux or not, but if you
are, you can put something like this in your pxe config file:

ipappend 2

For an entire config might look like this:

default buster

label buster
kernel vmlinuz
ipappend 2
append initrd=initrd.img console=ttyS0,115200n8 console=tty0 ip=dhcp
root=1.2.3.4:/srv/fai/nfsroot/filesystem.dir rootovl
ixgbe.allow_unsupported_sfp=1 FAI_FLAGS=verbose,sshd,createvt,reboot
FAI_ACTION=install rd.net.timeout.carrier=20 rd.net.timeout.ifup=30



Cheers,
Just


On Thu, 18 Mar 2021 at 16:11, Steffen Grunewald <
steffen.grunewald at aei.mpg.de> wrote:

> 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
> <http://10.150.100.100/srv/fai/config/cluster-busterGATEWAYS=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
> ~~~
>

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses.

References to the 
"Ocado Group" are to Ocado Group plc (registered in England and Wales with 
number 7098618) and its subsidiary undertakings (as that expression is 
defined in the Companies Act 2006) from time to time. The registered office 
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, 
Hatfield, Hertfordshire, AL10 9UL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20210318/91d3bd4b/attachment.html>