Re: Inconsistent predictable interface names
Hi.
On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> On 8/29/17, Reco <recoverym4n@gmail.com> wrote:
> >
> > On Tue, Aug 29, 2017 at 01:04:06PM -0400, Henning Follmann wrote:
> >> On Tue, Aug 29, 2017 at 07:45:41PM +0300, Reco wrote:
> >> >
> >> > On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
> >> > > Hello,
> >> > > I am experiencing an odd issue with a new install of Stretch.
> >> > > I do get the new predictable interface name for my ethernet (enp3s0).
> >> > > However I still have the old name for the wireless network card
> >> > > (wlan0).
> >> > > So I checked /etc/systemd/network if there is any .link file, there
> >> > > isn't.
> >> > > Also grub is configured correctly ("quiet" being the only kernel
> >> > > parameter).
> >> > > Where else might I have to check and which program might be
> >> > > overwriting
> >> > > this?
> >> >
> >> > Please post the output of this (root is needed):
> >> >
> >> > udevadm test /sys/class/net/wlan0
> >>
> >> ========================================================
> >> This program is for debugging only, it does not run any program
> >> specified by a RUN key. It may show incorrect results, because
> >> some values may be different, or not available at a simulation run.
> >>
> >> ACTION=add
> >> DEVPATH=/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0/net/wlan0
> >> DEVTYPE=wlan
> >> ID_BUS=pci
> >> ID_MM_CANDIDATE=1
> >> ID_MODEL_FROM_DATABASE=BCM4322 802.11a/b/g/n Wireless LAN Controller
> >> (AirPort Extreme)
> >> ID_MODEL_ID=0x432b
> >> ID_NET_DRIVER=b43
> >> ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
> >> ID_NET_NAME_MAC=wlxd8a25e8dabb1
> >> ID_OUI_FROM_DATABASE=Apple, Inc.
> >> ID_PATH=pci-0000:02:00.0
> >> ID_PATH_TAG=pci-0000_02_00_0
> >> ID_PCI_CLASS_FROM_DATABASE=Network controller
> >> ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
> >> ID_VENDOR_FROM_DATABASE=Broadcom Limited
> >> ID_VENDOR_ID=0x14e4
> >> IFINDEX=3
> >> INTERFACE=wlan0
> >> SUBSYSTEM=net
> >> SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlan0
> >> TAGS=:systemd:
> >> USEC_INITIALIZED=16526604
> >> run: 'ifupdown-hotplug'
> >> run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlan0
> >> --prefix=/net/ipv4/neigh/wlan0 --prefix=/net/ipv6/conf/wlan0
> >> --prefix=/net/ipv6/neigh/wlan0'
> >
> > Hm. This particular output seems to lack 'trie on-disk' blurb that shows
> > exact udev configuration files that could influence its decision, but
> > that's pure cosmetic.
> > The main difference from the hardware I have access to is the lack of
> > ID_NET_NAME and ID_NET_NAME_PATH attributes.
> >
> > Presumably that's because this particular class of PCI devices is not
> > recognised by net_id and net_setup_link udev builtins as a valid NIC.
> > It could be fixed in newer udev, or not.
> >
> > Long story short - you've found a udev bug.
> >
> > A good thing is - it has as easy workaround as creating a .link file
> > like this:
> >
> > [Match]
> > MACAddress=d8:a2:5e:8d:ab:b1
> > [Link]
> > Name=enp2s0
> >
> > Or whatever 'predictable' name you prefer. I believe that in your
> > conditions 'wlan0' is predictable enough ☺.
>
>
> I left everything in there in case somehow it already says "yes or
> no". Is it possible that's previously declared somewhere, possibly
> maybe in user configuration files that would carry over from upgrade
> to upgrade?
OP's e-mail says to this:
> > I am experiencing an odd issue with a new install of Stretch.
My e-mails assumed that there was no upgrade.
'udevadm info' should've shown such stray configuration files BTW, hence
'trie on-disk' remark.
> Maybe like something manually altered via a network
> manager at some point... or something....? :)
That's possible. Network Manager's ability to change MAC address of WLAN
(for AP scanning), or, say, machanger intervention can lead to funny
results if "Predictable" NIC Names are enabled. I haven't seen it
manifested in NIC renaming though.
It should not be possible in this case (all NICs are PCI devices) since
"Predictable" NIC Names should set by udev from initrd long before root
filesystem is mounted and things like Network Manager have a chance to
interfere.
Reco
Reply to: