View previous topic :: View next topic |
Author |
Message |
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Wed Dec 01, 2021 8:46 pm Post subject: [SOLVED] udev network device name |
|
|
The instructions here:
https://wiki.gentoo.org/wiki/Eudev/Network_device_names
That allows us to keep the traditional "eth0", "eth1",etc. network names has suddenly stopped working for me with a recent world update.
I think the machine in question was doing the eudev-> systemd-udevd migration at the time.
But after this world update, and a reboot, my network was gone..
This is especially frustrating as many of my gentoo machines are headless servers with just a sshd connection enabled - so network gone, means a difficult to debug problem.
I checked for the existance of the /etc/udev/rules.d/80-net-name-slot.rules file - it's still there.
But, no "eth0" device - I get the new fangled /dev/enp0s3 instead.
How does one re-enable this "stop messing with my network names" part of udev?
Last edited by gtwrek on Thu Dec 02, 2021 5:42 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54801 Location: 56N 3W
|
Posted: Wed Dec 01, 2021 9:13 pm Post subject: |
|
|
dtwrek,
Add as a kernel parameter to the kernel command line.
Exactly how you do that is boot loader depended. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 2113
|
Posted: Thu Dec 02, 2021 12:34 am Post subject: |
|
|
I've also updated the page you linked to refer to the newer instructions here (see bug 827937 too). |
|
Back to top |
|
|
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Thu Dec 02, 2021 12:40 am Post subject: |
|
|
Well, I think I've figured out *some* of what's going on.
To keep the normal network names, there's three methods:
1. touch /etc/udev/rules.d/80-net-name-slot.rules
2. touch /etc/udev/rules.d/80-net-setup-link.rules
3. add net.ifnames=0 to your kernel command line
Method 1 works with eudev and certain older versions of udev. (As I understand things eudev was forked from an early version of udev, so this make sense)
Method 2 works with current udev.
Method 3 (currently recommended?) should work past some xxx.xxx kernel version.
I'm still puzzled as to why udev is now being pulled in for me. I've been using eudev forever, and I thought we had until Jan 1, 2022 until it was formally deprecated.
But in any event I think some more text to the enews might be called for, for those of use migrating from eudev to udev. Dropping off the network after a reboot from a world update is a very frustrating experience. |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 2113
|
Posted: Thu Dec 02, 2021 1:41 am Post subject: |
|
|
gtwrek wrote: | Well, I think I've figured out *some* of what's going on.
To keep the normal network names, there's three methods:
1. touch /etc/udev/rules.d/80-net-name-slot.rules
2. touch /etc/udev/rules.d/80-net-setup-link.rules
3. add net.ifnames=0 to your kernel command line
Method 1 works with eudev and certain older versions of udev. (As I understand things eudev was forked from an early version of udev, so this make sense)
Method 2 works with current udev.
Method 3 (currently recommended?) should work past some xxx.xxx kernel version.
I'm still puzzled as to why udev is now being pulled in for me. I've been using eudev forever, and I thought we had until Jan 1, 2022 until it was formally deprecated.
But in any event I think some more text to the enews might be called for, for those of use migrating from eudev to udev. Dropping off the network after a reboot from a world update is a very frustrating experience. |
Noted, thanks for the feedback.
Some improvements:
1. I've just updated the news item to explicitly reference this and link to the wiki.
2. As I mentioned, I updated the page OP linked to earlier.
3. Earlier, floppym updated the udev wiki page to be more clear.
4. Earlier, we also added an automatic carry over for the rules eudev would recognise into sys-fs/udev (as a result of bug 827937).
There has been a message in sys-fs/udev about the interface naming since August: that message appears when installing udev for the first time after switching from eudev.
EDIT: The ebuild now also explicitly links to the wiki too.
As for why it's masked now: the news item said it'd be masked on 1st October, so it was actually done a far bit later than that. It can still be unmasked locally if you wish. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 23064
|
Posted: Thu Dec 02, 2021 2:02 am Post subject: |
|
|
2022-01-01 is the date on which the news said eudev would be retired and removed. I interpret that as meaning that on or about that date, emerge --pretend --verbose sys-fs/eudev will begin reporting "No such package". This gives users a window during which they could copy the last version of eudev into an overlay, if they are determined to continue using it instead of switching to udev. |
|
Back to top |
|
|
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Thu Dec 02, 2021 5:42 pm Post subject: |
|
|
Thanks Sam, and Hu. Sam - your edits to the enews message and the udev message are great. I think that should cover things.
Hu, yes rereading the original enews, it mentioned 2022-01-01 as the removal but 2021-10-01 as the mask. I'd really not consider the difference between the two. And it appears the 2021-10-01 mask was delayed to sometime in the last few weeks. This is what triggered my conversion from eudev->udev and the resulting network naming problems note in this thread.
I think I'm ok with moving forward with updating the rest of my machines, now that I understand what's happening.
Thanks all for the help. |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 2113
|
Posted: Thu Dec 02, 2021 11:41 pm Post subject: |
|
|
gtwrek wrote: | Thanks Sam, and Hu. Sam - your edits to the enews message and the udev message are great. I think that should cover things.
Hu, yes rereading the original enews, it mentioned 2022-01-01 as the removal but 2021-10-01 as the mask. I'd really not consider the difference between the two. And it appears the 2021-10-01 mask was delayed to sometime in the last few weeks. This is what triggered my conversion from eudev->udev and the resulting network naming problems note in this thread.
I think I'm ok with moving forward with updating the rest of my machines, now that I understand what's happening.
Thanks all for the help. |
Thanks a lot for the feedback! Really appreciated. Glad everything is OK now. Please let us know if any trouble. |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 3007 Location: Edge of marsh USA
|
Posted: Fri Dec 03, 2021 4:29 am Post subject: |
|
|
Just to cover all of the bases:
1. I created a symlink "80-net-name-slot.rules -> /dev/null" on April 2, 2013
2. I created a symlink "80-net-setup-link.rules -> /dev/null" on May 10, 2014.
3. I also have the line GRUB_CMDLINE_LINUX="net.ifnames=0" in /etc/default/grub
ADDED: On my newer main desktop machine, I use my own unique network names with a udev rule that was originally done because of a failing built-in NIC.
Code: | $ cat /etc/udev/rules.d/90-local-net-name.rules
# NOTES:
# wan0 Ralink corp. RT5390 Wireless 802.11n on-board rt2800pci module
# wlan0 by default
# lan0 Realtek RTL8111/8168/8411 on-board (bad) r8168 or r8169 module
# Disabled in kernel
# lan1 TP-Link USB UE300 10/100/1000 LAN Realtek RTL8153 r8152 module
# lan2 Intel Corporation 82572EI (used) Gigabit Ethernet e1000e module
# eth0 by default becomes lan2 via udev, below
#Model alternative:
#SUBSYSTEM=="net", ACTION!="remove", ATTR{address}=="9c:b7:0d:6a:ec:80", NAME="wan0"
#
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="9c:b7:0d:6a:ec:80", NAME="wan0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="e8:40:f2:0c:86:eb", NAME="lan0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="d0:37:45:ca:52:5d", NAME="lan1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:15:17:d3:3f:74", NAME="lan2" |
This worked so well, I didn't revert back to using eth0. If feels funky, but I got used to it. _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Fri Dec 03, 2021 5:08 am Post subject: |
|
|
figueroa wrote: | Just to cover all of the bases:
1. I created a symlink "80-net-name-slot.rules -> /dev/null" on April 2, 2013
2. I created a symlink "80-net-setup-link.rules -> /dev/null" on May 10, 2014.
3. I also have the line GRUB_CMDLINE_LINUX="net.ifnames=0" in /etc/default/grub
|
I'm now doing the same on all my servers. What's worth doing one way, might as well do it all 3 ways... |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|