MaaS v3.4, Enlistment fail for a machine with BIOS Legacy if PXE interface is the second one

Hey folks,

I’m playing with MaaS v3.4 (Snap, for now) and I noticed that the Enlistment stage fails for machines with BIOS Legacy if the PXE network interface is the second one (i.e., like eth1 or enp4s0). The same procedure works for UEFI.

It PXE-boots up correctly using enp4s0 (because Libvirt’s boot order is correct), but then it fails when the system running for the Enlistmentment stage first tries to DHCP on enp3s0, which gets the IP from Libvirt’s default network ( and then it fails to reach MaaS Rack on the PXE segment ( to download the image (the can not reach the isolated PXE network), which eventually drops to the (initramfs) prompt.

I tried to disable the DHCP from the default network, but then, the Enlistment process gives up, it never tries to get the IP from the enp4s0 which it PXE-booted from.

It’s interesting to note that this very same procedure/topology (i.e., with PXE in the second interface), with a Virtual Machine using the same virtual hardware networks, but with UEFI instead of BIOS, works as expected and it gets enlisted.

Back to the BIOS one, if I switch the “virtual cables” in Libvirt, plugging the enp3s0 into the PXE network, and the second interface on Libvirt’s default, then, it works, and it gets enlisted.

Having the PXE as the second interface is how I always did in past MaaS versions, and I’m wondering about what’s changed. I tried both Ubuntu 20.04 and 22.04 images for the Enlistment process, no difference.

Any suggestions?

Hi @tmartins!

Thank you for reporting this. Do you have some logs to share from the enlistment stage?

Hi, @r00ta!

Sure, I collected some screenshots, as follows:

1- Starting the process, PXE is the second interface, and Rackd logs are clean:

2- Here the machine PXE-booted but then failed because the Enlistment O.S. then obtained DHCP in the wrong (first) interface:

3- If I invert the “virtual cables”:

4- Then it gets enlisted:


I was able to reproduce your issue and I confirm this is definitely unexpected.

After the image is downloaded and started, it gets an IP from the DHCP server on the first interface and uses it.
This is why it fails to communicate to the maas server. I’ll report this on our bug tracker and get back to you when we find the root of the issue.

May I ask you if you also tried with a physical server? Or have you reproduced this only on virsh?

reported as

1 Like