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 <recovery...@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 | hfollm...@itcfollmann.com
