Incorrect netboot initrd being autodownloaded

We’re using Dell TB16 Thunderbolt docks with Dell XPS ultrabooks, to provide an Ethernet port with MAC address passthrough (these models have only USB-C/Thunderbolt 3 ports onboard) during Foreman PxE-based provisioning.

Our chosen Ubuntu distro (18.04.2 LTS) natively supports the r8152 driver module required for this setup, and we have configured as the installation media, against the ‘bionic’ release name. Foreman is successfully downloading and using ‘initrd.gz’ & ‘linux’ files from ‘/dists/bionic/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/’, renamed to match our media name, however they do not contain the r8152 module.

Two days digging later, and I have been able to establish the problem: Foreman is not correlating the ‘bionic-updates’ directory structure against the base ‘bionic’ directory structure when it retrieves the ‘initrd.gz’ & ‘linux’ files, and therefore ends up using retired versions from April 2018, rather than the current versions.

I have manually wget-ed the current versions, overwritten Foreman’s files within …/tftpboot/boot, and chown-ed them to have identical permissions, and the r8152 driver module is able to successfully load and complete the provisioning task, but I am concerned that this might not be the correct course of action, and also that it might not be persistent.

Expected outcome: Foreman automatically chooses the more current versions of ‘initrd.gz’ & ‘linux’ from a source’s netboot provision, when available in an adjacent directory structure.

Foreman and Proxy versions:
1.21.3 (single standalone server)

Foreman and Proxy plugin versions:
foreman-tasks 0.14.5
foreman_ansible 2.3.6
foreman_discovery 14.0.1
foreman_remote_execution 1.7.0

Other relevant data: n/a

This is a valid workaround and it is persistent because Foreman only downloads these files once.

I think this is a problem with logic for Operatingsystem family being the same when they actually have a different behavior. Red Hat family these files will only change with minor versions (with rare exception where the files in the original location get replaced). If also Debian has the same behavior a change would be possible, but it would not be trivial as the download once behavior of the TFTP Smart Proxy has to be changed to compare checksum and re-download.


Thanks Dirk. Do you think I should submit this as a feature/bug or just stick with the workaround?

There are already some ideas / tickets about rewriting, so adding one with the specific handling for Ubuntu (or if you can confirm the same behavior for Debian for the Debian family) will make the rewrite even better. So yes, please create one as a feature request.

It seems that Debian does not use this method, so it would be an Ubuntu-specific use case.