On Wed, Oct 13, 2021 at 05:10:05PM -0000, Dan Streetman wrote:
> > udev can produce unpredictable network interface names by default when
> multiple devices map to the same slot due to an intermediate bridge.
>
> so, if I understand it right, the MR won't actually fix this for anyone
> without additional per-system work, right? specifically, any system with
> this problem will need to also add the 'net.naming-scheme=latest' boot
> parameter (or set it via systemd-udevd env var).
Correct.
> If that's the case, then it seems like a much simpler manual workaround
> for this would be to just avoid slot naming for the problematic nics,
> for example by dropping a link file into /etc/systemd/network/ with
> content like:
>
> [Match]
> Driver="whatever driver the DGX nics use, or use some other specific match"
>
> [Link]
> NamePolicy=keep kernel database onboard path
> AlternativeNamesPolicy=database onboard path
> MACAddressPolicy=persistent
>
>
> essentially, override the 99-default.link to remove 'slot' naming.
>
> > While MAAS does take care to always restore the names used during
> commissioning (eth3 will always be the same NIC on every deploy), these
> names can change each time the system is commissioned.
>
> if the only change needed is during maas comissioning, that seems like
> the perfect time to use a link file to override the specific problematic
> nics by whatever matching logic is best.
Such a link file would presumably do the trick, but how would one
insert such a file during (and early enough) in the commissioning
process?
On Wed, Oct 13, 2021 at 05:10:05PM -0000, Dan Streetman wrote: scheme= latest' boot
> > udev can produce unpredictable network interface names by default when
> multiple devices map to the same slot due to an intermediate bridge.
>
> so, if I understand it right, the MR won't actually fix this for anyone
> without additional per-system work, right? specifically, any system with
> this problem will need to also add the 'net.naming-
> parameter (or set it via systemd-udevd env var).
Correct.
> If that's the case, then it seems like a much simpler manual workaround network/ with sPolicy= database onboard path y=persistent
> for this would be to just avoid slot naming for the problematic nics,
> for example by dropping a link file into /etc/systemd/
> content like:
>
> [Match]
> Driver="whatever driver the DGX nics use, or use some other specific match"
>
> [Link]
> NamePolicy=keep kernel database onboard path
> AlternativeName
> MACAddressPolic
>
>
> essentially, override the 99-default.link to remove 'slot' naming.
>
> > While MAAS does take care to always restore the names used during
> commissioning (eth3 will always be the same NIC on every deploy), these
> names can change each time the system is commissioned.
>
> if the only change needed is during maas comissioning, that seems like
> the perfect time to use a link file to override the specific problematic
> nics by whatever matching logic is best.
Such a link file would presumably do the trick, but how would one
insert such a file during (and early enough) in the commissioning
process?