Note that this is for the latest focal debian-installer. Since there is
no hwe-netboot image the current focal installer is affected. I think an
hwe-netboot image for focal would resolve this issue for the installer.
--
You received this bug notification because you are a member of Kernel
** Also affects: linux
Importance: Undecided
Status: New
** Project changed: linux => debian-installer
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1940860
Title:
Mellanox
This also affects the ubuntu-installer when the `d-i base-
installer/kernel/override-image string linux-generic-hwe-20.04`
flag is added to preseed. The installer loads 5.4 kernel and configure
NICs using the 5.4 naming convention, then once the 5.11 kernel is
loaded and the host reboots
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1940860
Title:
Mellanox NIC interface names change
And here's some proposed text. I assume this would be applicable to the
release notes from 20.04->22.04
= Known Issues =
== Network Interface Names ==
Ubuntu generates [predictable interface
names](https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/)
by default.
Understood, thanks for considering the issue. Perhaps this just needs to
be release noted, warning users it may happen and how to avoid it (i.e.
implement their own set-name config)?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
I should say here that I don't really know what changes to subiquity are
desirable here. I don't really like the idea of subiquity always using
set-name, that just feels wrong, but I can see the problem here too.
--
You received this bug notification because you are a member of Kernel
Packages,
> we should be careful to ignore NICs with randomly generated MACs (see
bug 1936972).
ugh nics with LAA?
yeah, it can be hard to 'uniquely' identify a nic, especially since it's
so common to clone macs for bonds, bridges, vlans, and in some cases
even duplicate hw devices with the same nic (e.g.
@ddstreet I agree that systemd is behaving as designed. But I'm not sure
what the proper fix for this is, and therefore where changes would be
required.
My initial thought is that perhaps subiquity installs should do what
MAAS installs do and configure netplan to always use the install-time
systemd/udevd appears to be working exactly as advertised, using the
phys_port_name when it's provided by the device's kernel driver; should
this be marked invalid for systemd, or is there actually some change
needed there?
--
You received this bug notification because you are a member of Kernel
10 matches
Mail list logo