Re: Inconsistent predictable interface names
- Date: Wed, 30 Aug 2017 11:37:30 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: Inconsistent predictable interface names
On Wed 30 Aug 2017 at 11:01:07 (-0400), Henning Follmann wrote:
> On Wed, Aug 30, 2017 at 04:12:16PM +0300, Reco wrote:
> > Hi.
> > On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> > > On 8/29/17, Reco <recoverym4n@xxxxxxxxx> wrote:
> > >
> > >
> > > 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.
> Yep, this was a new install. Even though I tend to reuse old configurations
> from previous installs, this very much happend with an untouched new
> install (only deviation from a "default" was xfce instead of gnome).
> I disabled the NM but at that time the names were already like they are
> right now.
> BTW. all those "try on disk" were sent to stderr and I piped only the
> stdout into my previous mail, that's why they were missing.
> > > 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.
> That was my initial thought.
> > 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.
> Yes, and I see that in dmesg happening for eth0. However that does not
> happen for the wlan0. I can see the firmware being loaded but no name
> changing to predictable pattern.
I see the name changes on these systems (a live stick and an
installation of stretch). What's odd is that the name of the
wireless interface is never reflected when its module is loaded
or reloaded; the first mention is always at the renaming moment.
This contrasts with the wired interface.
[ 3.930811] r8169 0000:01:00.0 eth0: RTL8168g/8111g at […]
[ 3.942793] r8169 0000:01:00.0 enp1s0: renamed from eth0
[ 18.689852] iwlwifi 0000:02:00.0: firmware: direct-loading firmware iwlwifi-7260-17.ucode
[ 18.691150] iwlwifi 0000:02:00.0: loaded firmware version 17.352738.0 op_mode iwlmvm
[ 19.399207] iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0
[ 111.424281] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, […]
[ 111.439912] tg3 0000:02:02.0 eth0: Tigon3 [partno(BCM95705A50) rev 3003] […]
[ 111.443209] tg3 0000:02:02.0 enp2s2: renamed from eth0
[ 134.994910] ipw2200 0000:02:04.0 wlp2s4: renamed from eth0
(selected lines only).