Re: Inconsistent predictable interface names
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@gmail.com> 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.
FWIW
-H
--
Henning Follmann | hfollmann@itcfollmann.com
Reply to: