View previous topic :: View next topic |
Author |
Message |
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Tue Jan 22, 2013 2:49 am Post subject: Network: eudev does, udev does not [SOLVED] |
|
|
Since a separate /usr is now working with udev and NOT eudev , I decided to try going back. It works well, except I no longer have wlan0, or eth0
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 |
|
|
666threesixes666 Veteran
Joined: 31 May 2011 Posts: 1248 Location: 42.68n 85.41w
|
Posted: Tue Jan 22, 2013 3:00 am Post subject: |
|
|
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 |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Tue Jan 22, 2013 3:04 am Post subject: Re: Network: eudev does, udev does not |
|
|
The Doctor wrote: | Since a separate /usr is now working with udev and NOT eudev , I decided to try going back. It works well, except I no longer have wlan0, or eth0
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 |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Tue Jan 22, 2013 3:05 am Post subject: |
|
|
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 |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Tue Jan 22, 2013 3:10 am Post subject: Re: Network: eudev does, udev does not |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Tue Jan 22, 2013 3:15 am Post subject: Re: Network: eudev does, udev does not |
|
|
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 |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Tue Jan 22, 2013 3:29 am Post subject: Re: Network: eudev does, udev does not |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Tue Jan 22, 2013 4:18 am Post subject: Re: Network: eudev does, udev does not |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3509
|
Posted: Wed Jan 23, 2013 1:25 pm Post subject: |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Wed Jan 23, 2013 1:48 pm Post subject: |
|
|
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 |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3509
|
Posted: Wed Jan 23, 2013 2:18 pm Post subject: |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Wed Jan 23, 2013 2:25 pm Post subject: |
|
|
As promised, news item is out and is shown to everyone with udev 197 or older. |
|
Back to top |
|
|
VoidMage Watchman
Joined: 14 Oct 2006 Posts: 6196
|
Posted: Wed Jan 23, 2013 3:53 pm Post subject: |
|
|
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 |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Jan 24, 2013 12:03 am Post subject: |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Thu Jan 24, 2013 1:44 am Post subject: |
|
|
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 |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2038 Location: United Kingdom
|
Posted: Thu Jan 24, 2013 3:37 am Post subject: |
|
|
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 systemd-utils[udev] elogind KDE on both.
My blog |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Thu Jan 24, 2013 4:39 am Post subject: |
|
|
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 |
|
|
VoidMage Watchman
Joined: 14 Oct 2006 Posts: 6196
|
Posted: Thu Jan 24, 2013 8:48 am Post subject: |
|
|
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 |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2038 Location: United Kingdom
|
Posted: Thu Jan 24, 2013 11:03 am Post subject: |
|
|
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 systemd-utils[udev] elogind KDE on both.
My blog |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2038 Location: United Kingdom
|
Posted: Thu Jan 24, 2013 3:34 pm Post subject: |
|
|
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. _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
Back to top |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Fri Jan 25, 2013 5:02 am Post subject: |
|
|
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 |
|
|
Sh4doW n00b
Joined: 13 Mar 2003 Posts: 37
|
Posted: Sat Jan 26, 2013 3:50 pm Post subject: |
|
|
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. |
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 |
|
|
cwr Veteran
Joined: 17 Dec 2005 Posts: 1969
|
Posted: Sun Jan 27, 2013 10:52 am Post subject: |
|
|
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 |
|
|
SamuliSuominen Retired Dev
Joined: 30 Sep 2005 Posts: 2133 Location: Finland
|
Posted: Sun Jan 27, 2013 11:52 am Post subject: |
|
|
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 |
|
|
|
|
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
|
|