[gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Howdy all,

First, if anyone is planning to switch a remote machine, you may want to
delay that. 

As some, most, know eudev is being removed.  I can't say how much I
dislike that but it seems to be happening despite some are saying it is
still being maintained upstream.  During my weekly update today, eudev
was masked and the virtual wanted systemd, which I do not want at all,
so I knew it was time to switch.  I do my updates in a chroot so that I
can just install binaries on my main system.  Everything went well in
the chroot.  No problems there.  However, when I switched in the real
system, no network.  Everything else seems to work but when I try to
bring up net.eth0, it pukes on my keyboard about a missing driver.  Keep
in mind, I was using the same kernel as before.  The only difference,
switching to udev.  Also, I switched to udev not systemd as a whole.  I
unmerged eudev, emerged udev with some little friends.

I suspect there is some sort of name change, config change or something
required that everyone else did ages ago.  I'm still using as you might
have noticed, net.eth0 for the name.  Thing is, it's all I have here. 
By the way, switching back to eudev got me connected with no problems. 
Some info.


root@fireball / # ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.100  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 secret stuff  prefixlen 64  scopeid 0x20<link>
        ether secret stuff  txqueuelen 1000  (Ethernet)
        RX packets 7841  bytes 9076941 (8.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7436  bytes 748477 (730.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  memory 0xfe3c0000-fe3e0000 

root@fireball / # ls -al /etc/init.d/net*
lrwxrwxrwx 1 root root     6 Mar  1  2012 /etc/init.d/net.eth0 -> net.lo
lrwxrwxrwx 1 root root    18 Oct 12  2013 /etc/init.d/net.eth1 ->
/etc/init.d/net.lo
-rwxr-xr-x 1 root root 19861 Nov 18 20:38 /etc/init.d/net.lo
-rwxr-xr-x 1 root root  2071 Nov 19 06:38 /etc/init.d/netmount
-rwxr-xr-x 1 root root  2278 Nov 19 06:38 /etc/init.d/net-online
root@fireball / #


Of course that is with eudev not udev.  Hard to post udev when it isn't
working.  ;-)  This is the emerge logs.


1638112926: Started emerge on: Nov 28, 2021 09:22:06
1638112926:  *** emerge --oneshot --unordered-display --ask
--backtrack=100 --jobs=5 --keep-going --with-bdeps=y --quiet-build=n
--regex-search-auto=y --usepkg --verbose udev
1638112961:  >>> emerge (1 of 9) acct-group/kmem-0-r1 to /
1638112961:  >>> emerge (2 of 9) acct-group/tty-0-r1 to /
1638112961:  >>> emerge (3 of 9) acct-group/audio-0-r1 to /
1638112961:  >>> emerge (4 of 9) acct-group/cdrom-0-r1 to /
1638112961:  >>> emerge (5 of 9) acct-group/dialout-0-r1 to /
1638112962:  === (1 of 9) Merging Binary
(acct-group/kmem-0-r1::/var/cache/portage/packages/acct-group/kmem-0-r1.tbz2)
1638112963:  === (2 of 9) Merging Binary
(acct-group/tty-0-r1::/var/cache/portage/packages/acct-group/tty-0-r1.tbz2)
1638112965:  === (4 of 9) Merging Binary
(acct-group/cdrom-0-r1::/var/cache/portage/packages/acct-group/cdrom-0-r1.tbz2)
1638112965:  === (5 of 9) Merging Binary
(acct-group/dialout-0-r1::/var/cache/portage/packages/acct-group/dialout-0-r1.tbz2)
1638112965:  === (3 of 9) Merging Binary
(acct-group/audio-0-r1::/var/cache/portage/packages/acct-group/audio-0-r1.tbz2)
1638112966:  >>> emerge (6 of 9) acct-group/disk-0-r1 to /
1638112967:  === (6 of 9) Merging Binary
(acct-group/disk-0-r1::/var/cache/portage/packages/acct-group/disk-0-r1.tbz2)
1638112977:  >>> emerge (7 of 9) acct-group/tape-0-r1 to /
1638112978:  === (7 of 9) Merging Binary
(acct-group/tape-0-r1::/var/cache/portage/packages/acct-group/tape-0-r1.tbz2)
1638112980:  >>> AUTOCLEAN: acct-group/kmem:0
1638112982:  >>> AUTOCLEAN: acct-group/cdrom:0
1638112991:  === (1 of 9) Post-Build Cleaning
(acct-group/kmem-0-r1::/var/cache/portage/packages/acct-group/kmem-0-r1.tbz2)
1638112991:  ::: completed emerge (1 of 9) acct-group/kmem-0-r1 to /
1638112991:  === (4 of 9) Post-Build Cleaning
(acct-group/cdrom-0-r1::/var/cache/portage/packages/acct-group/cdrom-0-r1.tbz2)
1638112991:  ::: completed emerge (4 of 9) acct-group/cdrom-0-r1 to /
1638113005:  >>> AUTOCLEAN: acct-group/tty:0
1638113009:  >>> AUTOCLEAN: acct-group/audio:0
1638113018:  === (2 of 9) Post-Build Cleaning
(acct-group/tty-0-r1::/var/cache/portage/packages/acct-group/tty-0-r1.tbz2)
1638113018:  ::: completed emerge (2 of 9) acct-group/tty-0-r1 to /
1638113018:  === (3 of 9) Post-Build Cleaning
(acct-group/audio-0-r1::/var/cache/portage/packages/acct-group/audio-0-r1.tbz2)
1638113018:  ::: completed emerge (3 of 9) acct-group/audio-0-r1 to /
1638113032:  >>> AUTOCLEAN: acct-group/dialout:0
1638113035:  >>> AUTOCLEAN: acct-group/disk:0
1638113043:  === (5 of 9) Post-Build Cleaning
(acct-group/dialout-0-r1::/var/cache/portage/packages/acct-group/dialout-0-r1.tbz2)
1638113043:  ::: completed emerge (5 of 9) acct-group/dialout-0-r1 to /
1638113043:  === (6 of 9) Post-Build Cleaning
(acct-group/disk-0-r1::/var/cache/portage/packages/acct-group/disk-0-r1.tbz2)
1638113043:  ::: completed emerge (6 of 9) acct-group/disk-0-r1 to /
1638113049:  >>> AUTOCLEAN: acct-group/tape:0
1638113055:  === (7 of 9) Post-Build Cleaning
(acct-group/tape-0-r1::/var/cache/portage/packages/acct-group/tape-0-r1.tbz2)
1638113055:  ::: completed emerge (7 of 9) acct-group/tape-0-r1 to /
1638113055:  >>> emerge (8 of 9) sys-fs/udev-249-r3 to /
1638113056:  === (8 of 9) Merging Binary
(sys-fs/udev-249-r3::/var/cache/portage/packages/sys-fs/udev-249-r3.tbz2)
1638113063:  >>> AUTOCLEAN: sys-fs/udev:0
1638113072:  === (8 of 9) Post-Build Cleaning
(sys-fs/udev-249-r3::/var/cache/portage/packages/sys-fs/udev-249-r3.tbz2)
1638113072:  ::: completed emerge (8 of 9) sys-fs/udev-249-r3 to /
1638113072:  >>> emerge (9 of 9) virtual/udev-217-r3 to /
1638113073:  === (9 of 9) Merging Binary
(virtual/udev-217-r3::/var/cache/portage/packages/virtual/udev-217-r3.tbz2)
1638113081:  >>> AUTOCLEAN: virtual/udev:0
1638113081:  === Unmerging... (virtual/udev-217-r3)
1638113087:  >>> unmerge success: virtual/udev-217-r3
1638113093:  === (9 of 9) Post-Build Cleaning
(virtual/udev-217-r3::/var/cache/portage/packages/virtual/udev-217-r3.tbz2)
1638113093:  ::: completed emerge (9 of 9) virtual/udev-217-r3 to /
1638113093:  *** Finished. Cleaning up...
1638113098:  *** exiting successfully.
1638113098:  *** terminating.


This is the network part of lspci -k and I'm using the top one:


03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
        Subsystem: Intel Corporation Gigabit CT Desktop Adapter
        Kernel driver in use: e1000e
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
        Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet
        Kernel driver in use: r8169



This is the USE flags for both packages.  I don't see anything obvious. 


[ebuild  N     ] sys-fs/udev-249-r3::gentoo  USE="kmod (split-usr) -acl
(-selinux) -test" ABI_X86="32 (64) (-x32)" 0 KiB
[uninstall     ] sys-fs/eudev-3.2.10-r1::gentoo  USE="hwdb introspection
kmod -rule-generator (-selinux) -static-libs -test" ABI_X86="32 (64) (-x32)"


In case it matters, I also have these udev rules.


root@fireball / # ls -al /etc/udev/rules.d/*
-rw-r--r-- 1 root root 2064 Apr 27  2021 /etc/udev/rules.d/69-libmtp.rules
-rw-r--r-- 1 root root 1903 Apr  4  2012
/etc/udev/rules.d/70-persistent-cd.rules
-rw-r--r-- 1 root root  814 Jan  1  2008
/etc/udev/rules.d/70-persistent-net.rules
-rw-r--r-- 1 root root    0 Mar 22  2015
/etc/udev/rules.d/80-net-name-slot.rules
root@fireball / #


Anyone have any ideas?  Are the network interfaces called something else
now?  Some config file not correct? 

Thanks.

Dale

:-)  :-) 

[Alexandru N. Barloiu]

On Sun, 2021-11-28 at 10:35 -0600, Dale wrote:



Boot with udev and do either ifconfig -a or ip addr show and look for
them. If they are not there, just load the modules e1000e or the other
one r8whatever it was. Should autoload, but who knows why they are not.
Use dmesg. Not that hard to debug.

[Dale]

I don't use modules, except for nvidia-drivers.  The network drivers are
built into the kernel.  When I first switched, I restarted all the
related stuff but it still wouldn't work even tho I had not rebooted.  I
only rebooted just in case it might help.  Still not sure if rebooting
makes a difference.

Any more ideas?

Dale

:-)  :-) 

[Jack]

This switch is NOT bringing in systemd.  It is just switching which
package is now providing udev as extracted from systemd. The news item
actually gives a bit more detail.

The network name switch (which I had thought was mentioned in the new
item, but apparently is not, so I don't remember where I read it) is not
directly due to eudev vs. udev, but to the "new" (years old at this
point) switch to consistent naming (or something like that) so your
network is probably something like enp20s2, reflecting which slot your
network card is physically in.  I'm pretty sure there is a kernel boot
parameter which forces the old way, but can't find it now, as I switched
to the new naming with eudev, so switching to udev didn't break anything
for me.

Looking through the dmesg output should tell you what it is currently
using but you'll have to hunt (or someone else will hopefully remember)
how to make the system revert to the old network interface naming.

[Dale]

Jack wrote:
> This switch is NOT bringing in systemd.  It is just switching which
> package is now providing udev as extracted from systemd. The news item
> actually gives a bit more detail.
>
> The network name switch (which I had thought was mentioned in the new
> item, but apparently is not, so I don't remember where I read it) is
> not directly due to eudev vs. udev, but to the "new" (years old at
> this point) switch to consistent naming (or something like that) so
> your network is probably something like enp20s2, reflecting which slot
> your network card is physically in.  I'm pretty sure there is a kernel
> boot parameter which forces the old way, but can't find it now, as I
> switched to the new naming with eudev, so switching to udev didn't
> break anything for me.
>
> Looking through the dmesg output should tell you what it is currently
> using but you'll have to hunt (or someone else will hopefully
> remember) how to make the system revert to the old network interface
> naming.

I'm not completely opposed to switching to the new name method.  Your
info about it being in dmesg is helpful.  Now I know where that name is
exactly.  ;-)  Do I just rename my current net.eth* files to the new way
and it works or do I need to do something else or is there a automatic
way to do this? 

That makes sense and was on my suspect list.  I just didn't know where
to get the new name from. 

Dale

:-)  :-) 

[Jack]

I'd suggest checking the wiki for network setup, but it's still down, and (of course) I can't currently find the URL for the status page.  General searching for "consistent network naming" or "persistent network naming" is also likely to find some helpful pages (among the not so helpful...)

If you know the kernel module you use for ethernet (even if it's built in) you can search for that in dmesg.  For example, my dmesg includes "[   19.528285] r8169 0000:19:00.0 enp25s0: renamed from eth0"  If you're not sure, lspci can help: mine includes "19:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)"  so you could find the PCI address for your network card and search for that in dmesg.  (19 hex is 25 decimal to get the network name)

[Dale]

Yep, your info helped.  Oh, Gentoo wiki is up and that helped too.  I
was able to access the install docs and print it for reference.  Anyway,
I removed eudev, emerged udev and rebooted, since it names the devices
during boot up, I thought that made sense.  When I got booted up,
naturally the network didn't work.  To make it easy I just logged into
KDE.  In a Konsole I ran both ip a and ifconfig.  Both agreed the
network was named enp3s0.  I then simply renamed the old net.eth0 file
to net.enp3s0.  After that, it came up but it didn't know to use DHCP
but did try it as a last resort.  That will slow things down so I went
digging for the file, /etc/conf.d/net, and changed the name of the
network to the new deal.  Once all this was done, I ended up with this
and it trying DHCP first.


root@fireball / # dmesg | grep e1000
[    0.531129] pci 0000:06:00.0: reg 0x30: [mem 0xfe100000-0xfe13ffff pref]
[    0.531486] pci 0000:00:15.0:   bridge window [mem 0xfe100000-0xfe1fffff]
[    0.568155] pci 0000:00:15.0:   bridge window [mem 0xfe100000-0xfe1fffff]
[    0.569693] pci_bus 0000:06: resource 1 [mem 0xfe100000-0xfe1fffff]
[    0.814373] e1000: Intel(R) PRO/1000 Network Driver
[    0.814432] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    0.814510] e1000e: Intel(R) PRO/1000 Network Driver
[    0.814566] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.814775] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec)
set to dynamic conservative mode
[    0.901776] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
68:05:ca:42:17:39
[    0.901855] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network
Connection
[    0.901925] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.795053] e1000e 0000:03:00.0 enp3s0: renamed from eth0
[  275.422120] e1000e 0000:03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full
Duplex, Flow Control: Rx/Tx
root@fireball / # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
    link/ether 68:05:ca:42:17:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global dynamic
noprefixroute enp3s0
       valid_lft 7134sec preferred_lft 6234sec
    inet6 fe80::1eef:2ca0:c286:9eec/64 scope link
       valid_lft forever preferred_lft forever
3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 94:de:80:cc:0c:39 brd ff:ff:ff:ff:ff:ff
    altname enp4s0
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
root@fireball / #


I'm mostly posting this just on the off chance someone else runs into
this and needs some guidance, I sure did.  o_O  Oh, don't forget to
remove the old network and add the new network to the default runlevel
as it should be. 

So, thanks Jack for the help.  The wiki coming up helped to but you got
me started by knowing what I should look for and where.  I think I could
have done this without the wiki and just the info you provided.  As a
bonus, I have the new network name. 

Dale

:-)  :-) 

[Neil Bothwick]

On Sun, 28 Nov 2021 11:02:17 -0600, Dale wrote:

> I'm not completely opposed to switching to the new name method.  Your
> info about it being in dmesg is helpful.  Now I know where that name is
> exactly.  ;-)  Do I just rename my current net.eth* files to the new way
> and it works or do I need to do something else or is there a automatic
> way to do this? 

Add net.ifnames=0 to kernel boot parameters.


--
Neil Bothwick

Of course it's not your day,
With 7 billion people on earth chances are slim it will ever be *your*
day.

[tastytea]

On 2021-11-28 11:50-0500 Jack <ostr...@users.sourceforge.net> wrote:

> This switch is NOT bringing in systemd.  It is just switching which
> package is now providing udev as extracted from systemd. The news
> item actually gives a bit more detail.
>
> The network name switch (which I had thought was mentioned in the new
> item, but apparently is not, so I don't remember where I read it) is
> not directly due to eudev vs. udev, but to the "new" (years old at
> this point) switch to consistent naming (or something like that) so
> your network is probably something like enp20s2, reflecting which
> slot your network card is physically in.  I'm pretty sure there is a
> kernel boot parameter which forces the old way, but can't find it
> now, as I switched to the new naming with eudev, so switching to udev
> didn't break anything for me.

The name switch is announced via a warning message when you emerge udev:

WARN: postinst

udev-249 defaults to predictable interface renaming, as described in
the URL below:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

If you wish to disable this, please see the above documentation, or set
net.ifnames=0 on the kernel command line.

You can change settings for log messages in make.conf, see
/usr/share/portage/config/make.conf.example for documentation (search
for PORTAGE_ELOG). I have
PORTAGE_ELOG_SYSTEM="save echo:error,warn,log" in my make.conf. echo
means the messages are displayed again when emerge exits.

> […]

Kind regards, tastytea

--
Get my PGP key with `gpg --locate-keys tast...@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

[Dale]

Neil Bothwick wrote:
> On Sun, 28 Nov 2021 11:02:17 -0600, Dale wrote:
>
>> I'm not completely opposed to switching to the new name method.  Your
>> info about it being in dmesg is helpful.  Now I know where that name is
>> exactly.  ;-)  Do I just rename my current net.eth* files to the new way
>> and it works or do I need to do something else or is there a automatic
>> way to do this? 
> Add net.ifnames=0 to kernel boot parameters.
>
>

I've already switched to the new naming method.  I'm not real big on it
but its been that way for a while so not likely to change again anytime
soon.  That said, they will likely announce a change in a month or so
just to rub my nerve the wrong way.  ROFL  At least it isn't as big a
deal as hal was.  ;-)  My biggest problem, I wasn't sure where to start
looking.  For some reason searching dmesg just escaped me. 

Now if I can figure out how to reset the list of /dev/sd* names that are
lurking about and inconsistent, that would be like striking gold.  Every
time I hook up my external drive, it gets a different sd* name.  It does
the same on the SD cards from my trail cameras too but I can auto mount
those. 

I'd also like for kwin to stop resetting every once in a while.  I
toggled the compositor(sp?) setting and that seems to have helped, so
far anyway. 

Dale

:-)  :-) 

[tastytea]

On 2021-11-29 22:47-0600 Dale <rdale...@gmail.com> wrote:

> Now if I can figure out how to reset the list of /dev/sd* names that
> are lurking about and inconsistent, that would be like striking gold.
> Every time I hook up my external drive, it gets a different sd*
> name.  It does the same on the SD cards from my trail cameras too but
> I can auto mount those. 

I don't think it is possible to get consistent sd* names for removable
media. But you could use volume labels with `tune2fs -L` or `tune.exfat
-L` or `fatlabel` and then mount them via /dev/disk/by-label/*.

[Matt Connell]

On Mon, 2021-11-29 at 22:47 -0600, Dale wrote:
> Now if I can figure out how to reset the list of /dev/sd* names that
> are lurking about and inconsistent, that would be like striking
> gold.  Every time I hook up my external drive, it gets a different
> sd* name.  It does the same on the SD cards from my trail cameras too
> but I can auto mount those. 

I'd suggest using the UUIDs for the disks (acquired via the blkid
command) and adding them to your /etc/fstab ... That's always been my
solution to commonly-connected-but-never-permanently external disks.

It won't ensure the same sd* name, but it will ensure that they get
mounted consistently where you expect them to be.

[Dale]

Thanks to both for the idea.  My problem isn't mounting, it's decrypting
the drive.  I use cryptsetup and I have to give the sd* name for both my
external drives.  The way I do now, I type in the command to the sd
point and hit tab twice.  Once the drive gets spun up, I hit tab again. 
Whichever one adds a 1 on the end is the one picked.  Thing is, it's
rarely the same one so I have to test to see which one it picks.  I wish
it would either reset itself or pick the same one each time.  I already
know to ignore sda, sdb, sdc, sdd and sde. 

If it wasn't encrypted, it would be a good idea.  I sometimes wish there
was a GUI way to do it that allows me to set my own mount point.  There
are GUI crypt programs but they set their own mount points.  Plus, the
command line is fairly easy.  The password is the hard part.  Good luck
NSA.  ROFL 

Dale

:-)  :-)

[Wols Lists]

On 30/11/2021 04:47, Dale wrote:
> Now if I can figure out how to reset the list of /dev/sd* names that are
> lurking about and inconsistent, that would be like striking gold.  Every
> time I hook up my external drive, it gets a different sd* name.  It does
> the same on the SD cards from my trail cameras too but I can auto mount
> those.

ls -al /dev/disk/by-uuid

That's a bunch of symlinks. The uuid part is guaranteed to be
consistent, and the link points to the correct sdXn.

Try using that instead, and see if it works. It's supposed to ...

Cheers,
Wol

[tastytea]

If the partition table is GPT (instead of msdos compatible), you can
set a label to the partition itself with gparted (right click →
name partition) and then access it via /dev/disk/by-partlabel/. That
works for encrypted partitions too, since the name is stored in the
partition table and not the file system.

[Grant Edwards]

On 2021-11-30, tastytea <gen...@tastytea.de> wrote:
> On 2021-11-29 22:47-0600 Dale <rdale...@gmail.com> wrote:
>
>> Now if I can figure out how to reset the list of /dev/sd* names that
>> are lurking about and inconsistent, that would be like striking gold.
>> Every time I hook up my external drive, it gets a different sd*
>> name.  It does the same on the SD cards from my trail cameras too but
>> I can auto mount those. 
>
> I don't think it is possible to get consistent sd* names for removable
> media.

You can write udev rules that trigger on the manufacturer, model, and
serial numbers. You can then assign consistent symlinks or even mount
them in predictable locations in the udev rules. I don't remember if
you can change the actual sd* names themselves, but there's no real
need to do so.

[Grant Taylor]

On 11/28/21 9:50 AM, Jack wrote:
> The network name switch ... is not directly due to eudev vs. udev,
> but to the "new" ... switch to consistent naming ... so your network

> is probably something like enp20s2, reflecting which slot your network
> card is physically in.

Except I've had multiple instances where the supposed to be consistent
naming is anything but consistent. I don't know if it was a udev issue
or something else. But I've seen the actual address of cards in the
system change based on what other cards are added to / removed from the
system. It seems as if the motherboard re-configured addressing with
the hardware change. E.g. NIC1 in PCIe slot A and NIC2 in PCIe slot C.
NIC2 changed from (hypothetical) enp20s2 to enp16s2 when NIC1 was
removed from PCIe slot A.

So ... if the new naming scheme isn't consistent, then I'm not going to
give it the time of day. I'd rather have the older and simpler
inconsistent naming scheme (eth#) vs the newer and more annoying scheme
en{po}\d\d{,s}{,1,2,3}.

The epiphany when is aw that the supposedly consistent names weren't was
a real son of a REDACTED moment.

> I'm pretty sure there is a kernel boot parameter which forces the old
> way, but can't find it now, as I switched to the new naming with eudev,
> so switching to udev didn't break anything for me.

As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot
lines (for the above reason).



--
Grant. . . .
unix || die

[Dale]

What I noticed in dmesg is that it takes the old name, eth0 for example,
and then renames it to the new name.  Well, if one moves things around
and eth0 becomes eth3 then doesn't that mess up the new name as well? 
That could be why you see the results you have.  It's hard to base a
name on something that is changing itself.  It would seem to me that if
they were going to change things for real, they would change what the
kernel names it in the beginning and it uses the name it was first given
based on slot or something else unique.  In other words, have the kernel
assign it enp2s3 or whatever when booting and that is the only name it
gets. 

I don't change much hardware often so it doesn't affect me but I'm sure
there are people, maybe even large companies/orgs that it does and it
could be a issue for them.  It could even be a security issue if two
nics gets switched and one has a lot of security and the other doesn't. 

Either way, I'm up and running again.  Even rebuilt my backup kernels to
include the drivers this morning.  I just hope nothing comes back and
bites me later.  :/  I was a bit lost there for a while. 

Dale

:-)  :-) 

[Grant Taylor]

On 11/30/21 12:58 PM, Dale wrote:
> What I noticed in dmesg is that it takes the old name, eth0 for
> example, and then renames it to the new name.

I don't know if it's the /kernel/ that does the renaming, or not based
on the kernel parameter, or if it's something else very early in the
boot that does the renaming.

> Well, if one moves things around and eth0 becomes eth3 then doesn't
> that mess up the new name as well?

My understanding is that the new name is -- supposed to be -- based off
of some property of the device. I assume that said property is from
something akin to where lspci gets it's data. Probably something
exposed in /proc and / or /sys via the actual driver that ultimately
gets feed into the renaming routine.

> That could be why you see the results you have.> It's hard to base
> a name on something that is changing itself.

My understanding is that the new name is supposed to be completely
independent from and not derived using the old name. So the old naming
should have no influence on the new name.

> It would seem to me that if they were going to change things for real,
> they would change what the kernel names it in the beginning and it uses
> the name it was first given based on slot or something else unique.

Agreed. As in have the driver instantiate the device with the new name
from the outset.

> In other words, have the kernel assign it enp2s3 or whatever when
> booting and that is the only name it gets.

Yep.

I don't know /why/ or /where/ the failure is with the new names. I just
know that I have seen instability in them. Seeing as how stability ~>
predictability is the motivation for the rename, well, that's a failure
in my opinion.

Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging
into a machine than it is to have to figure out the interface name first.

That being said, I was okay with what CentOS 6.x did, where the new name
was matched against the MAC address. I had eth0 based on MAC for
outside and eth1 based on MAC for inside on a number of systems.

[Rich Freeman]

On Tue, Nov 30, 2021 at 3:56 PM Laurence Perkins <lper...@openeye.net> wrote:
>
> If you only have one interface though and tweak your hardware regularly then you'll probably be happier to put it back to the old naming scheme because with only one device it should always be eth0.
>

I'm not sure if other network managers support wildcards, but with
networkd I just set the interface name to e* on single-device systems.

--
Rich

[Grant Taylor]

On 11/30/21 1:56 PM, Laurence Perkins wrote:
> So the old inconsistency was a super-bad kind of inconsistency.
> The interfaces got named based on the order in which the devices
> were discovered. Which, on a lot of systems, meant that every boot
> was essentially rolling the dice on a race condition.

-guppy mouth-

> If you only have one device, you're fine. If your devices consistently
> come up in the same order, you're fine. If there's jitter though
> then things can easily get messy, and do so unexpectedly.

I guess I never really gave the renaming much thought because I almost
always complied drivers into the kernel, which meant that they had a
consistent ~> predictable enumeration and naming order.

> The new naming scheme names devices based on where they show up
> on the bus. This has its own issues. It means that USB adapters
> get different names when plugged into different slots. It means
> that adding or removing other PCI bus devices can change the bus
> address and therefore the name of your network interfaces.

Thank you for that explanation. It describes what I witnessed perfectly.

> I've seen motherboard firmware updates do the same.

Oy vey!

> But, at least in theory, this inconsistency should be triggered
> by something you *know* about unless hardware is getting added and
> removed by someone else without your knowledge.

One would hope.

> If you only have one interface though and tweak your hardware regularly
> then you'll probably be happier to put it back to the old naming
> scheme because with only one device it should always be eth0.

Indeed.

[Grant Edwards]

On 2021-11-30, Grant Taylor <gta...@gentoo.tnetconsulting.net> wrote:

> Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging
> into a machine than it is to have to figure out the interface name first.

Yep. I always add udev rules to rename the boards net0, net1, etc.
based don the MAC addresses.

> That being said, I was okay with what CentOS 6.x did, where the new name
> was matched against the MAC address. I had eth0 based on MAC for
> outside and eth1 based on MAC for inside on a number of systems.

IIRC, there are situations where using udev rules to rename them
"ethN" based on MAC addresses will fail because that can conflict with
the low-level kernel names. Or something like that.

--
Grant (the other one)

[Grant Taylor]

On 12/1/21 10:02 AM, Grant Edwards wrote:
> IIRC, there are situations where using udev rules to rename them
> "ethN" based on MAC addresses will fail because that can conflict
> with the low-level kernel names. Or something like that.

I don't think I ever ran into a problem re-using the original kernel
eth# names /as/ /long/ /as/ the target name wasn't currently in use.
Sometimes I needed to vacate the target name before I could re-use it.

[Grant Edwards]

On 2021-11-30, Grant Taylor <gta...@gentoo.tnetconsulting.net> wrote:

> I guess I never really gave the renaming much thought because I
> almost always complied drivers into the kernel, which meant that
> they had a consistent ~> predictable enumeration and naming order.

I think that's generally true on most motherboards for PCI
devices. Possibly not so much for USB.

--
Grant