Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

Bug #2037202 reported by Marian Rainer-Harbach
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I'm not sure whether this is the correct package for this bug, please reassign if not.

I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in order to perform an unattended installation. The kernel command line looks like that:

iso/casper/vmlinuz --- ip=dhcp netboot=nfs nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=<removed>

This has worked perfectly before. However, in 23.10, the kernel tries to intialize DHCP before a network link is up.

I can see a few instances of messages like the following:
dhcpcd-10.0.2 starting
dev: loaded udev
no interfaces have a carrier
exiting due to oneshot
dhcpcd exited

Then, the kernel tries to mount NFS, even though neither an IP address nor even a link is available:
connect: Network is unreachable
NFS over TCP not available from 192.168.1.1

This is repeated for a while. In between, a message tells that now the link is up:
[ 10.0002805] e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

The NFS messages repeat for a while, until the system gives up and I'm dropped into a busybox prompt.

Executing dhcpcd now correctly gets IP addresses, but I don't know how to continue the boot from there.

The problem occurs on most physical machines that I tried, but not in VMs.

Related branches

tags: added: mantic
description: updated
Benjamin Drung (bdrung)
tags: added: rls-mm-incoming
Revision history for this message
Marian Rainer-Harbach (marianrh) wrote :

As a workaround, I added a `sleep 1` at the end of `_set_available_devices_to_up()` in `scripts/functions` in the Mantic initrd.

tags: added: foundations-todo
removed: rls-mm-incoming
Revision history for this message
Adrien Nader (adrien) wrote :

Should dhcp really be oneshot? I don't know what dhclient was doing (I guess it was dhclient before) but it sounds difficult to synchronize this properly. I imagine it's also possible to run the dhcp client in oneshot mode in a loop with maybe 3 iterations and "sleep 1" in between.

Revision history for this message
Marian Rainer-Harbach (marianrh) wrote :

If I understand the process correctly, dhcpcd is already run in a loop. But the loop is over too quickly if the interface takes a few seconds to come up.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I request this to be considered release critical, as this prevents all kernel team & certification team deployments of mantic systems, inhibiting our ability to test SRUs on all architectures.

tags: added: rls-mm-incoming
Revision history for this message
Adrien Nader (adrien) wrote :

Thanks for the precision Marian.

Dimitri, do you know if the "sleep 1" works in practice?

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Is the point here that dhcpcd -1 exits immediately if it finds no devices, even if it has a -t argument?

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.142ubuntu15

---------------
initramfs-tools (0.142ubuntu15) mantic; urgency=medium

  * scripts/functions: do not fail to configure networking too quickly. In
    particular make sure an unsuccessful attempt to run DHCP takes at least
    $ROUNDTTT seconds. (LP: #2037202)

 -- Michael Hudson-Doyle <email address hidden> Wed, 04 Oct 2023 12:02:13 +1300

Changed in initramfs-tools (Ubuntu):
status: New → Fix Released
Revision history for this message
Marian Rainer-Harbach (marianrh) wrote :

I tested on two machines where the boot failed previously. With the new `scripts/functions`, the boot now works properly. Thanks you!

Benjamin Drung (bdrung)
tags: removed: foundations-todo
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.