# 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

 *genterminl wrote:*   

> 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.

 *genterminl wrote:*   

> 
> 
> 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.

 *genterminl wrote:*   

> 
> 
> 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

 *genterminl wrote:*   

> 
> 
> 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
> ...

 

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

 *depontius wrote:*   

> 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.

 *depontius wrote:*   

> 
> 
> 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.

 *depontius wrote:*   

> 
> 
> 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

 *ssuominen wrote:*   

>  *depontius wrote:*   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.
> 
>  
> ...

 

Actually I was wondering about these 2 lines :

```
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.

 *ssuominen wrote:*   

> 
> 
>  *depontius wrote:*   
> 
> 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?
> ...

 

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.

 *ssuominen wrote:*   

> 
> 
>  *depontius wrote:*   
> 
> 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.)
> ...

 [/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

 *ssuominen wrote:*   

> 
> 
> 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.
> ...

 

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

 *risa2000 wrote:*   

>  *ssuominen wrote:*   
> 
> 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 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

```

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.

```

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

```

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

```
[Settings]

backend = external

wireless_interface = wlan0

wired_interface = eth0

wpa_driver = wext

always_show_wired_interface = True

```

to read

```

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

```

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

```

/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

 *rogerx wrote:*   

> 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:
> ...

 

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)  :Confused: 

----------

## 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 : 

 *Quote:*   

> "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
> ...

 

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  *Quote:*   

> "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

 *andip wrote:*   

> 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:

 *Quote:*   

> 
> 
> 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
> ...

 

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

```

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

```

Then you decide what you want.

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

 *Quote:*   

> 
> 
> 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
> ...

 

As in, run the following:

```

# 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.    :Laughing: 

I have followed the guide to the letter, and all seems well with regard to that, but....

networkmanager fails to start  because

```
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

 *Thistled wrote:*   

> 
> 
> ```
> 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

```
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.)

----------

## Thistled

Hey MikeT, cheers for the tip.

Eventually, revdep-rebuild fixed the issue.

Because my box had been down for so long (and I had been away traveling the UK for a week), I completely forgot I had ran a previous revdep-rebuild in pretend mode.

That meant when I ran revdep-rebuild this time around, it was highlighting what it had previously found, and not the current issue.   :Confused: 

So...

```
revdep-rebuild -i
```

fixed the problem.   :Embarassed: 

Another example of a user being a complete ****head and not Gentoo to blame.

My udev transition has gone a treat thanks to all the tips from ssuominen.

Now I have latest udev, systemd and Gnome-3.8.

This is the bit which is really sad, my box may have been down for a while, but getting to the latest Gnome using systemd has been worth the wait.

Now I have to fix a few problems with some failing systemd services, but I'm getting there.

Peace.  :Cool: 

----------

## painteru

Hi there,

I'm trying to get the pppoe connection up now when I've started a new gentoo  OS installation.

I'm using the latest  minimal iso (Aug 20)

Well, even that pppoe-start said : Connected

pinging www doesn't work

I know that in the past in order to get pppoe working , I had to stop net.eth*

The problem is now that there's no net.eth anymore since the new udev.

My network card got a name something like enp4s1 and don't know how to stop it.

Any advicees how to set up working a pppoe connection on the new udev conditions?

Thank you,

Daniel

----------

## Killerchronic

Same as you would before but replace eth0 with enp4s1.

----------

