Enlistment fail for a machine with BIOS Legacy if PXE interface is the second one

[Jacopo Rota]

As per discourse post https://discourse.maas.io/t/maas-v3-4-enlistment-fail-for-a-machine-with-bios-legacy-if-pxe-interface-is-the-second-one/7243 ,

maas fails to enlist the machine if it has two interfaces and it boots from the second one (with BIOS). THe user reports that with UEFI it works fine instead.

From a first analysis, it seems that after the machine boots from PXE it gets an IP from the (non MAAS) DHCP server running on the first interface instead of getting it from the second interface where the MAAS DHCP server is running (see screenshot).

[Benjamin Drung (bdrung)]

What kernel command line parameters are used? configure_network from initramfs-tools tries to bring up at least one device before declaring success. If you rely on one specific device to be up, you can specify it with `ip=` on the kernel command line.

[Jacopo Rota (r00ta)]

Hi Benjamin,

we have

nomodeset ro root=squash:http://172.16.99.2:5248/images/ubuntu/amd64/ga-20.04/focal/stable/squashfs ip=:::master-cougar:BOOTIF ip6=off overlayroot=tmpfs overlayroot_cfgdisk=disabled cc:{'datasource_list': ['MAAS']}end_cc cloud-config-url=http://172-16-99-0--24.maas-internal:5248/MAAS/metadata/latest/by-id/wd4x7g/?op=get_preseed apparmor=0 log_host=172.16.99.2 log_port=5247 --- BOOTIF=01-52:54:00:78:19:37

We craft this cmdline programmatically in MAAS BUT we don't have the information about the boot interfaces of the machines yet - there is no way for us to specify a device in that cmdline at this stage.

[Benjamin Drung (bdrung)]

You have BOOTIF specified on the command line. The device with that MAC address will be used unless overridden by the ip= parameter. The best documentation for the ip= parameter can be found in https://git.kernel.org/pub/scm/libs/klibc/klibc.git/tree/usr/kinit/ipconfig/README.ipconfig

"ip=:::master-cougar:BOOTIF" sets netmask=master-cougar and hostname=BOOTIF. It looks like a colon is missing there. "ip=::::master-cougar:BOOTIF" would set hostname=master-cougar and device=BOOTIF. If you want to use BOOTIF, device should be kept empty instead.

So I suggest trying with "ip=::::master-cougar::dhcp" instead. If you want to rely on the DHCP server to set the hostname, you can just specify "ip=dhcp" instead.

[Jacopo Rota (r00ta)]

Thank you very much Benjamin! Now I get it. With your feedback I was able to find the problem on our side.

In short, the mac address we specify in the cmdline is wrong. When the machine asks for tftp resources, it communicates also the mac address. However, it communicates the mac address of the first interface and not the one that was used to pxe boot the machine: that's the bug.

[Jacopo Rota (r00ta)]

The issue is in the iPXE bootloader configuration that we send to the machine: https://git.launchpad.net/maas/tree/src/provisioningserver/boot/ipxe.py#n22 .

In particular, we ask the machine to send an http request appending the `net0/mac` address, but as per title of the bug, if the boot interface is not the first one it is going to communicate the wrong mac address.

I have to check if it's possible to extract the mac address of the booted interface with ipxe

[Benjamin Drung (bdrung)]

I know that syslinux has the "ipappend 2" option to set BOOTIF, but I do not know if ipxe has an equivalent.

[Jacopo Rota (r00ta)]

asked ipxe community a clarification https://github.com/ipxe/ipxe/discussions/995 and waiting for reply.

[Jacopo Rota (r00ta)]

According to the discussion above, I'll go for the `mac` setting that in our specific case should do the job