EDIT: I implemented the delay tactic in the 5th post. I'll go back and fool with the new system when I have time. It is odd though because even the stable udev did not work. Anyway, the net is back using udev. Thanks for the help guys._________________First things first, but not necessarily in that order.

Last edited by The Doctor on Tue Jan 22, 2013 3:48 am; edited 2 times in total

Do you have /etc/udev/rules.d/80-net-name-slot.rules? It should have been copied in place when you emerged udev. If it's missing, it would indeed cause missing eth*. If you have it, read it.

Also renaming changed, so old 70- rules in /etc/udev/rules.d/ might not work without modifying them, like renaming eth0 first to eth0tmp and then to eth1, and not directly to eth1 -- as in, swapping them directly is not possible as kernel has not really allowed it properly so it was dropped from udev.

Otherwise it should be same as with 171. Certainly this would be the first time I'm hearing problems if it's not one of those.

Do you have /etc/udev/rules.d/80-net-name-slot.rules? It should have been copied in place when you emerged udev. If it's missing, it would indeed cause missing eth*. If you have it, read it.

No, ls says that I do not. I don't have anything in /etc/udev/rules.d/

If you use 197-r4 and emerged it straight off from ~arch, that means you selected "unstable" udev and the new network naming scheme took place. There is postinst message about it when you emerge udev. You can find more information from here:

If you use 197-r4 and emerged it straight off from ~arch, that means you selected "unstable" udev and the new network naming scheme took place. There is postinst message about it when you emerge udev. You can find more information from here:

If you want the old eth* naming back, and not switch to the new naming yet, all you have do is put a dummy file called 80-net-name-slot.rules in /etc/udev/rules.d/

Dummy as in, it can be like:

Code:

# No, I don't want the switch yet. Thanks.
# End of file.

If you are after stability, you of course use stable udev which is 197-r3.

Thanks for the link. That may explain it, I'll need to reboot to test that. Udev did not say anything about it. It just warned me about a separate /usr. This is probably because it is a fresh install, so only sys-fs/eudev-1_beta1-r2 and sys-fs/udev-197-r4 have been installed and I had to emerge -C them to switch past the blocks. It looks like that is not enough to trigger the messages. Thanks for the help._________________First things first, but not necessarily in that order.

If you use 197-r4 and emerged it straight off from ~arch, that means you selected "unstable" udev and the new network naming scheme took place. There is postinst message about it when you emerge udev. You can find more information from here:

If you want the old eth* naming back, and not switch to the new naming yet, all you have do is put a dummy file called 80-net-name-slot.rules in /etc/udev/rules.d/

Dummy as in, it can be like:

Code:

# No, I don't want the switch yet. Thanks.
# End of file.

If you are after stability, you of course use stable udev which is 197-r3.

Thanks for the link. That may explain it, I'll need to reboot to test that. Udev did not say anything about it. It just warned me about a separate /usr. This is probably because it is a fresh install, so only sys-fs/eudev-1_beta1-r2 and sys-fs/udev-197-r4 have been installed and I had to emerge -C them to switch past the blocks. It looks like that is not enough to trigger the messages. Thanks for the help.

It says it only once I think, if I don't remember wrong the ebuild has kludge to prevent double posting. Yes, indeed emerge -C or fresh install would cause it. Once the file is there, it won't be taken away by anything so you can keep on using -r4 and keep the file for long as you want there.

And indeed, the reason why eudev didn't have this "issue" is that they don't have the new networking scheme (yet). In fact, I've created 197 virtual for udev to mark the start of the predictable network interface support and ditched the 196 virtual away. So I'm not sure if we are playing a bit of catch up here or what.

Last edited by ssuominen on Wed Jan 23, 2013 11:35 am; edited 3 times in total

They have changed the networking to be even more reliable so I guess it's worth to getting used to and with Fedora backing I'd expect we have source of patches for various mainline apps

And anyone with 70-persistent-net.rules still in place now gets a warning from the udev ebuild. That's the very least we can do.

(I've used this thread because it seemed to match the most and is about networking in 197. No need to reply to this. I don't expect anyone to.)

I'm not shooting the messenger, here. Really.

This udev change deserves a news item and a sticky thread, all its own. It has caused a lot of grief so far and spawned several forum threads, and it sounds like that trend is going to continue, if not get worse. I got bit on the cdrom/dvd persistent names issue. I don't know if the recent udev-197-r3 update fixed that or not - I made my ugly hack at least smart enough to not interfere if it had.

This broke userspace - it broke EVERY piece of optical device software out there. Had this been a kernel interface, Linus would have crucified someone.

It sounds like the same thing is about to happen in network devices. I won't deny that perhaps the new network naming is better - or at least more consistent. But I will say that it completely ignores decades of tradition. A compromise would have been to use something like the optical device persistent names - but with traditional names like our good old eth0, eth1, ... wifi0, ...

Oddly enough the clueless noob who doesn't configure anything will be better off, because he/she won't have things like "config_eth0=..." sitting anywhere to become stale.

RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", except when it doesn't, then abandon all hope, because we're removed, hidden, obscured, or obfuscated the knobs that allow you to make it work. Your choices are to be a complete clueless noob, or to become a near-developer - the self-educated hacker is out of luck._________________.sigs waste space and bandwidth

This udev change deserves a news item and a sticky thread, all its own. It has caused a lot of grief so far and spawned several forum threads, and it sounds like that trend is going to continue, if not get worse. I got bit on the cdrom/dvd persistent names issue. I don't know if the recent udev-197-r3 update fixed that or not - I made my ugly hack at least smart enough to not interfere if it had.

The /dev/cdrom symlink is working again with 197-r3. It was a choice between broken path-by symlinks and cdrom symlink in 171; just another case where it was no longer compatible with current stable gentoo-sources.

And I've sent a news item to the gentoo-dev ML an hour ago for review. Yes, I'm aware it's late for part of the users but not for everyone; servers get updated last in my experience so it's still important for many.

And otherwise about your last post, no comment, it doesn't really involve the package maintainer but rather the upstream. Like you pointed out with the messenger note.

The /dev/cdrom symlink is working again with 197-r3. It was a choice between broken path-by symlinks and cdrom symlink in 171; just another case where it was no longer compatible with current stable gentoo-sources.

I'll give it a try, when I'm back at that system, perhaps tonight.

For curiosity, is there a way to find out what the new name for eth0 would be, without blowing up a boot by removing the dummy net-name-slot.rules file? By the way, does the loopback name change, in the new regime? (What happens to "tap0", "tun0"?)

This is going to make net configuration much more difficult, because it's just not clear what the network names are going to be on any given machine getting a new install. That is, unless you're happy to just accept default dhcp, with all of the default assignments the dhcp server makes. (Just Works (TM))

By the way, a few years back I was bit by the inconsistent network naming, when eth0 and eth1 swapped names on a new kernel. It was a sonofoagun to debug, but it also taught me about ARP and that lower layer of protocol._________________.sigs waste space and bandwidth

Lul, it's great that you've done the research and documented that for us. It doesn't half look like a clueless setup, though (which is nothing to do with you of course.) Workarounds to find out what the "convenience" layer has done to your configuration smell bad.

I've read through this thread and also read News item 2013-01-23-udev-upgrade but I'm still confused and would be grateful for additional clarification before I go ahead and install the latest version of udev.

I currently have the following udev-related packages installed on my main laptop:

# This file was automatically generated by the /lib64/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

Please let me know if either/both of the above are wrong, and what I should be doing instead. Thanks._________________Clevo W230SS: amd64, OpenRC, Optimus.
Compal NBLB2: ~amd64, OpenRC, FGLRX, dual booting with Windows 7 Professional 64-bit.
KDE on both laptops.Fitzcarraldo's blog

1. If I want my laptop to behave exactly as it did before, do I have to:
1.1 create the file /etc/udev/rules.d/80-net-name-slot.rules manually, or is it installed automatically?
1.2 leave the file /etc/udev/rules.d/70-persistent-net.rules exactly as it is was before?
1.3 create the initscript given in Gentoo Bugzilla Bug Report No. 453494 and add it to the sysinit runlevel?

Remove persistent-cd rules in any case, this file isn't needed anymore. Edit persistent-net rules following the example in the comments of the workaround script. Add the workaround script to sysinit runlevel. Read the comments in the workaround script and you don't have to ask as it should be self-explanatory. Make sure 80-net-name-slot.rules is there too to prevent the new
scheme from taking over. As for the other rules you have in /etc/udev/rules.d/ if you didn't create them yourself, they shouldn't even be there. If they are part
of some packages, please use https://bugs.gentoo.org/ so the package maintainers get a chance of fixing the path to /lib/udev/rules.d/ using the udev.eclass and
$(udev_get_udevdir) function.

Fitzcarraldo wrote:

2. If, instead, I want my laptop to use the new network device naming convention, do I have to:
2.1 delete the file /etc/udev/rules.d/80-net-name-slot.rules if it was installed automatically?
2.2 leave the file /etc/udev/rules.d/70-persistent-net.rules exactly as it is was before?
2.3 create the initscript given in Gentoo Bugzilla Bug Report No. 453494 and add it to the sysinit runlevel?
2.4 do anything else (and, if so, what)?

Remove 80-net-name-slot.rules, remove 70-persistent-net.rules (hey, backup?), don't use the workaround init script, read the page[1] and figure out which names you want to use. Propably
the MAC based ones, and I'm basing this assumption on the 70-persistent-net.rules you had.

Thanks for the rapid reply, ssuominen. I took the plunge and performed an 'emerge -uvDN world' and it installed udev-197-r4 and udev-init-scripts-21. I opted to stick with the existing network interface naming convention, so I followed your first set of instructions and also the ewarn message telling me to run 'emerge -av1 \$(qfile -q -S -C /usr/lib/udev)'.

However, the following message is displayed during start-up, and there is a delay before start-up continues:

Code:

ERROR: ethtmp failed to start

The directory /etc/udev/rules.d/ now contains:

Code:

10-usbprinter.rules 70-persistent-net.rules 80-net-name-slot.rules

where 10-usbprinter.rules is a rule I had created for my Canon MP560 MFP, I had to create 80-net-name-slot.rules that contains just comments, and I edited 70-persistent-net.rules so that it now contains:

So apparently the initscript in the bug report is not needed, only the dummy rule file /etc/udev/rules.d/80-net-name-slot.rules and the rule file /etc/udev/rules.d/70-persistent-net.rules with the modified contents listed above.

I think I'm going to leave well alone for now, as I've had enough of messing around with udev for a while. _________________Clevo W230SS: amd64, OpenRC, Optimus.
Compal NBLB2: ~amd64, OpenRC, FGLRX, dual booting with Windows 7 Professional 64-bit.
KDE on both laptops.Fitzcarraldo's blog

Even so, I'm not sure why the initscript is giving the error message "ERROR: ethtmp failed to start". What am I doing wrong?

Use the latest script from https://bugs.gentoo.org/show_bug.cgi?id=453494 because it was improved in a way it's less error prone. You still have
to edit it for others than eth*
The copy you were using failed if the value that is now {0..9999} in the script didn't match the amount of interfaces to rename, like with three NICs it would be {0..2}, as in 0, 1 and 2.
Delete the old copy.

So apparently the initscript in the bug report is not needed, only the dummy rule file /etc/udev/rules.d/80-net-name-slot.rules and the rule file /etc/udev/rules.d/70-persistent-net.rules with the modified contents listed above.

I think I'm going to leave well alone for now, as I've had enough of messing around with udev for a while.

I went with info you've provided, closed my eyes and sent "reboot" cmd over the network to a machine half way around the world, after udev upgrade 171-r10 -> 197-r3. And it came back online a minute later, interfaces setup as defined in updated 70-persistent-net.rules. Thank you! I can confirm that this is (still) working on my install.

I have no idea if it's related but "scsi-" prefix seems to be "ata-" nowadays @ /dev/disk/by-id/. That broke a couple of mount points after reboot, but that's another story._________________only sheep need a leader.

This thread is pretty useful, but there are a couple of points I don't understand.
Does the CONFIG_DEVTMPFS needed by udev-197 also need the automount option?
Does fstab need to be modified to match?

1. CONFIG_DEVTMPFS is enough because OpenRC/baselayout will mount it for you, but CONFIG_DEVTMPFS_MOUNT is recommended and somewhat more reliable.
2. If you have /dev in /etc/fstab, it's likely you can simply delete whole line, but if not, then put "devtmpfs" in the fstype part of the line. With this I mean exactly /dev, and not like /dev/shm.
3. If you have /dev/shm in /etc/fstab it's likely you can simply delete whole line, this is mounted by the udev-mount init script it seems. Either way I have it mounted just fine without any line for it.

Here is snip from my `mount` output without /dev and /dev/shm being in fstab at all. The defaults suit most people.