Bug 264901 - oops, we have multiple sources of persistent network names active at the same time
oops, we have multiple sources of persistent network names active at the same...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
8
All All
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
bzcl34nup
:
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-08-29 16:02 EDT by Bill Nottingham
Modified: 2014-03-16 23:08 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 12:43:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda patch to write persistent net rules (2.11 KB, patch)
2007-10-11 17:14 EDT, Bill Nottingham
no flags Details | Diff
ifcfg-eth0 (184 bytes, text/plain)
2007-10-27 15:36 EDT, Charles R. Anderson
no flags Details
ifcfg-lo (254 bytes, text/plain)
2007-10-27 15:37 EDT, Charles R. Anderson
no flags Details
ifcfg-wifi0 (atheros card) (129 bytes, text/plain)
2007-10-27 15:37 EDT, Charles R. Anderson
no flags Details
70-persistent-net.rules (346 bytes, text/plain)
2007-10-27 15:40 EDT, Charles R. Anderson
no flags Details
ifconfig output showing multiple wireless devices (1.96 KB, text/plain)
2007-10-27 15:41 EDT, Charles R. Anderson
no flags Details

  None (edit)
Description Bill Nottingham 2007-08-29 16:02:37 EDT
Description of problem:

* Fri Aug 10 2007 Harald Hoyer <harald@redhat.com> - 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)
Comment 1 Matt Domsch 2007-08-29 16:24:30 EDT
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.
Comment 2 Bill Nottingham 2007-08-29 23:04:22 EDT
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.
Comment 3 Harald Hoyer 2007-08-30 04:04:00 EDT
What about:
70-persistent-net.rules
71-biosdevname.rules
72-net.rules
75-persistent-net-generator.rules

This should work... 
Comment 4 Bill Nottingham 2007-08-30 13:59:28 EDT
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? 
Comment 5 Harald Hoyer 2007-08-31 07:51:51 EDT
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
Comment 6 Kay Sievers 2007-08-31 11:09:46 EDT
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.
Comment 7 Matt Domsch 2007-08-31 12:28:09 EDT
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"

Comment 8 Kay Sievers 2007-08-31 12:53:55 EDT
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.
Comment 9 Harald Hoyer 2007-09-11 08:11:26 EDT
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.
Comment 10 Bill Nottingham 2007-09-19 17:08:48 EDT
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?
Comment 11 Kay Sievers 2007-09-19 17:16:25 EDT
The files in /dev/.udev/rules.d/ are sorted with the other rules files, just
like they would all live in one single directory.
Comment 12 Bill Nottingham 2007-09-19 17:19:50 EDT
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.)
Comment 13 Kay Sievers 2007-09-19 17:24:32 EDT
What does "set NAME via IMPORT" mean? How does the rule look like?
Comment 14 Bill Nottingham 2007-09-19 17:29:07 EDT
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

Comment 15 Kay Sievers 2007-09-19 17:35:55 EDT
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.
Comment 16 Bill Nottingham 2007-09-19 17:53:24 EDT
Does NAME=%E{INTERFACE} DTRT, if interface is set via IMPORT?
Comment 17 Kay Sievers 2007-09-19 18:04:20 EDT
NAME="$env{INTERFACE}" might work.
Comment 18 Bill Nottingham 2007-09-28 12:40:14 EDT
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.
Comment 19 Bill Nottingham 2007-10-04 16:01:16 EDT
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.
Comment 20 Bill Nottingham 2007-10-11 17:14:19 EDT
Created attachment 224801 [details]
anaconda patch to write persistent net rules

Here's the anaconda patch to write persistent net rules.
Comment 21 Jeremy Katz 2007-10-22 21:40:34 EDT
anaconda bits are committed.  Bill -- what else needs doing here?
Comment 22 Bill Nottingham 2007-10-23 13:13:34 EDT
Well, if biosdevname isn't installed, it should all work OK. If it is installed,
strange things may happen.
Comment 23 Matt Domsch 2007-10-23 17:09:40 EDT
Bill, what does biosdevname need to do to prevent "strange things"?
Comment 24 Bill Nottingham 2007-10-23 18:17:25 EDT
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.
Comment 25 Jesse Keating 2007-10-25 08:55:43 EDT
So can this be closed or what?  (or moved off the F8Blocker list)?
Comment 26 Bill Nottingham 2007-10-25 10:53:49 EDT
Hrm, maybe moved to Target at this point?
Comment 27 Charles R. Anderson 2007-10-26 20:02:07 EDT
With madwifi driver on F8, I see "ath0_rename" as the device name.  What causes
this and how do I fix it?
Comment 28 Bill Nottingham 2007-10-26 23:46:55 EDT
Ooh, the first one. Please attach /etc/sysconfig/network-scripts/ifcfg-*, and
/etc/udev/rules.d/70-persistent-net.rules.
Comment 29 Kay Sievers 2007-10-27 02:09:35 EDT
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.
Comment 30 Charles R. Anderson 2007-10-27 15:36:30 EDT
Created attachment 240651 [details]
ifcfg-eth0
Comment 31 Charles R. Anderson 2007-10-27 15:37:03 EDT
Created attachment 240661 [details]
ifcfg-lo
Comment 32 Charles R. Anderson 2007-10-27 15:37:58 EDT
Created attachment 240671 [details]
ifcfg-wifi0 (atheros card)
Comment 33 Charles R. Anderson 2007-10-27 15:40:14 EDT
Created attachment 240681 [details]
70-persistent-net.rules
Comment 34 Charles R. Anderson 2007-10-27 15:41:33 EDT
Created attachment 240691 [details]
ifconfig output showing multiple wireless devices

Yes, madwifi creates multiple wireless interfaces, wifi0 and ath0.  See
attachment for ifconfig output.
Comment 35 Bill Nottingham 2007-10-29 12:00:47 EDT
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?
Comment 36 Charles R. Anderson 2007-10-29 15:36:43 EDT
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.

Comment 37 Bill Nottingham 2007-10-29 16:17:10 EDT
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.
Comment 38 Bug Zapper 2008-04-04 09:43:16 EDT
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.
Comment 39 Bug Zapper 2008-11-26 02:43:50 EST
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
Comment 40 Bill Nottingham 2008-11-26 12:43:10 EST
I believe this is currently handled OK in Fedora 10. At least until we try and use biosdevname.

Note You need to log in before you can comment on or make changes to this bug.