View previous topic :: View next topic |
Author |
Message |
dead_parrot n00b
Joined: 26 Mar 2012 Posts: 27 Location: /EU/PL
|
Posted: Sat Apr 27, 2013 8:29 pm Post subject: [SOLVED] interface eth0 does not exist (udev issue) |
|
|
Hi,
I have installed Gentoo (3.7.10) with the following problem:
Code: | * Bringing up interface eth0
* ERROR: interface eth0 does not exist
* Ensure that you have loaded the correct kernel module for your hardware
* ERROR: net.eth0 failed to start
* ERROR: cannot start netmount as net.eth0 would not start |
I compared the network configuration with the manual http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8 -was OK
Kernel module forcedeth was loaded.
I tried to run dhcpcd manually and it created following interface Code: | enp0s5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 |
What's going on? Kernel configuration or udev?
Last edited by dead_parrot on Mon May 06, 2013 8:30 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54810 Location: 56N 3W
|
Posted: Sat Apr 27, 2013 8:43 pm Post subject: |
|
|
dead_parrot,
udev has renamed your eth0 to enp0s5 at no extra cost.
You can fix its rules to leave eth0 alone or you can change eth0 to enp0s5 everywhere. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 498 Location: Gainesville, FL, USA
|
Posted: Sat Apr 27, 2013 9:03 pm Post subject: Re: interface eth0 does not exist |
|
|
You've got the perfect username for this. Cue Monty Python: Bloody parrot, bloody bird, ... bloody udev!
dead_parrot wrote: | I have installed Gentoo (3.7.10) with the following problem:
Code: | * Bringing up interface eth0
* ERROR: interface eth0 does not exist
* Ensure that you have loaded the correct kernel module for your hardware
* ERROR: net.eth0 failed to start
* ERROR: cannot start netmount as net.eth0 would not start |
I compared the network configuration with the manual http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8 -was OK |
Let me guess--you're doing your first Gentoo installation. My apologies to you on behalf of the Gentoo community. You landed in the middle of a big controversy. Whereas users had long been told to look for the eth0 interface, and whereas documentation you find in all kinds of places talks about eth0, the upstream responsible for udev thinks it's important to overturn the world, and Gentoo maintainers have taken it on to propagate these changes into Gentoo without even allowing for enough time to adjust the installation documentation.
dead_parrot wrote: | I tried to run dhcpcd manually and it created following interface enp0s5 |
That's the incredibly stupid default that you get. It reflects the fact that your interface is plugged into PCI bus 0, slot 5. If you move it somewhere else, the name changes. Hooray!
A lot of us are up in arms about this! If you've got a single interface, there is a fairly simple solution: put an empty file at /etc/lib/udev/rules.d/80-net-name-slot.rules and reboot you'll get the sane eth0 interface name.
EDIT: I had written the incorrect path for /etc/lib/udev/rules.d/80-net-name-slot.rules
There are definite reasons to have made a change in device naming which I won't get into here, but their default renaming rule is sold as being "predictable". That is the precise word they use even though it is the epitome of unpredictablity unless you promise never to move your NIC to another slot. There are other rules you can use--it is a bit harder to set up--but better down the road.
Good luck on the rest of your installation.
Last edited by miket on Sat Apr 27, 2013 10:00 pm; edited 1 time in total |
|
Back to top |
|
|
sitquietly Apprentice
Joined: 23 Oct 2010 Posts: 151 Location: On the Wolf River, Tennessee
|
Posted: Sat Apr 27, 2013 9:29 pm Post subject: Re: interface eth0 does not exist |
|
|
miket wrote: | .....
dead_parrot wrote: | I tried to run dhcpcd manually and it created following interface enp0s5 |
That's the incredibly stupid default that you get. It reflects the fact that your interface is plugged into PCI bus 0, slot 5. If you move it somewhere else, the name changes..... |
F**k! I just caught on.
I guess that's weird enough to laugh at
Thanks for making it clear for me. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 23072
|
Posted: Sat Apr 27, 2013 9:41 pm Post subject: Re: interface eth0 does not exist |
|
|
miket wrote: | If you've got a single interface, there is a fairly simple solution: put an empty file at /usr/lib/udev/rules.d/80-net-name-slot.rules | Are you sure about that path? The news says to use /etc/udev/rules.d/80-net-name-slot.rules. All my machines use the /etc name and enjoy their predictable name of eth0 instead of bizarre slot-based naming. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 498 Location: Gainesville, FL, USA
|
Posted: Sat Apr 27, 2013 9:58 pm Post subject: Re: interface eth0 does not exist |
|
|
Hu wrote: | miket wrote: | If you've got a single interface, there is a fairly simple solution: put an empty file at /usr/lib/udev/rules.d/80-net-name-slot.rules | Are you sure about that path? The news says to use /etc/udev/rules.d/80-net-name-slot.rules. All my machines use the /etc name and enjoy their predictable name of eth0 instead of bizarre slot-based naming. |
Egg on my face! You're right. I'll edit my response lest anyone get led astray. Thank you. |
|
Back to top |
|
|
dead_parrot n00b
Joined: 26 Mar 2012 Posts: 27 Location: /EU/PL
|
Posted: Sun Apr 28, 2013 2:06 pm Post subject: |
|
|
Thanks to all of you for the answer and especially to miket for his exhaustive explanation. I have created 80-net-name-slot.rules and it works.
Before I flag this threat as solved, I would like to ask one more thing. In general, there are two types of solutions: one with the 80-net-name-slot.rules file and the second, mentioned by NeddySeagoon, to replace eth0 with enp0s5. What are advantages/disadvantages of any of them?
Is a change of the naming convention a bigger plan or just a side effect? |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2056 Location: United Kingdom
|
Posted: Sun Apr 28, 2013 2:22 pm Post subject: |
|
|
Actually, there's also a third solution: rename all interfaces to e.g. netX (https://forums.gentoo.org/viewtopic-p-7244030.html#7244030). _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54810 Location: 56N 3W
|
Posted: Sun Apr 28, 2013 2:54 pm Post subject: |
|
|
dead_parrot,
If you only have a single network card its a case of being aware of the naming convention in use.
If you add network cards, replace network cards, or move your network card from slot to slot, you need to conside the pros and cons.
The kernel names eth0, eth1 ... are allocated in PCI bus scan order. So if you add a card, before your present card, eth0 can become eth1.
Old udev had code/rules to fix the names based on the MAC address, so that this didn't happen but it meant that it had to be able to swap kernel names around. Swapping kernel names has been dropped. As names were tied to MAC addesses, whem your NIC died and you fitted a new one, the new one became eth1 until you fixed the rules file.
The new default naming scheme names interfaces for the PCI bus and slot they are in, so you can swap NICs without the names changing. If you fit an extra NIC, the old name won't change either. If you move the NIC to another slot say because you have a new shiny video card that is two slots wide, it changes names.
Its a case of two different default naming conventions, neither of which are perfect for 100% of use cases. Both work for single NICs, which is over 99% of installs.
Its a PITA when defaults are changed like this and its alienating many udev users to the point where udev has been forked and other options are being looked too. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 498 Location: Gainesville, FL, USA
|
Posted: Mon Apr 29, 2013 2:55 pm Post subject: |
|
|
NeddySeagoon wrote: | The new default naming scheme names interfaces for the PCI bus and slot they are in, so you can swap NICs without the names changing. If you fit an extra NIC, the old name won't change either. If you move the NIC to another slot say because you have a new shiny video card that is two slots wide, it changes names. |
Now here is a thing I don't see adequately addressed, and unfortunately I've not gone tweaking through to find out: since obviously udev has knowledge of the physical address of the NIC to be able to generate the "predictable" name, isn't it possible to write a udev rule that tests for bus type, bus number, and slot number and assign a netX, lanX, wanX, or whateverX? The renaming should not come down to a choice between either mac-address-to-nice-name or bus-address-to-ugly-name; you should be able to use a bus-address-to-nice-name pattern.
Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue. The question now: isn't there a way you can get a name like net0 based on bus and slot rather than MAC address? |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6214 Location: Dallas area
|
Posted: Mon Apr 29, 2013 3:00 pm Post subject: |
|
|
miket wrote: | Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue. |
Udev itself caused the "race condition" by trying to start itself before the kernel truly finished loading
all in the name of trying to save a second or two booting. _________________ UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 498 Location: Gainesville, FL, USA
|
Posted: Mon Apr 29, 2013 3:21 pm Post subject: |
|
|
Anon-E-moose wrote: | miket wrote: | Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue. |
Udev itself caused the "race condition" by trying to start itself before the kernel truly finished loading
all in the name of trying to save a second or two booting. |
EDIT: No, I didn't know that. When did they start that? What follows below is another way I thought of going around the situation, but maybe the best thing is going back to making udev wait a bit!
A couple of weeks ago I thought of making a kernel patch to allow the user to configure the kernel to use a different base name so that udev could safely rename to names in the eth series. As I looked to the kernel sources, I see Ethernet drivers generally have this in them: Code: | sprintf(dev->name, "eth%d", unit) |
That told me two things: 1) that makes for way too many places to patch, and 2) that base integer is a better target. Unfortunately, I haven't had a lot of time to trace back in the driver-initialization flow to see how feasible it is to make the devices have a different initial count, but maybe you can see where I'm going. With an offset like 10, the kernel could freely assign names like eth10, eth11, and so on. This would leave the lower numbers like eth0 free for udev. Someone setting up a kernel might go with knowledge like "I certainly won't have more more than X interfaces" and leave those lower-numbered names free.
In any case, this is not the question I was posing just now in this thread. |
|
Back to top |
|
|
eurabilis n00b
Joined: 22 Jun 2010 Posts: 66 Location: Warwick, Rhode island, USA
|
Posted: Tue Aug 20, 2013 8:47 pm Post subject: Thanks. |
|
|
This drove me nuts for a day. Thanks to all that responded, touching 80-net-name-slot.rules in /etc/udev/rules.d/ fixed it for me. |
|
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
|
|