No network after udev 2 update

[roarkh]

I really tried to follow the instructions carefully but this latest udev update seems to have borked my system. The command to discover my new network interface told me its name was enp3s0 but after rebooting there is no network and I see the error "ERROR: interface enp3s0 does not exist." I would really appreciate any help to get network back. Thanks.

[SamuliSuominen]

Do you have any files in /etc/udev/rules.d? Like 70-* or 80-* that would prevent the new names from getting activated. Paste output of `ls -l /etc/udev/rules.d/*`?
Paste the whole output of the udevadm command that gave you the information?

[roarkh]

I had removed both files that started with 70- from /etc/udev/rules.d but the file 80-net-name-slot.rules file was still there, it had no lines that were not commented out but I removed it, rebooted the machine and all is well so I guess that was it. Thanks for your help, I guess that was a relatively painless upgrade after all. It will take some getting used to the new naming convention, eth0 was much easier to remember than enp3s0.

Thanks for your help.

[genterminl]

I just did the udev 200 upgrade. I did read the news item. I have only one wired network interface. I left the 80-net-name-slot.rules in place, and renamed and modified the 70-persistent-network.rules to use neteth0 instead of eth0. After reboot, dmesg shows eth0 being created and being renamed to neteth0. /sys/class/net/neteth0 exists, and points to the expected pci interface. However, there is no entry in /dev for the network. I've read bunches of other posts on this, but am obviously still missing something.

I assume if I just delete the 80-net-name-slot.rules, I should get the new style name for the interface. I will eventually try that, but I'd prefer to figure out why I'm not getting /dev/neteth0. Is that just a bad choice of name? Have I created some conflict in naming? Am I correct to assume the presence of that file is preventing the new name (enp0s10 in my case) from being used?

Also, can someone explain the difference between 80-net-name-slot.rules being a real file with content (as installed by emerge,) it being an empty file, and it being a symlink to /dev/null? I think I can understand how the latter two are equivalent, and the first seems to also have the same effect - should it be different?

Thanks for any insights or explanations.

[edit: I intended to post a new thread, but obviously used the wrong browser tab. The topic seems pretty close, so I'll leave it here but am OK if an admin kills this and I will repost from scratch.]

[SamuliSuominen]

However, there is no entry in /dev for the network. I've read bunches of other posts on this, but am obviously still missing something.

Hardware networking interfaces have neved had a /dev entry, there was no /dev/eth0 with old udev, for example.

I assume if I just delete the 80-net-name-slot.rules, I should get the new style name for the interface. I will eventually try that, but I'd prefer to figure out why I'm not getting /dev/neteth0. Is that just a bad choice of name? Have I created some conflict in naming? Am I correct to assume the presence of that file is preventing the new name (enp0s10 in my case) from being used?

If you want your interface to be called neteth0, then you should just have _1_ file in /etc/udev/rules.d, call it like 70-my-network.rules that does the renaming to neteth0.

However, delete all files from /etc/udev/rules.d (70-* and 80-*) if you want the new names to take place instead of custom renaming them.

So in other words:
Pick one, 70-my-network.rules for renaming, point here is that is should be 70-something.rules.
Or alternatively empty 80-net-name-slot.rules, or symlink to /dev/null and kernel names will be used again.

Also, can someone explain the difference between 80-net-name-slot.rules being a real file with content (as installed by emerge,) it being an empty file, and it being a symlink to /dev/null? I think I can understand how the latter two are equivalent, and the first seems to also have the same effect - should it be different?
Thanks for any insights or explanations.

If /etc/udev/rules.d/80-net-name-slot has only # commented lines in it, or if it's otherwise empty, or if it's symlink to /dev/null it all means the same thing -> It will prevent the /lib/udev/rules.d/80-net-name-slot.rules from taking into action.
Alternatively you could copy /lib/udev/rules.d/80-net-name-slot.rules over to /etc/udev/rules.d/80-net-name-slot.rules and edit it there to change the order of how the interfaces get named, to define what attributes from /sys/class/net/<the name of your interface> gets used primarily, what secondary, and so forth.

As in, /etc/udev is just the place to override stuff from /lib/udev.

I hope that clears things up. This is all in the news item though, so I'm just replicating this same answer propably 100x times today. Would be cool if people would read the news item with a bit more care.

[genterminl]

There are so many moving parts in getting the network started, that it really is easy to get confused, even if you read the news item several times, as I did.

I have no idea why I was so convinced I had previously seen a network interface in /dev.

In my case, I now see the reason my network didn't come up after reboot was that I didn't change the network interface name in /etc/conf.d/net. I did change the net.eth0 symlink in /etc/init.d. In fact, I created symlinks for both enp0s10 and neteth0, and it failed on the first and didn't try the second. Running it manually worked. Deleting the unnecessary one let the other one work correctly on reboot. Note that the news item does mention updating the symlinks, but I don't see any mention of updating /etc/conf.d/net to reflect the new name.

Regarding the slot rules file - it seems "empty" means empty of any actual rules, comments don't count. That could have been said more explicitly to avoid at least some of the confusion.

I still have several files in /etc/udev/rules.d - I suppose I'll have to go through them (at least the 70- ones) one at a time to see if they are really still necessary and to anything useful (or perhaps anything at all). However, only some of the appear to have been created by me for any remembered purpose, so either I forgot why I created them or they were created by some ancient emerge.

So - is this correct for /etc/udev/rules.d?
- 80-net-name-slot.rules can be a modified version of the one in /lib/udev/rules.d to modify the kernel naming
- 80-net-name-slot.rules is present and empty (expect perhaps for comments) will block the new kernel naming
(In both the above cases, the presence of this file overrides the use of /lib/udev/80-net-name-slot.rules)
- 70-my-network.rules to use a custom renaming
No need for the empty 80- file if you have a 70- file to do the rename. (or would the presence of both files fail, since there wouldn't be an interface for the 70- rule to rename?)

ssuominen - thanks for your persistence in putting up with all of us so politely, and continuing to explain. It's all obvious once you understand it - but not before that.

[SamuliSuominen]

So - is this correct for /etc/udev/rules.d?
- 80-net-name-slot.rules can be a modified version of the one in /lib/udev/rules.d to modify the kernel naming
- 80-net-name-slot.rules is present and empty (expect perhaps for comments) will block the new kernel naming
(In both the above cases, the presence of this file overrides the use of /lib/udev/80-net-name-slot.rules)
- 70-my-network.rules to use a custom renaming
No need for the empty 80- file if you have a 70- file to do the rename.

Correct.

As for old files:

I've put up text to at least the Gentoo wiki[1]

"Any file you haven't created or edited yourself in /etc/udev/rules.d should be backupped and removed as it's likely an relic from old udev installation."

[1] http://wiki.gentoo.org/wiki/Udev/upgrade

The news item also says:

"In a normal new installation there are no files in /etc/udev/rules.d and if you haven't edited any files you have in there, you should most likely backup and delete them all if they don't belong to any packages."

In many times, 'emerge sys-fs/udev' in the end will either warn or automatically remove some old files from /etc/udev/rules.d but not everything can be automated, unfortunately.

[depontius]

A few clarifications, because perhaps I'm being thick...

1 - In the news article, they give 2 lines to keep my good old eth0/eth1 names. Do those lines go in 70-persistent-net.rules, or do they go in 80-net-name-slot.rules? Maybe at some future date I'll migrate to the newfangled device names, but not today, and not tomorrow. I simply don't know everywhere on my systems where "eth0" or "eth1" might be references, and don't feel like chasing it all down right now. On a new install I'll probably let the default names happen.

2 - The news article talks about removing "udev-postmount". I don't have that on any of my systems, I have "udev" and "udev-mount". Do you really mean to remove "udev-mount": from the sysinit runlevel?

3 - Whatever happened to CD/DVD naming? How has that all sugared out? I threw a kludge into my local.d to paper this one over. Is i still necessary or has Lennart still decided that every media player in the Linux world is WRONG by using names like /dev/dvd or /dev/cdrom? (Pardon the minor diatribe, it was a short weekend, and I held back for most of this post.)

[SamuliSuominen]

A few clarifications, because perhaps I'm being thick...

1 - In the news article, they give 2 lines to keep my good old eth0/eth1 names.

Umm. No it doesn't. It tells explictely those 2 lines are now old and shouldn't be used. Only way to use eth* is to disable entire new networking from udev by adding empty 80-net-name-slot.rules, or symlink it to /dev/null, that will mean kernel will do all the naming which can be random.
Either use the new names or rename to free namespace like net* or similar.
You must have read wrong.

2 - The news article talks about removing "udev-postmount". I don't have that on any of my systems, I have "udev" and "udev-mount". Do you really mean to remove "udev-mount": from the sysinit runlevel?

It means exactly udev-postmount. Not udev, or udev-mount.

3 - Whatever happened to CD/DVD naming? How has that all sugared out? I threw a kludge into my local.d to paper this one over. Is i still necessary or has Lennart still decided that every media player in the Linux world is WRONG by using names like /dev/dvd or /dev/cdrom? (Pardon the minor diatribe, it was a short weekend, and I held back for most of this post.)

/dev/cdrom is now always a symlink to /dev/sr0 and the others are gone in purpose so any software defaulting to /dev/dvd should be fixed to default to /dev/cdrom
the only way to get back /dev/dvd is by writing a custom rule
if /dev/cdrom is still missing with the new udev, it's because some old file in /etc/udev/rules.d, like the old 70-persistent-cd.rules is breaking it

[depontius]

A few clarifications, because perhaps I'm being thick...

1 - In the news article, they give 2 lines to keep my good old eth0/eth1 names.

Umm. No it doesn't. It tells explictely those 2 lines are now old and shouldn't be used. Only way to use eth* is to disable entire new networking from udev by adding empty 80-net-name-slot.rules, or symlink it to /dev/null, that will mean kernel will do all the naming which can be random.
Either use the new names or rename to free namespace like net* or similar.
You must have read wrong.

Actually I was wondering about these 2 lines :

Code: Select all

This is the new format with free namespace:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="net1"

Calling it "new" makes me thing it's still/now usable.

2 - The news article talks about removing "udev-postmount". I don't have that on any of my systems, I have "udev" and "udev-mount". Do you really mean to remove "udev-mount": from the sysinit runlevel?

It means exactly udev-postmount. Not udev, or udev-mount.

As far as I know, I've never had udev-postmount. I certainly don't have it on any of my Gentoo systems I can currently access. (There's one at home powered down right now.) On all of my systems I have udev and udev-mount, so at this point I'm more wondering why I don't have udev-postmount anywhere.

3 - Whatever happened to CD/DVD naming? How has that all sugared out? I threw a kludge into my local.d to paper this one over. Is i still necessary or has Lennart still decided that every media player in the Linux world is WRONG by using names like /dev/dvd or /dev/cdrom? (Pardon the minor diatribe, it was a short weekend, and I held back for most of this post.)

/dev/cdrom is now always a symlink to /dev/sr0 and the others are gone in purpose so any software defaulting to /dev/dvd should be fixed to default to /dev/cdrom
the only way to get back /dev/dvd is by writing a custom rule
if /dev/cdrom is still missing with the new udev, it's because some old file in /etc/udev/rules.d, like the old 70-persistent-cd.rules is breaking it

[/quote]

If they had to pick one name, it would have been better /dev/dvd, since CDs are almost obsolete at this point. I'll have to change more /dev/dvd configurations than I would have had to change /dev/cdrom.

[risa2000]

Umm. No it doesn't. It tells explictely those 2 lines are now old and shouldn't be used. Only way to use eth* is to disable entire new networking from udev by adding empty 80-net-name-slot.rules, or symlink it to /dev/null, that will mean kernel will do all the naming which can be random.
Either use the new names or rename to free namespace like net* or similar.
You must have read wrong.

This is interesting. After an upgrade to udev-200 I have the interface ethv on my system, created by "my persistent rules" in /etc/udev/rules.d. I have not added the command line argument to the kernel to turn off new naming scheme and I also do not keep 80-net-name-slot.rules anymore in /etc/udev/rules.d.

So I wonder, could it be because I run vanilla kernel 3.8.4 and not gentoo sources? Why is my interface renamed correctly when you say the complete namespace eth* is no longer supposed to work?

[SamuliSuominen]

Umm. No it doesn't. It tells explictely those 2 lines are now old and shouldn't be used. Only way to use eth* is to disable entire new networking from udev by adding empty 80-net-name-slot.rules, or symlink it to /dev/null, that will mean kernel will do all the naming which can be random.
Either use the new names or rename to free namespace like net* or similar.
You must have read wrong.

This is interesting. After an upgrade to udev-200 I have the interface ethv on my system, created by "my persistent rules" in /etc/udev/rules.d. I have not added the command line argument to the kernel to turn off new naming scheme and I also do not keep 80-net-name-slot.rules anymore in /etc/udev/rules.d.

So I wonder, could it be because I run vanilla kernel 3.8.4 and not gentoo sources? Why is my interface renamed correctly when you say the complete namespace eth* is no longer supposed to work?

You are right, when I talked about complete namespace... I meant the reserved bits of said namespace, for example if kernel assigns eth0 and eth1, then eth3, eth4, eth5, ethx, ethy, ethv, would still be free and usable. It just means you can't swap in-place between eth0 and eth1 anymore.
It's just, in my personal opinion, easier to explain it the way I did as using complete free namespace like net* is just easier. So keep on using ethv, kernel is unlikely to ever assign name like that.

[astaines]

Hi,
I read the various threads on udev upgrades, I must admit with some trepidation, but I dove in, and it worked. I have a fairly common setup on a HP laptop - one wired ethernet connection (formerly eht0) and one wireless connection (formerly wlan0) both managed with wicd.

Here's what I did.

• Delete all files in /etc/udev/rules.d apart from one i wrote myself to give a specific name to specific USB disk. In particular I had a 70-persistent-net.rules and a 70-persistent-cd.rules, both of which I moved to the /root directory
• Emerge udev 200
• etc-update (nothing needed updating

Then I rebooted. On rebooting there were no network devices visible at all. Wicd started, but could make no cconnections. ifconfig returned only the lo connection

Code: Select all

HP init.d # ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 2430  bytes 194588 (190.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2430  bytes 194588 (190.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

So, no panic. dmesg is your friend, or at least, mine.

Code: Select all

HP init.d # dmesg | grep eth0
[    2.298932] tg3 0000:85:00.0: eth0: Tigon3 [partno(BCM95751) rev b002] (PCI Express) MAC address d8:d3:85:20:56:34
[    2.300548] tg3 0000:85:00.0: eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    2.302179] tg3 0000:85:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    2.303815] tg3 0000:85:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[    7.616563] systemd-udevd[1313]: renamed network interface eth0 to enp133s0

and

Code: Select all

HP init.d # dmesg | grep wlan0
[    8.764556] systemd-udevd[1312]: renamed network interface wlan0 to wlp2s0

This tells me that my two interfaces are called enp133s0 and wlp2s0, respectively, which is what I needed to know.

In the file /etc/wicd/manager-settings.conf change

Code: Select all

[Settings]
backend = external
wireless_interface = wlan0
wired_interface = eth0
wpa_driver = wext
always_show_wired_interface = True

to read

Code: Select all

Settings]
backend = external
wireless_interface = wlp2s0
wired_interface = enp133s0
wpa_driver = wext
always_show_wired_interface = True

I also added net.enp133s0 as a symlink to net.lo

Code: Select all

ln -s /etc/init.d/net.lo /etc/init.d/net.enp133s0

I don't know if I needed to do that, but I did anyway. I still have net.eth0 as a symlink to net.lo, and I don't know if I ought to remove it. Then a quick

Code: Select all

/etc/init.d/wicd restart

and all is well.

Regards,
Anthony

[rogerx]

astaines: Upon sync and upgrading on Sunday, in other words I upgraded to the latest sys-fs/udev sys-fs/udev-init-scripts, I found no interfaces within ifconfig upon booting this morning and no "/etc/wicd/manager-settings.conf" file(s). I too also removed /etc/udev/rules.d/* to /root, and rebooted. (I too require custom /etc/udev/rules since I have two on-board ethernet PCIE with an add-on wireless PCIE, requiring ordering to initialize the Intel PCIE first and all others secondary. But shouldn't have been an issue since I read the eselect news posts and removed those files, and rebooted.)

Saw this coming within the past weeks too, and had a gut feeling things were going to break. I give -1 votes for security with this recent udev upgrade.

A better, secure method:

# echo "=sys-fs/udev-200" >> /etc/portage/package.mask
# echo "=sys-fs/udev-init-scripts-25" >> /etc/portage/package.mask

# emerge =sys-fs/udev-197-r8
# emerge =sys-fs/udev-init-scripts-23

(NOTE: I have fixed this within my follow-up post @ 9:53 to ssuominen's replay below, and am now using the recent udev/udev-init-scripts! I completely agree with Kollin's comment below, regarding "If it works, why fix it." I have a gut feeling, I might be struggling with this renaming for the next year due to secondary issues, and I also have to migrate several other x86 platforms as their network is now broken.)

[SamuliSuominen]

astaines: Upon sync and upgrading on Sunday, in other words I upgraded to the latest sys-fs/udev sys-fs/udev-init-scripts, I found no interfaces within ifconfig upon booting this morning and no "/etc/wicd/manager-settings.conf" file(s). I too also removed /etc/udev/rules.d/* to /root, and rebooted. (I too require custom /etc/udev/rules since I have two on-board ethernet PCIE with an add-on wireless PCIE, requiring ordering to initialize the Intel PCIE first and all others secondary. But shouldn't have been an issue since I read the eselect news posts and removed those files, and rebooted.)

Saw this coming within the past weeks too, and had a gut feeling things were going to break. I give -1 votes for security with this recent udev upgrade.

A better, secure method:

# echo "=sys-fs/udev-200" >> /etc/portage/package.mask
# echo "=sys-fs/udev-init-scripts-25" >> /etc/portage/package.mask

# emerge =sys-fs/udev-197-r8
# emerge =sys-fs/udev-init-scripts-23

The same feature is already in 197. It's just disabled there by default and random kernel assigned names are used by default.
You can continue disabling the feature with 200 as instructed by the news item and continue using the random kernel assigned names.
As in, the only difference is the "empty" file in /etc/udev/rules.d/80-net-name-slot.rules in place with default 197-r8 installation, not anymore in place with 200.
If you had read the news item, you would have known this and been able to make more informed decisions.

[rogerx]

Sorry. I read the eselect news items *completely* within the past months. ;-)

# dmesg |less

(And search for your network module name. Once found, search to the last mention of your module name for the kernel renaming it to another name.)

[ 0.363538] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
...snip...
[ 0.622276] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
...snip...
[ 2.999320] systemd-udevd[1296]: starting version 200
[ 3.728293] systemd-udevd[1326]: renamed network interface eth0 to eno1


Rename or move the init.d script to the proper interface name
# mv /etc/init.d/net.eth0 to /etc/init.d/net.eno1

Replace "eth0" within "/etc/conf.d/net" with "eno1"
# sed -i 's/eth0/eno1/g' /etc/conf.d/net

Restart udev
# /etc/init.d/udev restart


I do not think the "eselect news" post(s) were not quite clearly worded though. (Or maybe it was just embedded within a large paragraph "4. predictable network interface names:".)

"You can prepare the system for the new names before booting for example
by renaming /etc/init.d/net.* symlinks, editing /etc/conf.d/net, etc."

Should have been more explicitly worded such as "NOTE: If you are currently using eth0/net.eth0, you will need to rename or edit your /etc/init.d/net.* symlinks and editing /etc/conf.d/net, etc..." The current wording used, within the post was wordy and assumed readers knew what "4. predictable network interface names" was!

In other words, clearly state the steps, setting them aside from customized users' details.

I usually try to proof read my posts from a dummy's perspective before posting, especially when detailing instructions. It helps with other readers' comprehension. (ie. Keep it simple, keep it stupid) ... No pun intended here. (Matter of fact, could likely use a sed script within the ebuild to look out for net.eth0/eth0 naming?)

[Kollin]

I'm not an ancient Gentoo user but I'm remembering an old saying: "If it works - don't fix it"...
I think i'm going to stick with the old "unpredictable" network names, the new "predictable" ones just gave me pain last week (hostapd wpa_supplicant and iptables just fell apart)

[rogerx]

I just checked-out my older x86 box this morning and found, as I suspected earlier, I had completely neglected to modify or remove any /etc/udev/rules.d, and the box's network still works like a charm! Against what the eselect news post likely foretold.

I suspect a fallback method, or this may have been an April Fools joke aimed at those reading the "eselect news" posts. :-/

So likely most people's boxes will continue to work with the default configurations? Especially since, they likely ignore the "eselect news" posts?

(As such, I'm leaving things as they are, and likely reverting the changes I made on this box, letting the future dictate it's demise. ;-)

[andip]

i don't care what my new nic-names are, as long as i can be told beforehand, and that they ARE predictable, preferably across computers too. therefore :

"4. predictable network interface names:

If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
symlink to /dev/null, the new names will be disabled and the kernel will
do all the interface naming, and the resulting names may vary by kernel
configuration, hardware configuration and kernel version."

worries me...

Do i not understand this, and maybe i'm just too thick for "new" udev/gentoo, but..
I should remove 70 files, and the 80 says itself that

"To activate this function, move this file to a name that doesn't end in.rules,
# or remove it then reboot your system."

At the same time i'm told in eselect news that interface naming will be done by kernel and may vary by kernel configuration, hardware configuration and kernel version. (who here has many systems that are identical in both hardware and kernel version/config??).

this is how i've come to understand this change, and i do appreciate i can have it very wrong, but if i'm not.. :
remove both 70 files and edit 80-file to keep my system up to date and ready for the next change, or is there NO drawback to keeping the 70-files (not ending in rules), and the old eth*-names?

i really don't see what's "good" about me having to edit my udev-files, with a cryptic syntax, for the first time EVER. this to get a name i choose myself, rather than one generated by the kernel.

the best joke in all this though : "Udev 197 and above has implemented predictable network interface names....". FYI, my main network interface has been called eth0, on many different hardware/kernel-variants, for at least 15 years. if that's not predictable, what is?

well, i'm sorry if this was too much nagging, but my problem is. what do i do?

[rogerx]

andip: well, i'm sorry if this was too much nagging, but my problem is. what do i do?

I'm by far a UDEV expert, however I have written a few custom scripts, etc.

Try not to worry too much and just revert to the old method, as it currently seems harmless and await for the future to resolve this, as it always does? ;-)

BTW: As I previously mentioned and based on my experience; If you failed to have read the "eselect news" post dated 2013-03-29 by Samuli Suominen, or ignored it, then it's very likely you still have a working network naming scheme. And as such, the majority likely still have a working network schemes.

Agreed, the news post wasn't easily comprehensible and I did post a polite recommendation to reread posts (or instructions) as if reading from a dummies perspective in order to verify instructions.

Imagine an 80 year old who can no longer go upstairs to maintain or fix his boxes', and is required to as his SSH daemon (or his network) is now broken. Now he has permanently broken boxes because he read a news post. ;-)

The previously mentioned scenario is relevant, albeit slightly convoluted, as it involves boxes' stability or security of reliability. I further suggest, in accordance with my above posts, to utilize sed or grep within a pre emerge script for searching for incompatible configuration files or contents of files, and halt the emerge udev upgrade, rather than just proceeding and merrily mentioning a warning with the result of breaking a box's network. Shrugs, just a thought.

[SamuliSuominen]

the best joke in all this though : "Udev 197 and above has implemented predictable network interface names....". FYI, my main network interface has been called eth0, on many different hardware/kernel-variants, for at least 15 years. if that's not predictable, what is?

The news item says:

In a normal new installation there are no files in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely backup and delete them all if they don't belong to any packages.

So you can wipe the /etc/udev/rules.d directory clean for starters to have a clean slate.

Code: Select all

# mv /etc/udev/rules.d/* /root/

Then you decide what you want.

If the machine only has one interface, eth0, the news item says:

If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
symlink to /dev/null, the new names will be disabled and the kernel will
do all the interface naming, and the resulting names may vary by kernel
configuration, hardware configuration and kernel version.

As in, run the following:

Code: Select all

# ln -nfs /dev/null /etc/udev/rules.d/80-net-name-slot.rules

And nothing will change, as in, eth0 will stay as eth0 and there is no risk of it being random... because there is nothing it would be random with, as being the only interface.

Is that what you wanted?

[rogerx]

Yes. Exactly.

Another method I often use when writing instructions, try to conform to an outline format.

Outline formats help keep complicated irrelevant issues separate of default configuration files. Keeping things simple for simple minded folks. And, the instructions do not have to conform specifically to an outline format, but just follow it somewhat loosely. (ie. Omit numbers, roman numerals, indentations, etc)

In other words, documentation is much like building a pyramid or building. If the base or beginnings are confusing, than later parts will be exponentially confusing.

Much of the excellent (Gentoo) Wiki and Documentation conforms to something similar as mentioned above. ;-)

Yes, I know when there's trivial fixes/patches, I find small jottings better than nothing, and rarely ever complain or worry as not many are effected by them. But with issues such as udev renaming eth0, it's a little bit more important.

Thanks for your time recognizing this issue and your time volunteering.

[andip]

hello

ssuominen : thanks, that was somewhat clarifying. i do have a wlan interface too, that i sometimes use, and i don't know what'll happen to that, if i follow your instructions.

seems that "net.ifnames=0" on the kernel command line is the way to go for me, as i've never had any problems with not predictable if-names.

[Thistled]

I feel like I am the 80 year old who can not get up the stairs.
I have followed the guide to the letter, and all seems well with regard to that, but....
networkmanager fails to start because

Code: Select all

libudev.so.0 is missing

.
As a result of this some of my IMPORTANT services fails to start, which isn't funny when you are using NFS to host portage on a separate box.
A revdep-rebuild does not find anything to do with networkmanager.

I have used locate to find some other libudevs, but libudev.so.0 is not there.

Should I be symlinking to one of the more recent libraries?

It aint funny having to go down the systemrescue CD route in order to try and fix this.

Also, this update has killed gnome. (stuck with the GDM blue desktop and a busy mouse pointer for over 3 days now).
But, that is a separate issue I suppose.

[miket]

Code: Select all

libudev.so.0 is is missing

Well, you're up against the March of the Sonames. It doesn't matter if you've got udev or eudev: the soname has moved to libudev.so.1.

A dependency of Network Manager might be the thing holding you back. Try

Code: Select all

revdep-rebuild --library libudev.so.0

to find the package that still wants the old version of the library. Symlinking will get you into lots of trouble--try this revdep-rebuild instead.

(Of course, I always end up throwing in a -vp when I run revdep-rebuild the first time.)