Summary: | >=sys-fs/udev-197: Document the change in interface name swapping for pre-197 rule file 70-persistent-net.rules | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sergey Popov <pinkbyte> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, alexanderyt, axiator, bes.internal, derk.tebokkel, egorov_egor, flyser42, gentoo, heissfuss, infinity80, krinpaus, kripton, m_gentoobug, nikoli, ojaksch, rzubaly, snowy.mail, strogdon, tbzatek, web.alexander, williamh, xdudka00 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=454224 | ||
Whiteboard: | http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 411627 | ||
Attachments: |
Edit this and put it into sysinit runlevel
Loop eth1-eth9999 and be silent about it Workaround init script Workaround init script to temporarily rename to eg. eth0tmp rc.log of ethX-rename failure ethX_rename net-name-test.sh net-name-test.sh net-name-test.sh |
Description
Sergey Popov
2013-01-22 09:53:25 UTC
You should use names for interfaces which are differ from the internal kernel names (netNN, lanNN, iternetNN, etc). (In reply to comment #1) > You should use names for interfaces which are differ from the internal > kernel names (netNN, lanNN, iternetNN, etc). If it's not official upstream position(we do not support flawless upgrade), then - no i do not :-). At least - not in such important system part as udev. Also see bug 433746 SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1" try above for me i'd rename the file to something else starting with 70- ;) (In reply to comment #4) > SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", > NAME="net0" > SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", > NAME="net1" eth, not net (In reply to comment #2) > (In reply to comment #1) > > You should use names for interfaces which are differ from the internal > > kernel names (netNN, lanNN, iternetNN, etc). > > If it's not official upstream position(we do not support flawless upgrade), > then - no i do not :-). At least - not in such important system part as udev. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames "The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back." Also proof from Kay Sievers: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c3 The issue here is that the kernel never allowed you to rename a net device to the name of another existing net device, but older versions of udev did extra work to allow this. This version of udev no longer has this extra processing. (In reply to comment #8) > The issue here is that the kernel never allowed you to rename a net > device to the name of another existing net device, but older versions of > udev did extra work to allow this. This version of udev no longer has > this extra processing. Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just doesn't work for eth*? Confused. (In reply to comment #9) Yes, your example as given in comment 4 should work fine. (In reply to comment #9) > Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just > doesn't work for eth*? Confused. Yes, you are correct, but maybe I was confused as well, because comment #5 seems to be a correction saying that the person should use eth* instead of net*. (In reply to comment #11) > (In reply to comment #9) > > Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just > > doesn't work for eth*? Confused. > > Yes, you are correct, but maybe I was confused as well, because comment #5 > seems to be a correction saying that the person should use eth* instead of > net*. After renaming them to net0 and net1, shouldn't it be possible to re-rename them back to eth0 and eth1? Would it work to have... SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1" 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" Or in a different file? I think Joky (Freenode) was using a workaround like this. Use temporary names and not direct swapping... Just trying to get something together for postinst message/news item... I think I tried that, and it didn't work. Maybe udev reads the entire config and then executes the resulting rules? I'm not sure. (In reply to comment #13) > I think I tried that, and it didn't work. Maybe udev reads the entire config > and then executes the resulting rules? I'm not sure. AFAIK you are right. Temporary renaming of "ethX: to another name "renameX" was done internally by udev, not via rules. And this code was removed: http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad *** Bug 453030 has been marked as a duplicate of this bug. *** Created attachment 336566 [details]
Edit this and put it into sysinit runlevel
Here is a workaround that Christian is using. It has numbers hardcoded so editing is required.
So swapping is no longer possible and the dropping of it was intention. Okay, we have to deal with that. I looked at reverting the code but it no longer applies cleanly and I won't be doing it.
So what we could do is provide this example workaround enchanced to the users and issue a news item? Does that sound sane?
Comment on attachment 336566 [details]
Edit this and put it into sysinit runlevel
Uses sys-apps/iproute2 which unfortunately isn't part of the system (yet)
(In reply to comment #17) > Comment on attachment 336566 [details] > Edit this and put it into sysinit runlevel > > Uses sys-apps/iproute2 which unfortunately isn't part of the system (yet) hint: for i in {1..9999}; do Created attachment 336568 [details]
Loop eth1-eth9999 and be silent about it
Created attachment 336570 [details]
Workaround init script
Created attachment 336574 [details]
Workaround init script to temporarily rename to eg. eth0tmp
0..9999 and comment about iproute2
ebuild now has postinst message, that's the very least we can do (In reply to comment #22) > ebuild now has postinst message, that's the very least we can do and it's now part of the news item committed today script looks nice. does it help? I would not like to risk rebooting some remote servers without being sure I'll be able to access them... (In reply to comment #21) > Created attachment 336574 [details] > Workaround init script to temporarily rename to eg. eth0tmp > > 0..9999 and comment about iproute2 I fell over this yesterday when the HDD on my Gentoo multi WAN router crashed and I tried to rebuild it. Having read this bug I now understand the issues I had with the network card reordering. I have tried using the attached script, placing it in /etc/init.d/ethX-rename but it fails. See the attached rc.log. I feel I must be missing some other configuration setting somewhere. Help! Created attachment 336766 [details]
rc.log of ethX-rename failure
(In reply to comment #26) > Created attachment 336766 [details] > rc.log of ethX-rename failure start() in this initscript will always return false because you really don't have 9999 interfaces. This is normal. Do you really experience problems with persistent network names setup? FYI, if you have eth drivers compiled as modules, the above script won't work since it's started "before dev" and eth modules are not loaded yet. The modules service starts somewhere after udev. For this to work, you need to modify the script to include "need modules" in depend() and manually specify required modules in /etc/conf.d/modules With old 70-persistent-net.rules this works as expected with new udev. (In reply to comment #28) > FYI, if you have eth drivers compiled as modules, the above script won't > work since it's started "before dev" and eth modules are not loaded yet. The > modules service starts somewhere after udev. > > For this to work, you need to modify the script to include "need modules" in > depend() and manually specify required modules in /etc/conf.d/modules > > With old 70-persistent-net.rules this works as expected with new udev. My eth drivers are compiled as modules. I'll try the above. Thanks. Created attachment 336774 [details]
ethX_rename
Slightly modified version of the script.
(In reply to comment #30) > Created attachment 336774 [details] > ethX_rename > > Slightly modified version of the script. this was exactly my intention when dropping the script here that people would edit and improve it. thanks. (coming from bug #453030) Can confirm that swapping/renaming of my two eth's is working now again as before udev update. With the script of comment #30 the 70-net rule ist working as usual. *phew* Thanks everybody who helped on this... Also had positive results with script in comment 30. Finally have persistent names for both net cards in my server. Was touch and go for the last 2 days trying to get it to work. I guess I should have waited two more days to upgrade udev. Thanks for the script. Lifesaver, you are. :D The recent news message "Upgrading udev from 171 (or older) to 197" told me that I *need* to read this bug report (emphasis mine). I have read this bug report, but I have no idea what I am supposed to take away from this. In the news item about this issue one reads: "need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)" Does this mean that the usual /etc/fstab line: shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 should be replaced by shm /dev/shm devtmpfs nodev,nosuid,noexec 0 0 ? Or does the news comment refer to the case where one might have an fstab line that makes reference to /dev/tmpfs?... I suspect fstab is OK the way it is, but would just like to make sure before rebooting... Thanks :) (In reply to comment #35) > In the news item about this issue one reads: Use forums.gentoo.org for such questions, this is a bug about the networking change. With that said, the news item says /dev so it means /dev not /dev/shm. I don't have such /dev/shm line in my fstab at all, but yet shm is mounted automatically correctly so I'm not sure why you have it there in the first place. The thing is: This bug, which we according to the news item are supposed to read, is still completely useless to us. You do not seriously expect us to make an init script based on that ethX_rename file attached here, to keep renaming working, do you? Because that is a horrible hack. A transparent solution is required here. To me it makes no sense, that useful functionality was deliberately removed for no reason. This is not Gnome or Apple. (That race condition could have been solved inside udev.) So we’re still stuck, and this bug is not resolved. (In reply to comment #37) > The thing is: This bug, which we according to the news item are supposed to > read, is still completely useless to us. > > You do not seriously expect us to make an init script based on that > ethX_rename file attached here, to keep renaming working, do you? > Because that is a horrible hack. > > A transparent solution is required here. [...] > So we’re still stuck, and this bug is not resolved. I agree. Reading carefully this bug series, I follow what has happened but there is no good solution offered. And it takes a good while to follow what has happened. I am reminded of the recent passion from Linus about breaking user-space... ;-) My action is to hold off further upgrades until there is some dire need to spend hours hacking multiple servers with multiple network interfaces... Or until there is a transparent fix? Help? Regards, Martin (In reply to comment #38) > (In reply to comment #37) > > The thing is: This bug, which we according to the news item are supposed to > > read, is still completely useless to us. > > [...] > > I am reminded of the recent passion from Linus about breaking user-space... > ;-) > > > My action is to hold off further upgrades until there is some dire need to > spend hours hacking multiple servers with multiple network interfaces... > > Or until there is a transparent fix? FYI: After reading through: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames That is a very good idea for new installs. Unfortunately, somewhat disruptive for existing systems. Also, all this is going to take an awful lot of reading by ALL users...! My solution is the manual option of: You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules (I'll be trying the new naming scheme on a new test install.) So... How to fix this easily for existing users? Regards, Martin Well, it seems that this is (still) working after upgrade from 171-r10 -> 197-r3.. at least on my stable install. I've updated /etc/udev/rules.d/70-persistent-net.rules based on https://forums.gentoo.org/viewtopic-p-7230178.html#7230178 post, and after reboot my interface names were there, setup as defined. What I did is strip everything but SUBSYSTEM, ACTION, ATTR{address} and NAME from each entry and left 80-net-name-slot.rules in place. So, if someone else could validate this, package postinst message could be changed. I don't expect anyone to use the workaround script as a permanent solution. I'm expecting people to use the new precictable netwok scheme. The script here is only for people who had their setup at production server installed and are in need for urgent workaround before they get a better time to finish the upgrade. As in, switch to the predictable naming scheme. However patches are accepted, if you really have better idea. Otherwise you can just shup up. No offense ;-) *** Bug 450938 has been marked as a duplicate of this bug. *** Created attachment 338090 [details] net-name-test.sh from bug 455882 perhaps in view of the confusion reigning over the new net naming convention with newer udev's a name testing script should be included for the clueless? code is not original but from the forums: http://forums.gentoo.org/viewtopic-p-7240454.html#7240454 I just put it into a script for general use I found the command line from /etc/udev/rules.d/80-net-name-slot.rules udevadm test-builtin net_id /sys/class/net/ifname 2> /dev/null give no info at all .. as ifname seems not to exist .. of course my machine is on the new rules but the method should still work as a reboot may have occurred prior to the use of the line .. *** Bug 455822 has been marked as a duplicate of this bug. *** error info for https://bugs.gentoo.org/show_bug.cgi?id=453494#c43 udevadm test-builtin net_id /sys/class/net/ifname calling: test-builtin === trie on-disk === tool version: 197 file size: 5518899 bytes header size 80 bytes strings 1237475 bytes nodes 4281344 bytes load module index unable to open device '/sys/class/net/ifname' unload module index Replace "ifname" with the actual interface name. udevadm test-builtin net_id /sys/class/net/* Password: calling: test-builtin === trie on-disk === tool version: 197 file size: 5518899 bytes header size 80 bytes strings 1237475 bytes nodes 4281344 bytes load module index ID_NET_NAME_MAC=enx0023545b3d7f ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC. ID_NET_NAME_PATH=enp12s0 unload module index works better but does not grab the wireless cards as the net-name-test.sh script does. please change the documentation in fact the one liner relies on net names being alphabetical and grabs the first entry only? Is this true? (In reply to comment #47) > udevadm test-builtin net_id /sys/class/net/* Don't use wildcards; you have to run the command separately for each interface. (In reply to comment #49) > Don't use wildcards; you have to run the command separately for each > interface. for the novice .. a wild card works .. better is perhaps .. ls /sys/class/net/ to identify all available network interfaces then run the command .. udevadm test-builtin net_id /sys/class/net/{specific-name} .. if the actual names are not known .. i.e. not the old defaults eth0, eth1 etc. I just did the upgrade to udev-197-r8. I removed 70-persistent-net.rules and 80-net-name-slot.rules. Networkmanager was unable to connect to any wireless network. Feb 16 17:03:20 [NetworkManager] <info> wpa_supplicant started Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): supplicant interface state: starting -> ready Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] Feb 16 17:03:20 [NetworkManager] <warn> Trying to remove a non-existant call id. Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): supplicant interface state: ready -> inactive After deleting /etc/conf.d/net all problems were gone and it now works fine. I suggest to put the hint into the message of the udev-ebuild. (In reply to comment #51) > I just did the upgrade to udev-197-r8. I removed 70-persistent-net.rules and > 80-net-name-slot.rules. Networkmanager was unable to connect to any wireless > network. *snip* > After deleting /etc/conf.d/net all problems were gone and it now works fine. > I suggest to put the hint into the message of the udev-ebuild. Since you are using networkmanager, The only net.* service you should have in your runlevels is net.lo. You should not have to remove /etc/conf.d/net. Can you please confirm that you do not have any other net.* services in your runlevels? (In reply to comment #39) > (In reply to comment #38) > > (In reply to comment #37) > > > The thing is: This bug, which we according to the news item are supposed to > > > read, is still completely useless to us. > > > > [...] > > > > I am reminded of the recent passion from Linus about breaking user-space... > > ;-) > My solution is the manual option of: > > > You disable the assignment of fixed names, so that the unpredictable kernel > names are used again. For this, simply mask udev's rule file for the default > policy: > > ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules That looks to have been done already by the installation of the gentoo dummy file, good thanks: /etc/udev/rules.d/80-net-name-slot.rules For upgrading one of my systems, I then additionally: Deleted /etc/udev/rules.d/70-persistent-net.rules Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature (thanks for the emerge notes and checks for that). I also enabled CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary for those users using the normal Gentoo genkernel!) Added early into /etc/fstab: devtmpfs /dev devtmpfs defaults 0 0 Reboot saw the expected reshuffling of the network cards eth numbers... That was fixed by renumbering the eths in the Shorewall interfaces file and in the Gentoo net config /etc/conf.d/net to match. > So... How to fix this easily for existing users? That's one machine... Hopefully, multi-nic machines are rare? Cheers, Martin (In reply to comment #53) > For upgrading one of my systems, I then additionally: > > Deleted /etc/udev/rules.d/70-persistent-net.rules > > Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature > (thanks for the emerge notes and checks for that). I also enabled > CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary > for those users using the normal Gentoo genkernel!) > > Added early into /etc/fstab: > > devtmpfs /dev devtmpfs defaults 0 0 > > > Reboot saw the expected reshuffling of the network cards eth numbers... That > was fixed by renumbering the eths in the Shorewall interfaces file and in > the Gentoo net config /etc/conf.d/net to match. Ooooops! For anyone following that, also needed (as root): rc-update delete udev-postmount Good luck, Martin *** Bug 460614 has been marked as a duplicate of this bug. *** *** Bug 461516 has been marked as a duplicate of this bug. *** I'm having the same problem and with the drivers built into the kernel none of the above quick-arounds worked. Is there any solution? I'm voting for banning the udev developer who did make this update in this radical un-thoughtful fashion. It broke many servers and wasted many hours of many gentoo-users. The reason for this update is unknown. Let's users decide what they want. (In reply to comment #57) > I'm having the same problem and with the drivers built into the kernel none > of the above quick-arounds worked. Is there any solution? Sure, use free namespace instead of kernel reserved namespace and rename to for example, net0, net1, net2 Or remove both 70-persistent-* 80-net-name-slot.rules from /etc/udev/rules.d and run following command to get the required information BEFORE booting: # udevadm test-builtin net_id /sys/class/net/<ifname> 2> /dev/null Both are very quick ways. And this is the upstream default. Disabling this default would mean relying to the kernel named devices which can be random, that may even has security implications. The names must be predictable, and that's the beauty of it, no need for renaming them at all anymore! And rest of your message was just rude, moaning over upstream replacing one feature with better feature doesn't help In my case I had a kernel with built-in two network interface drivers. After upgrading to the new udev the server went offline. The problem was that 70-persistent-net.rules were no longer applied and eth0 became eth1 and vice versa. The routing rules in /etc/conf.d/net were applied to eth1 and the server went offline. Could you please explain how removing 70-persistent-* 80-net-name-slot.rules will help to get eth0 as eth0 back and eth1 as eth1? Would I have to re-configure ./conf.d/net? since they refer to eth0, eth1? Could you please demonstrate the beauty of the new update? I've been using eth0, eth1 configs for many many many years and I fail to see the beauty of the new udev. How can I migrate to the new UDEV leaving old ./conf.d/net? Why there is no backward compatibility? Is getting servers offline being a new idea of beauty? This is rude self-relying and mindless way of issuing an update and I don't feel rude calling it these names and I vote for a year ban of the developer of this update before he can ruin something with the new one. And I'm sure a lot of people feel the same about it. (In reply to comment #58) > (In reply to comment #57) > > I'm having the same problem and with the drivers built into the kernel none > > of the above quick-arounds worked. Is there any solution? > > Sure, use free namespace instead of kernel reserved namespace and rename to > for example, net0, net1, net2 > > Or remove both 70-persistent-* 80-net-name-slot.rules from /etc/udev/rules.d > and run following command to get the required information BEFORE booting: > > # udevadm test-builtin net_id /sys/class/net/<ifname> 2> /dev/null > > Both are very quick ways. > > And this is the upstream default. Disabling this default would mean relying > to the kernel named devices which can be random, that may even has security > implications. The names must be predictable, and that's the beauty of it, no > need for renaming them at all anymore! > > And rest of your message was just rude, moaning over upstream replacing one > feature with better feature doesn't help If anyone knows how to get my eth0 as eth0 and eth1 as eth1 back with built-in kernel network drivers instead of having eth0 as eth1 and eth1 as eth0 with the new sound and beautiful UDEV and the old /conf.d/net I would appreciate a step-by-step instructions (and I'm sure many will). What should I do to boot the the computer with the same config and experience the beauty of UDEV in it's full? for /etc/conf.d/net you need to search and replace eth0 w/ enp????? what ever the new name is .. and eth1 w/ enpxxxxx also what ever that happens to be .. will be unique to your mother board, installed cards and slots used .. use net-name-test.sh to id the cards (be sure to chmod +x net-name-test.sh ) also rename /etc/init.d/net.eth0 and net.eth1 to the same as above i.e. net.enp????? and net.enpxxxxx as per example .. then all should work .. I thought that will go that. Now I'm sure, thank you, it's now clear. How about net configs and routing information that are replicated to the servers is it no go from now? I find it at least equally simple to have a unique rule assigning eth0 and eth1 than to have unique conf.d/net configs. What is simpler to type /etc/init.d/net.eth0 restart than net.enp2s0 restart. The problem is worse. Now you never know what is your FIRST and SECOND or THIRD or FOURTH network interface. How to know? If all nics are of the same make then without the old persistent file it's hard to understand even what pathcord is connected to what interface. Now to find what is what I have lspci first then cat /proc/net/dev/ then compare DEVICE_ID And how now I should know what interface I should restart. Earlier I knew that eth0 is always the input with the first pathcord. Now how do I know what ID first pathcord is connected to? It will differ from machine to machine - it's kind of hell if you have 100 of them. I don't remember device ids, and especially I don't want them to be unique on each server. If fact I want each sever to have the same eth0 referring to the first path cord, eth1 to the second and eth3 to the spare. This update should be masked it's not ready, it's alpha or even pre-alpha. (In reply to comment #61) > for /etc/conf.d/net > > you need to search and replace eth0 w/ enp????? what ever the new name is .. > and eth1 w/ enpxxxxx also what ever that happens to be .. will be unique to > your mother board, installed cards and slots used .. use net-name-test.sh > to id the cards (be sure to chmod +x net-name-test.sh ) > > also rename /etc/init.d/net.eth0 and net.eth1 to the same as above i.e. > net.enp????? and net.enpxxxxx as per example .. then all should work .. The situation is aggravated I just noticed that iptables are all broken too :-( of course they are they refer to eth0, eth1, eth2, eht3 of which I myself lost traces of. The backward compatibility should be restored. It's no way the new UDEV will work. If anyone wants to spend months in a data-centers experiencing the beauty of the new UDEV - let him go ahead. I'm for the old nasty udev. And to think of that if anything is used successfully for many years by many people then why exterminate the code which served well. Not evolve but exterminate. This is so amateur. This update is nearly the worst what happened to us in the past 4 years. It's lucky only a few servers were updated. (In reply to comment #62) > The problem is worse. Now you never know what is your FIRST and SECOND or > THIRD or FOURTH network interface. How to know? If all nics are of the same > make then without the old persistent file it's hard to understand even what > pathcord is connected to what interface. Quite the opposite, now you don't have to rename and always know which will be what Sounds like you need to (re)read http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Did you have any real issues? Parsing your comments didn't reveal any. > Did you have any real issues? Parsing your comments didn't reveal any.
Please reread this bug thread.
The scenario for any multi-network-interface system is:
Working system;
Apply udev update;
Without adequate warning or checks, broken system;
Then add three hours to read arcane detail, trace hardware and network leads, and re-hack multiple config files that have nothing to do with udev;
Working system oncemore and a sys-op feeling like a road crash.
Thankfully, I had the sense to try the update on a non-essential system first. That painful update means that I am not updating other systems for the time being until there is a smoother non-broken upgrade path.
Consistent device names is a good idea. However, translation to a human readable non-finger-breaking easily used form is essential.
I'm observing until I'm forced to put more time into this for other systems.
Thank you for working on this and for sorting out the code this far. Sorry, but the present update is too painful for collateral damage for forcing radical changes to existing configs for some existing systems.
(And amongst others, I have two live servers that have 8 network ports each, all utilised with individual firewalling and traffic management... That will be a full overnight job each to safely update and reconfig those. :-( )
Regards,
Martin
(In reply to comment #54) > (In reply to comment #53) > > > For upgrading one of my systems, I then additionally: > > > > Deleted /etc/udev/rules.d/70-persistent-net.rules > > > > Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature > > (thanks for the emerge notes and checks for that). I also enabled > > CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary > > for those users using the normal Gentoo genkernel!) > > > > Added early into /etc/fstab: > > > > devtmpfs /dev devtmpfs defaults 0 0 > > > > > > Reboot saw the expected reshuffling of the network cards eth numbers... That > > was fixed by renumbering the eths in the Shorewall interfaces file and in > > the Gentoo net config /etc/conf.d/net to match. > > Ooooops! For anyone following that, also needed (as root): > > rc-update delete udev-postmount Ooops... There's been other bits needing tweaking. An important one if you are using tc traffic management is to also re-hack the Shorewall tcstart file for whatever new interface names. Also do a egrep -R 'eth[0-9]' /etc to pick up any others. For my 'simple' test server example, after the fixes that gives: /etc/asterisk/phoneprov.conf /etc/dhcp/dhcpd.conf /etc/shorewall.ml02.modem/tcstart.mp01 /etc/shorewall.ml02.modem/tcstart /etc/shorewall.ml02.modem/params /etc/yp.conf /etc/shorewall.ml01/tcstart.mp01 /etc/shorewall.ml01/tcstart /etc/shorewall.ml01/params.ml01 /etc/shorewall.ml01/params /etc/udev/rules.d/80-net-name-slot.rules /etc/asterisk.ml02/phoneprov.conf /etc/rc.conf /etc/asterisk.ml01/phoneprov.conf /etc/shorewall/tcstart.mp01 /etc/shorewall/tcstart /etc/shorewall/params.ml01 /etc/shorewall/params /etc/conf.d/net /etc/conf.d/network /etc/conf.d/netmount (And for example, people are very touchy about losing asterisk even for a minute... :-( ) Good luck, Martin Sorry, I've not checked what whatever present warning messages are given before an update, but can this scenario be put in place as a fix: Give a "dumb-speak" warning saying that the network interface names will be changed and this may break other system settings. Then give your more long detailed explanation and web links. The new system suggests that we cannot do renaming to old interface names. Hence instead, can an automated check be made to find and *suggest* fixes to all affected config files? I'll leave others to discuss whether we keep with the new static interface naming or offer an aliasing scheme whereby the static names can be also be referred to as for example enet0, enet1... (I'm leery of using "net0", "net1" etc because that naming commonly gets used elsewhere.) Thanks, Martin (In reply to comment #67) > Sorry, I've not checked what whatever present warning messages are given > before an update, but can this scenario be put in place as a fix: > > Give a "dumb-speak" warning saying that the network interface names will be > changed and this may break other system settings. Then give your more long > detailed explanation and web links. Can you please be more specific? Can you check the warnings and let us know what else you think we should add? > The new system suggests that we cannot do renaming to old interface names. > Hence instead, can an automated check be made to find and *suggest* fixes to > all affected config files? The problem here is that there is no simple way for us to cover *all* possible cases that I'm aware of. > I'll leave others to discuss whether we keep with the new static interface > naming or offer an aliasing scheme whereby the static names can be also be > referred to as for example enet0, enet1... (I'm leery of using "net0", > "net1" etc because that naming commonly gets used elsewhere.) Unfortunately, the kernel doesn't and never has allowed a network interface to have more than one name, so there isn't a way to do an aliasing scheme. Udev doesn't actually force you into this network naming scheme. All it does is set up a default naming policy and the documentation tells you how to change that. The choices you have are covered in the "I don't like this, how do I disable this?" section of the wiki page referred to in comment #6. The choice we made in udev 197 was affectively a version of option 1, but in 198 or newer, we are leaving it up to you. The "why" section of the same wiki page explains the problems with users trying to rename interfaces within the old names, such as renaming eth1 to eth0. They explain why allowing this was dropped from udev (the kernel never allowed it, but udev had some extra code that made it happen). Does that clarify things more? William williamh:
Clarification question, from the freedesktop page:
> This combined policy is only applied as last resort. That means, if the system
> has biosdevname installed, it will take precedence. If the user has added udev
> rules which change the name of the kernel devices these will take precedence
> too. Also, any distribution specific naming schemes generally take precedence.
With all rule files removed from /etc/, and the /lib ones stock, however, biosdevname does NOT get used.
I should have named my interfaces {em1,em2,p0p0,p0p1}.
Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test).
(In reply to comment #69) > williamh: > Clarification question, from the freedesktop page: > > This combined policy is only applied as last resort. That means, if the system > > has biosdevname installed, it will take precedence. If the user has added udev > > rules which change the name of the kernel devices these will take precedence > > too. Also, any distribution specific naming schemes generally take precedence. > With all rule files removed from /etc/, and the /lib ones stock, however, > biosdevname does NOT get used. > I should have named my interfaces {em1,em2,p0p0,p0p1}. > Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test). Right, that's why postinst message of udev says biosdevname is deprecated in favour of the predictable network names (In reply to comment #70) > (In reply to comment #69) > > williamh: > > Clarification question, from the freedesktop page: > > > This combined policy is only applied as last resort. That means, if the system > > > has biosdevname installed, it will take precedence. If the user has added udev > > > rules which change the name of the kernel devices these will take precedence > > > too. Also, any distribution specific naming schemes generally take precedence. > > With all rule files removed from /etc/, and the /lib ones stock, however, > > biosdevname does NOT get used. > > I should have named my interfaces {em1,em2,p0p0,p0p1}. > > Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test). @ssuominen: I just walked through this with @robbat2, and if biosdevname is installed, udev does use the biosdevname rules since they are installed as /lib/udev/71-biosdevname.rules. You see this by looking at both stderr and stdout from: udevadm test /sys/class/net/<ifname> > Right, that's why postinst message of udev says biosdevname is deprecated in > favour of the predictable network names I think this should be removed since udev doesn't stop you from using biosdevname. Created attachment 342056 [details]
net-name-test.sh
Here is an updated net-name-test.sh.
This one actually shows you the name your interface will get and the
location of the rule that name comes from.
Created attachment 342068 [details]
net-name-test.sh
All, this is the version of net-name-test.sh you should use.
Be aware that it does not give accurate information if you have
biosdevname or anything else that uses RUN or PROGRAM options in the
udev rules to get the name of the network interfaces.
Thanks to @robbat2 for testing.
(In reply to comment #71) > > Right, that's why postinst message of udev says biosdevname is deprecated in > > favour of the predictable network names > I think this should be removed since udev doesn't stop you from using > biosdevname. It's a warning instead of hard blocker based on your logic already. There is no need to keep continuing to use biosdevname, and I'm considering moving it as a blocker in later udev ebuilds The migration plan in Fedora includes replacing biosdevname with plain udev, too http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames Scope: "As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations." (In reply to comment #74) > (In reply to comment #71) > > > Right, that's why postinst message of udev says biosdevname is deprecated in > > > favour of the predictable network names > > I think this should be removed since udev doesn't stop you from using > > biosdevname. > > It's a warning instead of hard blocker based on your logic already. There is > no need to keep continuing to use biosdevname, and I'm considering moving it > as a blocker in later udev ebuilds > The migration plan in Fedora includes replacing biosdevname with plain udev, > too Fedora isn't planning on forcing it to be removed from people's systems, just preventing new installations. If we make it a blocker that means it will be automatically removed from people's systems, so I disagree with that. If we are going to deprecate biosdevname, I would rather just go through the lastrights procedure for it. The solutions are all good but in real life renaming interfaces is the last thing you want with remote a server. Even if you know what names interfaces will receive with a complex config the chances are that you won't boot or you may boot but parts of the system will not work. One may continue fixing the system for months after the update. It's far more reliable to restore the old udev behavior. Add a new configure option and let users think for themselves if they need the new behavior or not. Gentoo could use a new use flag. By default the udev will behave as the old one and the flag should be ON by default and if somebody meets with the imaginable problems mentioned in udev annotation he can turn this flag off and get a new udev sound and running in just what - a few months may be. This all story with udev is mimicking Windows 8 "successful" start. Ballmer was born when the coolest thing ever was the touch-screen. It was only in the SF movies like the Flight of the Navigator which he watched over and over again. And when he grew he got his chance to prove to the world that a touch interface is superior to the keyboard and everyone else with the keyboard are just old-fashioned pranks. Sometimes keyboard jams he says and ah... a few extra letters are printed he says, and then yes, you can spill tea on the keyboard, and in 10 000 years these extra letters will burn the LCD - let's fix these great problems because we have nothing else important to do with our lives but fixing things which are proved by time. Let's remove keyboard entirely that is what he says. And the solution of this problem will be exactly the same as with windows 8. The udev should be rolled back and the users should decide what's best for them - a chance of their server being killed by a meteorite or an inevitable death by installing udev. (In reply to comment #77) No ranting in bugzilla please. This is not a discussion forum. *** Bug 462082 has been marked as a duplicate of this bug. *** (In reply to comment #30) Thanks for the renaming script. However, in my case, it does not work every single time. Unfortunately, I am not able to reproduce the failure. What I have noticed, however, is that if my local server was off for several hours, the renaming fails; when I do a reboot, it is working again. For my remote servers, this behavior could be really painful... I agree to the upper part of comment #77, why not have a configuration option for the old behavior? (In reply to comment #80) > I agree to the upper part of comment #77, why not have a configuration > option for the old behavior? As we said before: because it's not possible due to upstream decision (In reply to comment #80) > (In reply to comment #30) > > Thanks for the renaming script. > > However, in my case, it does not work every single time. Unfortunately, I am > not able to reproduce the failure. What I have noticed, however, is that if > my local server was off for several hours, the renaming fails; when I do a > reboot, it is working again. > > For my remote servers, this behavior could be really painful... > > I agree to the upper part of comment #77, why not have a configuration > option for the old behavior? Rename to free namespace like net0, net1, internet0, internet1, foobar0, foobar1, ... Or switch to the new predictable names which are now enabled by default for 198, soon-to-be 199, and live-ebuild 9999, then you don't need to rename at all since the names are predictable! This is by design. (In reply to comment #81) > (In reply to comment #80) > > I agree to the upper part of comment #77, why not have a configuration > > option for the old behavior? > > As we said before: because it's not possible due to upstream decision Correct. (In reply to comment #82) I wouldn't mind new names for the devices, if this would not mean rewriting a bunch of configuration files, iptables skripts and so on on several servers. Furthermore, for remote servers this transition is far too risky in my eyes, possibly resulting in a non-responding server. This is a risk I am not willing to take. (In reply to comment #53) > (In reply to comment #39) [...] > Reboot saw the expected reshuffling of the network cards eth numbers... That > was fixed by renumbering the eths in the Shorewall interfaces file and in > the Gentoo net config /etc/conf.d/net to match. > > > > So... How to fix this easily for existing users? > > That's one machine... Hopefully, multi-nic machines are rare? Well... That was a rhetorical question: I've got 6 more multi-nic servers to work through which is going to be very badly time consuming to fix a lot connected configs... And it all has to just simply work "first time". Hence: Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the respective new "persistent-net-names" workable? Or would such /dev symlinks need to be replicated also in various other /dev /proc /sys trees? Regards, Martin (In reply to comment #84) > Hence: > > Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the > respective new "persistent-net-names" workable? > > Or would such /dev symlinks need to be replicated also in various other /dev > /proc /sys trees? "/dev/sdXN" should of course read "/dev/ethX" for this case...! Regards, Martin (In reply to comment #85) > (In reply to comment #84) > > > Hence: > > > > Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the > > respective new "persistent-net-names" workable? > > > > Or would such /dev symlinks need to be replicated also in various other /dev > > /proc /sys trees? > > > "/dev/sdXN" should of course read "/dev/ethX" for this case...! > > Regards, > Martin There has never been /dev nodes for network interfaces. Or do you remember seeing things like /dev/eth0? Then that must have been some other UNIX like AIX, but not Linux -- although I have to admit I don't remember things from old kernels like Linux 2.0 or 2.2 from back in 90s, so please google for more accurate information. And you can find out what the names will be using the script from Comment #73, but you would have find that out by reading this bug... Same information is in the "dummy" file /etc/udev/rules.d/80-net-name-slot.rules if it's still in place, and same information is in postinst message of >=sys-fs/udev-198 since we no longer install /etc/udev/rules.d/80-net-name-slot.rules Basically you are asking the already asked questions again, and I'm answering to them again, they are all over this bug, the ebuild, the example file, the forums, referenced from the news item, etc etc (I had no problems booting the 12 servers at work straight to the new names) (In reply to comment #86) > (In reply to comment #85) > > (In reply to comment #84) > > > > > Hence: > > > > > > Is a naive 'dumb fix' of setting symlinks in /dev ... "/dev/ethX" > > There has never been /dev nodes for network interfaces. Or do you remember > seeing things like /dev/eth0? Then that must have been some other UNIX like Indeed so. For my case I was thinking of the /dev/net/tunXX on the system, but that's not for real physical hardware... > And you can find out what the names will be using the script from Comment > #73, but > you would have find that out by reading this bug... > Same information is in the "dummy" file > /etc/udev/rules.d/80-net-name-slot.rules if it's still in place, and same > information is in postinst message of >=sys-fs/udev-198 since we no longer > install /etc/udev/rules.d/80-net-name-slot.rules ...And also needed with that is a right-first-time strategy to avoid service interruption for heavily used multi-service systems with eight ports each (eth0 - eth7 with eth:xxx 'aliases'). I'm hoping not to lose too much of the Easter break untangling that... > Basically you are asking the already asked questions again, and I'm > answering to them again, they are all over this bug, the ebuild, the example > file, the forums, referenced from the news item, etc etc > > (I had no problems booting the 12 servers at work straight to the new names) And you've already answered that all the other non-udev configs affected (broken) cannot be allowed for by this change. Good for your case and easy enough for single nic servers. However, go multi-nic and multi services referencing those nics and... This remains quite a headache. Unfortunately, still difficult from all sides for existing multi-nic systems. (In reply to comment #87) > multi-nic and multi services referencing those nics and... This remains Unless anyone has any better ideas: egrep -R 'eth[0-9]' /etc Work through the list with sed ... Wait until midnight (when hopefully noone is looking) and reboot... Regards, Martin *** Bug 463296 has been marked as a duplicate of this bug. *** There are 2 internal network interfaces on my motherboard (this is a Supermicro server board). Initialy they was named enp1s0 and enp2s0. 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection Then I install a video card, and interfaces got renamed to enp2s0 and enp3s0: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape Verde PRO [Radeon HD 7750] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection So predictable network names are not really predictable? :) Qote from the URL: "With this new scheme you now get: ... - Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place ..." (In reply to comment #90) > So predictable network names are not really predictable? :) Qote from the > URL: > > "With this new scheme you now get: > ... > - Stable interface names even when hardware is added or removed, i.e. no > re-enumeration takes place > ..." BTW, I've same issue when I decide to enable more USB3.0 ports in BIOS (which was disabled because I've no USB3.0 devices and I try to avoid enabling hardware and software features which I don't need now). (In reply to comment #90) [ ... ] Then use consistent names by renaming into eg. net0, net1, net2 based on MACs or use Option 4) directly from upstream wiki page that creates MAC based iface names Multiple options to get sane setup, just pick one :-) We take option 1) renaming interfaces based on MAC to non-kernel namespace interface names. Where belongs these rules now, ideally? In the old and "semi wrong" 70-persistent-net.rules? In 80-net-name-slot.rules? Or in a custom rule file before or after 80-net-name-slot.rules? On a new installed system, we will have a non-emtpy 80-net-name-slot.rules file, right? So our renaming to non-kernel namespace rule should belongs after 80-net-name-slot.rules file? (In reply to comment #93) > We take option 1) > renaming interfaces based on MAC to non-kernel namespace interface names. > > Where belongs these rules now, ideally? > In the old and "semi wrong" 70-persistent-net.rules? > In 80-net-name-slot.rules? > Or in a custom rule file before or after 80-net-name-slot.rules? > > On a new installed system, we will have a non-emtpy 80-net-name-slot.rules > file, right? > So our renaming to non-kernel namespace rule should belongs after > 80-net-name-slot.rules file? You should only have _1_ file called, for example, 70-my-network.rules in /etc/udev/rules.d with content like: SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1" Adjust the MACs to match yours. Delete any 70-persistent-*.rules and 80-net-*.rules from /etc/udev/rules.d so they don't interfere with this 70-my-network.rules you are creating. Is it still a) possible b) recommended to use the rename rc-script attached to this bug alongside a valid 70-persistent-net.rules and 80-net-name-slot.rules if we want to keep "eth0" style naming? I was holding off moving to a "MAC based re-name to net0" until I'm sure that it won't break anything that expects "eth0". Thanks. (In reply to comment #95) > Is it still a) possible b) recommended to use the rename rc-script attached > to this bug alongside a valid 70-persistent-net.rules and > 80-net-name-slot.rules if we want to keep "eth0" style naming? > > I was holding off moving to a "MAC based re-name to net0" until I'm sure > that it won't break anything that expects "eth0". > > Thanks. Sorry I meant is it still relevant to udev 200 as I sucessfully set up the rename rc-script and rules files for udev 197 and don't know if it is still the recommended practice. (In reply to comment #95) > Is it still a) possible b) recommended to use the rename rc-script attached > to this bug alongside a valid 70-persistent-net.rules and > 80-net-name-slot.rules if we want to keep "eth0" style naming? > > I was holding off moving to a "MAC based re-name to net0" until I'm sure > that it won't break anything that expects "eth0". > > Thanks. Nothing should have changed in-between, but using the rc-script here was definetely never recommended, otherwise it would be in portage by now Just use different namespace, like net* lan* internet* or you can even use names like etha, ethb, ethc, since kernel shouldn't reserve by letter I believe (In reply to comment #97) > (In reply to comment #95) > > Is it still a) possible b) recommended to use the rename rc-script attached > > to this bug alongside a valid 70-persistent-net.rules and > > 80-net-name-slot.rules if we want to keep "eth0" style naming? > > > > I was holding off moving to a "MAC based re-name to net0" until I'm sure > > that it won't break anything that expects "eth0". > > > > Thanks. > > Nothing should have changed in-between, but using the rc-script here was > definetely never recommended, otherwise it would be in portage by now > Just use different namespace, like net* lan* internet* or you can even use > names like etha, ethb, ethc, since kernel shouldn't reserve by letter I > believe Just a check before losing any remote systems: Can /etc/udev/rules.d/70-persistent-net.rules be used with interface names such as: eth_0, eth_1, eth_2, etc... or would those get tripped up anywhere? Thanks, Martin (In reply to comment #98) > (In reply to comment #97) > > (In reply to comment #95) > > > Is it still a) possible b) recommended to use the rename rc-script attached > > > to this bug alongside a valid 70-persistent-net.rules and > > > 80-net-name-slot.rules if we want to keep "eth0" style naming? > > > > > > I was holding off moving to a "MAC based re-name to net0" until I'm sure > > > that it won't break anything that expects "eth0". > > > > > > Thanks. > > > > Nothing should have changed in-between, but using the rc-script here was > > definetely never recommended, otherwise it would be in portage by now > > Just use different namespace, like net* lan* internet* or you can even use > > names like etha, ethb, ethc, since kernel shouldn't reserve by letter I > > believe > > Just a check before losing any remote systems: > > Can /etc/udev/rules.d/70-persistent-net.rules be used with interface names > such as: > > eth_0, eth_1, eth_2, etc... > > or would those get tripped up anywhere? > > Thanks, > Martin Don't use _ or other chars like -+, even if most of base system would somehow boot up with it, almost certainly something will fail! Just alphabets and numbers far as I can remember. Plus, everyone, let's use http://forums.gentoo.org/ for thesetype of issues, please! Otherwise unrelated people will only get bugspam they don't need. |