Hi Valentín, Thanks for opening the MR, prodding me, and then opening this bug report when requested; much appreciated! FWIW you could also have tagged it with an extra pseudoheader: “Tag: patch” for completeness, but that was a very nice report anyway. I've merged your MR and uploaded the package so that doesn't matter much now anyway. ;)
Valentín Gutierrez <vgutier...@wikimedia.org> (2019-02-05): > Since Predictable Network Interface Names[1] had been adopted in > stretch, BOOTIF is required in some multi NIC systems to hint the > installer the main NIC because string comparison fails to determine > the main interface. Independently of the current implementation, it might be good to rethink what we expect to be the main interface… Aren't we checking the link status anyway? > Take into consideration a system with the following NICs: enp59s0f0, > enp59s0f1d1, enp175s0f0 and enp175s0f1d1. > > Currently the debian installer considers enp175s0f0 as the first > interface instead of enp59s0f0 and therefore some operations during > the installation like network configuration via DHCP are wrongly > attempted using enp175s0f0. This behaviour can be fixed using BOOTIF > to signal the NIC used to boot the system, but BOOTIF shouldn't be > propagated to the installed system. So enp175s0f0 was picked up because it sorts first? If you have the details of the interface selection ready, another bug report would be great to keep track of this… > I've took the liberty of submitting a MR[2] to avoid BOOIF reaching > the installed system. Whether we fix heuristics regarding the interface that should be automatically configured (at least attempted), it seems that not forwarding this variable to the installed system makes sense, hence the merging and uploading. Thanks again! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
