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

    From Dale@21:1/5 to All on Sun Nov 28 17:40:03 2021
    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexandru N. Barloiu@21:1/5 to All on Sun Nov 28 17:50:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack@21:1/5 to Dale on Sun Nov 28 18:00:02 2021
    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.

    On 11/28/21 11:35, Dale wrote:
    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

    :-)  :-)


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Alexandru N. Barloiu on Sun Nov 28 18:00:02 2021
    Alexandru N. Barloiu wrote:
    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.




    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Jack on Sun Nov 28 18:10:06 2021
    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack@21:1/5 to All on Sun Nov 28 18:40:02 2021
    This is a multi-part message in MIME format.
    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)
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>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...)</p>
    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 "<span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">[   19.528285]
    r8169 0000:19:00.0 enp25s0: renamed from eth0"  If you're not
    sure, lspci can help: mine includes "</span></span><span
    style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;"><span
    style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">19:00.0
    Ethernet controller: Realtek Semiconductor Co., Ltd.
    RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    (rev 15)</span></span>"  so you could find the PCI address
    for your network card and search for that in dmesg.</span></span><span
    style="font-family:monospace">  (19 hex is 25 decimal to get the
    network name)<br>
    </span>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Jack on Sun Nov 28 21:10:01 2021
    Jack wrote:

    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)


    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Neil Bothwick@21:1/5 to Dale on Sun Nov 28 21:50:02 2021
    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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmGj6lsACgkQ92eFu0QS MJjEqRAAwIUDuUX3Wj5YQB2dR1i26ZNDH0jb2PwuwQaIzivx+UFKqbV5wDZ5VHcm nTXbY9RkGarKKqkhGURFI+V+/rIWPVjofPaqrEQEfbHN9Lumz3FevQQ3WYI0Yi2H R8c+emrWr38iClsbYYXcf2spboYnBvfTRSrFaEUSJ55xEm7bdnfC5URSG91ku5yr OOYuTJzuoemKMXw/TvIT5eVrduHdv+dGRqubAun8DZjmbK9mmBCGWePQ3g8K5aoi wxCXjKZcx0KI/qZqwygXlUwFpr8IWxseZ3qFHaAm61W7fZxFKuANHk2BJHyCUsas J+7xEYnCuPUYSdH4sSmv4feqGdx7KUwuLCmId9wzypdYPMoSysr/3yymL8fLHAka zWmIEgzKtCqvAz77Ijvpm0q06tLje2hfowFzNphda7E2jN9Y5retAZ8hKyl8Uxga u8e3pmLUQ6ZOYErAsw81+rpmFZEkOGk2LXj1exYl+hKuMnO0MqYKq9AVOPcEmA08 2w0wi8DxczR5X1yoxuglMAgLtdGT0p42Nnsng2UVa3y+6vbSM4Mx4IZKwrfWMae8 DTZkgXb7lvzmd5NFQ5KNZHGzvXeqdMUyfDyOABGh3bb7+hOCL5ERX8SYtNM6Q5c1 QqOOF/Q27iFORV5TGcKcjagnWUZePZxb4kSJ/H+GsbuvdSR6mx8=
    =jfab
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxN
  • From tastytea@21:1/5 to ostroffjh@users.sourceforge.net on Mon Nov 29 05:50:02 2021
    On 2021-11-28 11:50-0500 Jack <ostroffjh@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 tastytea@tastytea.de` or at <https://tastytea.de/tastytea.asc>.

    -----BEGIN PGP SIGNATURE-----

    iHUEAREKAB0WIQQ1VSZoZMptf/RapufPw5SX8bJuBwUCYaRaVQAKCRDPw5SX8bJu ByqxAP4yinecul+0JcIIWamfRsY5E0js3sitwPl5NzBATb7HDAD/a/zcDGrfpGhl V+3RxKmU1YUmsZs8AF6TPhU/BdNjjLg=
    =dbRE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Neil Bothwick on Tue Nov 30 05:50:02 2021
    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Connell@21:1/5 to Dale on Tue Nov 30 06:10:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tastytea@21:1/5 to rdalek1967@gmail.com on Tue Nov 30 06:10:01 2021
    On 2021-11-29 22:47-0600 Dale <rdalek1967@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/*.

    Kind regards, tastytea

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

    -----BEGIN PGP SIGNATURE-----

    iHUEAREKAB0WIQQ1VSZoZMptf/RapufPw5SX8bJuBwUCYaWv4QAKCRDPw5SX8bJu BytRAPwNNKFtVbodwDTR4GlKdUOrSt2MnzsHQnenX30WBVDW/wD/cG7Yf/s72x/Q on4ojybjGwmKb9zBhpCpOsUeffpC58c=
    =A4Ca
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Matt Connell on Tue Nov 30 06:20:01 2021
    Matt Connell wrote:
    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.





    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

    :-)  :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wols Lists@21:1/5 to Dale on Tue Nov 30 06:40:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tastytea@21:1/5 to rdalek1967@gmail.com on Tue Nov 30 06:50:02 2021
    On 2021-11-29 23:19-0600 Dale <rdalek1967@gmail.com> wrote:

    Matt Connell wrote:
    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.





    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 

    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.

    Kind regards, tastytea


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

    -----BEGIN PGP SIGNATURE-----

    iHUEAREKAB0WIQQ1VSZoZMptf/RapufPw5SX8bJuBwUCYaW5owAKCRDPw5SX8bJu B565AP43v6L0ud7uDLTl/MWOFzBoVL17f1kIPsmfJ0420/J2cgD+PrjGebd6EXAG eZ+ysFq0dRlPXiRd11Lie3JKV4FRQkU=
    =KDW1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Edwards@21:1/5 to tastytea on Tue Nov 30 07:20:01 2021
    On 2021-11-30, tastytea <gentoo@tastytea.de> wrote:
    On 2021-11-29 22:47-0600 Dale <rdalek1967@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.

    But you could use volume labels with `tune2fs -L` or `tune.exfat
    -L` or `fatlabel` and then mount them via /dev/disk/by-label/*.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dale@21:1/5 to Grant Taylor on Tue Nov 30 21:00:02 2021
    Grant Taylor wrote:
    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).





    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

    :-)  :-) 

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Jack on Tue Nov 30 20:30:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Dale on Tue Nov 30 21:40:02 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich Freeman@21:1/5 to lperkins@openeye.net on Tue Nov 30 22:10:02 2021
    On Tue, Nov 30, 2021 at 3:56 PM Laurence Perkins <lperkins@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Laurence Perkins on Tue Nov 30 23:00:02 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Edwards@21:1/5 to Grant Taylor on Wed Dec 1 18:10:01 2021
    On 2021-11-30, Grant Taylor <gtaylor@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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Grant Edwards on Wed Dec 1 18:20:01 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Edwards@21:1/5 to Grant Taylor on Wed Dec 1 18:20:01 2021
    On 2021-11-30, Grant Taylor <gtaylor@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)