Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Network: eudev does, udev does not [SOLVED]
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Tue Jan 22, 2013 2:49 am    Post subject: Network: eudev does, udev does not [SOLVED] Reply with quote

Since a separate /usr is now working with udev and NOT eudev :roll:, I decided to try going back. It works well, except I no longer have wlan0, or eth0 8O 8O

I tried adding their modules to /etc/conf.d/moduels, but this had no affect. ifconfig does not see them and wicd cannot connect.

Anyway, here is emerge -pv eudev sys-fs/udev
Code:
[ebuild   R    ] sys-fs/eudev-1_beta1-r2  USE="gudev hwdb kmod modutils openrc static-libs -doc -introspection -keymap (-selinux)" 0 kB
[ebuild  N     ] sys-fs/udev-197-r4  USE="acl gudev hwdb kmod openrc static-libs -doc -introspection -keymap (-selinux)" 0 kB


Any hints as to what is going on?!

Thanks

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.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.


Last edited by The Doctor on Tue Jan 22, 2013 3:48 am; edited 2 times in total
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w

PostPosted: Tue Jan 22, 2013 3:00 am    Post subject: Reply with quote

eudev and udev control /DEV/eth0 and /DEV/wlan0.... i think you should revert back to udev, and recompile a kernel with config_devtmpfs=y :twisted:
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Jan 22, 2013 3:04 am    Post subject: Re: Network: eudev does, udev does not Reply with quote

The Doctor wrote:
Since a separate /usr is now working with udev and NOT eudev :roll:, I decided to try going back. It works well, except I no longer have wlan0, or eth0 8O 8O

I tried adding their modules to /etc/conf.d/moduels, but this had no affect. ifconfig does not see them and wicd cannot connect.

Anyway, here is emerge -pv eudev sys-fs/udev
Code:
[ebuild   R    ] sys-fs/eudev-1_beta1-r2  USE="gudev hwdb kmod modutils openrc static-libs -doc -introspection -keymap (-selinux)" 0 kB
[ebuild  N     ] sys-fs/udev-197-r4  USE="acl gudev hwdb kmod openrc static-libs -doc -introspection -keymap (-selinux)" 0 kB


Any hints as to what is going on?!

Thanks


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.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Tue Jan 22, 2013 3:05 am    Post subject: Reply with quote

It is already set. Otherwise my initramfs would not work, thanks for the thought though.
Code:
cat /usr/src/linux/.config | grep DEVTMPFS=y
CONFIG_DEVTMPFS=y


For more information, here is my .config
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Tue Jan 22, 2013 3:10 am    Post subject: Re: Network: eudev does, udev does not Reply with quote

ssuominen wrote:
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/ :?:
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.


Last edited by The Doctor on Tue Jan 22, 2013 3:16 am; edited 1 time in total
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Jan 22, 2013 3:15 am    Post subject: Re: Network: eudev does, udev does not Reply with quote

The Doctor wrote:
ssuominen wrote:
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:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

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.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Tue Jan 22, 2013 3:29 am    Post subject: Re: Network: eudev does, udev does not Reply with quote

ssuominen wrote:

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:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

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.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Jan 22, 2013 4:18 am    Post subject: Re: Network: eudev does, udev does not Reply with quote

The Doctor wrote:
ssuominen wrote:

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:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

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 SamuliSuominen on Wed Jan 23, 2013 11:35 am; edited 3 times in total
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Jan 23, 2013 10:44 am    Post subject: Reply with quote

You can get 70-persistent-net.rules working again by workaround if required, see https://bugs.gentoo.org/453494#c21 and the example workaround script using iproute2

This was done by udev internals before but this happened:
http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad

So we have to live with what we have in mainline udev and get used to the new naming:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

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.)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Wed Jan 23, 2013 1:25 pm    Post subject: Reply with quote

ssuominen wrote:
You can get 70-persistent-net.rules working again by workaround if required, see https://bugs.gentoo.org/453494#c21 and the example workaround script using iproute2

This was done by udev internals before but this happened:
http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad

So we have to live with what we have in mainline udev and get used to the new naming:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

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
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Jan 23, 2013 1:48 pm    Post subject: Reply with quote

depontius wrote:

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.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Wed Jan 23, 2013 2:18 pm    Post subject: Reply with quote

ssuominen wrote:

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
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Jan 23, 2013 2:25 pm    Post subject: Reply with quote

As promised, news item is out and is shown to everyone with udev 197 or older.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Wed Jan 23, 2013 3:53 pm    Post subject: Reply with quote

As noted in the override file, the way to check the name is
Code:
udevadm test-builtin net_id /sys/class/net/$(ifname) 2>/dev/null

for any $(ifname) you'll check.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Jan 24, 2013 12:03 am    Post subject: Reply with quote

VoidMage wrote:
As noted in the override file, the way to check the name is
Code:
udevadm test-builtin net_id /sys/class/net/$(ifname) 2>/dev/null

for any $(ifname) you'll check.

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.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Thu Jan 24, 2013 1:44 am    Post subject: Reply with quote

VoidMage wrote:
As noted in the override file, the way to check the name is
Code:
udevadm test-builtin net_id /sys/class/net/$(ifname) 2>/dev/null

for any $(ifname) you'll check.


You mean for the workaround init script in the bug? Does that work even with the init script being "before dev"? If so, feel free to post to the bug with new attachment. ;)
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Thu Jan 24, 2013 3:37 am    Post subject: Reply with quote

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:

Code:
# eix -I udev
[U] dev-python/pyudev
     Available versions:  (~)0.11 (~)0.12 (~)0.13 0.15 (~)0.16.1 {pygobject pyqt4 pyside test}
     Installed versions:  0.15(02:19:58 29/03/12)(pyqt4 -pygobject -pyside)
     Homepage:            http://packages.python.org/pyudev/ http://pypi.python.org/pypi/pyudev
     Description:         Python binding to libudev

[U] sys-fs/udev
     Available versions:  171-r10 197-r3^t (~)197-r4^t **9999^t {acl action_modeswitch build debug doc edd extras floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}
     Installed versions:  197-r1^t(18:11:06 11/01/13)(acl gudev hwdb introspection keymap kmod openrc static-libs -doc -selinux)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[U] sys-fs/udev-init-scripts
     Available versions:  19-r1^t (~)21^t **9999^t
     Installed versions:  19^t(19:43:50 10/01/13)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

[U] virtual/udev
     Available versions:  171 197 {gudev hwdb introspection keymap selinux static-libs}
     Installed versions:  196(19:21:09 10/01/13)(gudev hwdb introspection keymap -selinux -static-libs)
     Description:         Virtual to select between sys-fs/udev and sys-fs/eudev

Found 4 matches.


The directory /etc/udev/rules.d/ on my laptop currently contains the following files:

Code:
00-dgc.rules         51-android.rules        70-persistent-net.rules        kino.rules
10-usbprinter.rules  70-persistent-cd.rules  91-fingerprint-gui-upek.rules  regulatory.rules

and the contents of 70-persistent-net.rules are currently as follows:

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

# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="70:5a:b6:3e:c1:8a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:6a:9a:68:4c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

I have CONFIG_DEVTMPFS set in the 3.6.1-gentoo kernel:

Code:
# cat /usr/src/linux/.config | grep CONFIG_DEVTMPFS
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set


Once I merge udev-197-r4 and udev-init-scripts-21:

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?


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

Please let me know if either/both of the above are wrong, and what I should be doing instead. Thanks.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Thu Jan 24, 2013 4:39 am    Post subject: Reply with quote

Fitzcarraldo wrote:

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.

[1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Thu Jan 24, 2013 8:48 am    Post subject: Reply with quote

ssuominen wrote:
VoidMage wrote:
As noted in the override file, the way to check the name is
Code:
udevadm test-builtin net_id /sys/class/net/$(ifname) 2>/dev/null

for any $(ifname) you'll check.


You mean for the workaround init script in the bug? Does that work even with the init script being "before dev"? If so, feel free to post to the bug with new attachment. ;)


OK, I fail to find the question here.

I was responding to
depontius wrote:
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?
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Thu Jan 24, 2013 11:03 am    Post subject: Reply with quote

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:

Code:
# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="70:5a:b6:3e:c1:8a", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:21:6a:9a:68:4c", NAME="wlan0"

The initscript /etc/init.d/ethtmp has the same contents as your attachment to Gentoo Bug Report No. 453494, and is added to the sysinit runlevel.

ifconfig reports the following:

Code:
# ifconfig
eth0tmp: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::725a:b6ff:fe3e:c18a  prefixlen 64  scopeid 0x20<link>
        ether 70:5a:b6:3e:c1:8a  txqueuelen 1000  (Ethernet)
        RX packets 2879  bytes 2654480 (2.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2751  bytes 379711 (370.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

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 15  bytes 1440 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 1440 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.77  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::221:6aff:fe9a:684c  prefixlen 64  scopeid 0x20<link>
        ether 00:21:6a:9a:68:4c  txqueuelen 1000  (Ethernet)
        RX packets 782  bytes 47998 (46.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70  bytes 39868 (38.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Am I correct in thinking I should modify the initscript as shown below, to include my wireless interface?

Code:
#!/sbin/runscript

# Run this before 70-persistent-net.rules to allow swapping to eth*
#
# OpenRC, example: rc-update add $script_name sysinit
#
# Then you can use rules like, example:
#
# SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="eth0"
# SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="eth1"
#
# You need to have sys-apps/iproute2 installed.

description="Renames ethX to ethXtmp to avoid udev rename conflicts"

depend() {
        before dev
}

start() {
        local i
        for i in {0..9999}; do
                ip link set dev eth${i} name eth${i}tmp 2>/dev/null
                ip link set dev wlan${i} name wlan${i}tmp 2>/dev/null
        done
}

Even so, I'm not sure why the initscript is giving the error message "ERROR: ethtmp failed to start". What am I doing wrong?
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Thu Jan 24, 2013 3:34 pm    Post subject: Reply with quote

I can't see anything wrong with the initscript's permissions:

Code:
# ls -la /etc/init.d/ethtmp
-rwxr-xr-x 1 root root 661 Jan 24 11:22 /etc/init.d/ethtmp


Anyway, it was clearly causing a problem at start-up so I stopped it from being launched at start-up:

Code:
# rc-update del ethtmp sysinit
 * service ethtmp removed from runlevel sysinit

So, in summary, I now have the following udev rules files in the /etc/udev/rules.d/ directory:

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

and the contents of the two relevant rules files are:

Code:
# cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="70:5a:b6:3e:c1:8a", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:21:6a:9a:68:4c", NAME="wlan0"

Code:
# cat /etc/udev/rules.d/80-net-name-slot.rules
# No, I don't want the switch yet. Thanks.
# http://forums.gentoo.org/viewtopic-t-948718-highlight-.html
# End of file.

After rebooting, the two network interfaces now seem to be back to the old naming convention and behaviour:

Code:
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::725a:b6ff:fe3e:c18a  prefixlen 64  scopeid 0x20<link>
        ether 70:5a:b6:3e:c1:8a  txqueuelen 1000  (Ethernet)
        RX packets 6250  bytes 7694933 (7.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4569  bytes 579250 (565.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

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 5  bytes 480 (480.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 480 (480.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:21:6a:9a:68:4c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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. :roll:
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Fri Jan 25, 2013 5:02 am    Post subject: Reply with quote

Fitzcarraldo wrote:

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.
Back to top
View user's profile Send private message
Sh4doW
n00b
n00b


Joined: 13 Mar 2003
Posts: 37

PostPosted: Sat Jan 26, 2013 3:50 pm    Post subject: Reply with quote

Fitzcarraldo wrote:

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


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.
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Sun Jan 27, 2013 10:52 am    Post subject: Reply with quote

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?

Thanks - Will
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sun Jan 27, 2013 11:52 am    Post subject: Reply with quote

cwr wrote:

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.

Code:

devtmpfs on /dev type devtmpfs (rw,relatime,size=8197116k,nr_inodes=2049279,mode=755)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)


If these are coming from the example make.conf in the stage tarball, and these are # commented out, people often uncomment them and think they are necessary. I object! :-)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

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