Description of problem: * Fri Aug 10 2007 Harald Hoyer <harald> - 114-1 - version 114 - big rule unification and cleanup - added persistent names for network and cdrom devices over reboot However, we still have: - 60-net.rules, which - renames devices based on HWADDR/SUBCHANNEL in ifcfg-XXX files - queues ifup based on those names - anaconda writing ifcfgs with HWADDR for that rules file - kudzu writing ifcfgs with HWADDR for that rules file We need to clean this up before release, as having 60-net.rules and 70-persistent-net.rules disagreeing on the device name is going to cause problems somewhere. Initial suggestion: - remove /lib/udev/rename_device - have a quick script that runs on upgrade that writes a persistent net rules file based on the current ifcfg-* - nuke the kudzu device writing - have anaconda write persistent rules as well Questions: - how does this integrate with bios_dev_name, if at all? - does the persistent net generator in udev use subchannels as the primary key instead of address on s390? (grrr)
re: integration with biosdevname. I expect the following order is what's wanted. persistent-net.rules biosdevname.rules someothernaming.rules In this way, assigned persistent names are used if present, falling back to invoking biosdevname for an answer, and falling back yet again to whatever final rules may exist.
Yes, but udev will write new persistent-net rules once it's done booting. As long as that's done after biosdevname has picked out a name, it would theoretically work, except the rule generator wouldn't run (in most cases) because the device name wouldn't match its whitelist.
What about: 70-persistent-net.rules 71-biosdevname.rules 72-net.rules 75-persistent-net-generator.rules This should work...
Well, if -net.rules does nothing more than queue an ifup, its ordering is irrelevant. The issue is going to move from the HWADDR as primary key in the ifcfg- file - do we keep the rename_device rule around for if the user changes it?
Yes, I think ifcfg- should overrule everything, so rename_device should run after persistent. Maybe 70-persistent-net.rules should run _after_ biosdevname.rules, so that the user can "config" that by hand. Also 70-persistent-net.rules is should be have taken initial names from biosdevname.rules and net.rules, because 75-persistent-net-generator.rules runs after them. So: 60-biosdevname.rules 70-persistent-net.rules 72-net.rules 75-persistent-net-generator.rules
70-persistent-net.rules will do configured device renaming. 75-persistent-net-generator will write out rules, if a device is unconfigured. I think all other optional device naming stuff should go in-between the both and _only_ provide a hint to 75-persistent-net-generator which name to use for this device. All stuff in-between must check for NAME=="?*" (already handled), and skip any action if set. That way, biosdevname would run only _once_ at interface discovery, and the given name would end as a config in 70-persistent-net.rules. It looks like a waste of resources, to call biosdevname at every bootup, while it will always return the same name anyway. With integrating in the generator, it would just create an entry in the usual database file, and users can go and edit that name without any knowledge about biosdevname. The name would just be a custom name, not an enumerated one.
Kay, I'll put at 71-biosdevname.rules then: KERNEL!="eth*", GOTO="biosdevname_end" ACTION!="add", GOTO="biosdevname_end" NAME=="?*", GOTO="biosdevname_end" PROGRAM="/sbin/biosdevname --policy=embedded_ethN_slots_names -i %k", NAME="%c" LABEL="biosdevname_end"
But that will still not make 75-persistent-net-generator write out your interface name to 70-persistent-net.rules, which is what I would like to have. So the next bootup, NAME will be already set and you are never called again on the same system. Something like setting ENV{INTERFACE_NEW}="%c", and make /lib/udev/write_net_rules to use that name, if INTERFACE_NEW is already suggested by something else, would do that magic, I guess.
sry for the confusion, but first NAME= takes it all... NAME The name of the node to be created, or the name the network interface should be renamed to. Only one rule can set the node name, all later rules with a NAME key will be ignored.
Hrm, this is going to require more jiggering of what we currently do. Where in the ordering are the temporary rules in /dev/.udev used?
The files in /dev/.udev/rules.d/ are sorted with the other rules files, just like they would all live in one single directory.
So, I'm not seeing the 'NAME' stuff working here in brief testing. I have a rule that runs at 72 that sets NAME (via IMPORT), and udev is happily running the persistent net generator and renaming anyway. (Needless to say, this breaks horribly.)
What does "set NAME via IMPORT" mean? How does the rule look like?
ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="/lib/udev/rename_device" where the program prints out: NAME=<whatever> INTERFACE=<whatever> DEVPATH=<whatever> In any case, I'm not sure the suggested workflow of: ... Yes, I think ifcfg- should overrule everything, so rename_device should run after persistent. ... can work right, period. Example: You have a network card A that normally is eth0; you have an ifcfg file that defines this. You add a network card B. It happens to load/initialize first via udev. udev will generate a persistent name, possibly eth0. (After all, if the prior ifcfg is setting the device name, it will (theoretically) set NAME, so the persistent generator will never run for such devices.) Then, you load the driver for A. It initializes, and goes into the renamer that reads the ifcfg file. This renames B to a temporary device, and renames A to eth0. So, problems: - B never gets renamed to something sane - the udev init script promptly writes a persistent rule for B that has 'eth0' as the device
Oh, NAME is not an environment variable, like DEVPATH or INTERFACE, udev will not do anything with it. You'll need to set the NAME= rule key.
Does NAME=%E{INTERFACE} DTRT, if interface is set via IMPORT?
NAME="$env{INTERFACE}" might work.
Will do some more testing, but I still think we need to do some more work here. Right now, we have a supposed priority of using: 1) the name in ifcfg-<whatever> for the given HWADDR 2) the name in persistent-device-names for the given HWADDR 3) the name suggested by biosdevname 4) the name assigned by the persistent-device-names generator In order for this to work reliably when a new device is added: - #2 can't use any names defined in #1 - #3 can't use any names defined in #1 or #2 - #4 can't use any names defined in #1, #2, or #3 That's not the case right now.
OK, some more testing yields that to do this right, we need the following things done. 1) /lib/udev/rename_device (Fedora/RH specific) needs to simply suggest device names with INTERFACE_NAME, not do any actual renaming (and the Fedora rules in initscripts need adjusted appropriately.) I have a patch for this. 2) anaconda needs to write out persistent device names for what it loads. No patch for this yet. 3) biosdevname needs the following added to its rules, so that it doesn't do anything if something else has already suggested a name: ENV{INTERFACE_NAME}=="?*", GOTO="biosdevname_end" 4) biosdevname needs some behavior changes. It never reads the current persistent device settings, or even the currently existing devices. This means that it is very likely that it will suggest a device name already in use, if it returns a name in the ethX space. (Using all_ethN as the policy makes this very likely to happen.) When it's using something like eth_sX_Y, it's less likely there will be a collision, as that's its 'own' namespace, so to speak. 5) What happens when new devices are added will probably need some documentation. If you don't have biosdevname installed, every new device added will just get a new ethX number, monotonically increasing. If you *do* have biosdevname installed, what happens depends on the policy - right now with all_ethN it doesn't work. What we do with ifcfg-XXXX files on device add depends on this.
Created attachment 224801 [details] anaconda patch to write persistent net rules Here's the anaconda patch to write persistent net rules.
anaconda bits are committed. Bill -- what else needs doing here?
Well, if biosdevname isn't installed, it should all work OK. If it is installed, strange things may happen.
Bill, what does biosdevname need to do to prevent "strange things"?
See comment #19. Since biosdevname doesn't check what it's going to offer against: 1) currently allocated persistent device names (in 70-persistent-net.rules) 2) currently in-use by other devices device name (eth0, eth1, whatever) it's highly likely that it will cause conflicts on device add. That's what I'd like fixed. If it uses a different policy by default (eth_sX_Y, for example) this shouldn't be an issue.
So can this be closed or what? (or moved off the F8Blocker list)?
Hrm, maybe moved to Target at this point?
With madwifi driver on F8, I see "ath0_rename" as the device name. What causes this and how do I fix it?
Ooh, the first one. Please attach /etc/sysconfig/network-scripts/ifcfg-*, and /etc/udev/rules.d/70-persistent-net.rules.
Does the madwifi driver create two interfaces with the same MAC address, like the iwl* driver? If that's the case, you may need to add ATTR{type}=="1" to the rule in /etc/udev/rules.d/70-persistent-net.rules, like the current version of the rule writer is doing it by default.
Created attachment 240651 [details] ifcfg-eth0
Created attachment 240661 [details] ifcfg-lo
Created attachment 240671 [details] ifcfg-wifi0 (atheros card)
Created attachment 240681 [details] 70-persistent-net.rules
Created attachment 240691 [details] ifconfig output showing multiple wireless devices Yes, madwifi creates multiple wireless interfaces, wifi0 and ath0. See attachment for ifconfig output.
Oh, that's *cute*. I'm assuming you didn't create ifcfg-wifi0. What happens if you remove the persistent net rule for wifi0 and that file?
I removed ifcfg-ath* and ifcfg-wifi* and the persistent net rule for wifi0. After rebooting, I now have only this file: ifcfg-ath0: # Atheros Communications, Inc. AR5212 802.11abg NIC DEVICE=ath0 ONBOOT=yes BOOTPROTO=dhcp HWADDR=00:05:4e:47:de:c4 and the device is named properly (ath0). This is using madwifi ath-pci driver.
Ugh, ok. So, at some point, kudzu decided to write an ifcfg file for the device, and it decided (for reasons unknown) to pick wifi0. I'm not seeing how it would do this off the top of my head, and unfortunately I don't have hardware to test this with.
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I believe this is currently handled OK in Fedora 10. At least until we try and use biosdevname.