Bug 965718

I could have sworn that I've mentioned this before, but...

The problem that still needs to be solved is the intersection of biosdevname & systemd naming. The feature itself claims that it wants to allow biosdevname to be used if it's installed, but that cannot work right now.

Right now, the naming policy is essentially set *at installation*.
biosdevname is on the anaconda dracut initramfs (it's pulled in explicitly in the lorax template for anaconda). It names the interfaces on boot (systemd will if biosdevname=0 is passed).

Then, anaconda *writes these interface names* to the network configuration, essentially making the naming permanent. At this point, neither removal of biosdevname (if you want systemd naming), or adding biosdevname to a system installed without it (in case you want biosdevname naming) actually changes the naming in use in the system. To switch, you need to rewrite the config, and no one wants that.

So, yes, we can drop biosdevname from core. However:
1) because biosdevname remains on the anaconda initramfs, it will still record the biosdevname interface names on the installed system
2) if we fixed that, we'll still have the problem where biosdevname naming can't be enabled post-boot without rewriting all the configuration on the system.

(This is why I really really preferred that the naming schemes be compatible so that customers/users who need biosdevname names could use systemd - that would avoid this mess.)

In any case, one potential solution would be:
1) modifying the biosdevname rules *when used in anaconda* to only take effect if biosdevname=1 is passed on the commandline.
2) modifying anaconda such that if biosdevname=1 is passed, then biosdevname is added to the installation package set
3) then removing biosdevname from @core in comps

That at least gives a semi-coherent way to have the default install not use biosdevname names, while still allowing someone to install with biosdevname names and have that carry through to the installed system.

I think Bill has outlined a reasonable solution here.  There's really minimal code required of anaconda - #2 is probably just a well-placed line or two.  I do, however, think we are going to get complaints about a different naming scheme.

Adding Radek to the CC, since he will likely want to know about this.

Chris/Radek - does anaconda set something that udev can branch on in its install environment? If we can change the biosdevname udev rules so it acts on that, then we don't even have to worry about changing anaconda/lorax for that part.

We do, though it may perhaps be too late.  We do this fairly soon once the python portion of anaconda starts:

    os.system("udevadm control --env=ANACONDA=1")

anaconda can always choose to name the interface as stored in the udev DB.

$ udevadm info /sys/class/net/enp0s25 |fgrep ID_NET
E: ID_NET_NAME_MAC=enxf0def1a25d1e
E: ID_NET_NAME_PATH=enp0s25


Just give the user a choice of:

- biosdevname name
- ID_NET_NAME_ONBOARD
- ID_NET_NAME_SLOT
- ID_NET_NAME_PATH
- ID_NET_NAME_MAC

if set.

No, we're not going to provide a user interface for the user to pick the naming scheme they want to use.

(In reply to Chris Lumens from comment #6)
> No, we're not going to provide a user interface for the user to pick the
> naming scheme they want to use.

This is sad. If not, I would suggest ID_NET_NAME_PATH, if set and not setting HWADDR.

No, what's sad is the idea that having the users pick a device naming scheme is a good UI.  It's not.  With biosdevname, very little is required from anaconda.  All we have to do is make sure it's in the environment, and the rest just happens.  You really don't want anaconda involved with naming devices, and we really don't want to be involved.

So, someone just needs to decide on a default and ensure it happens, and that someone needs to not be us.  And all this seems to be out of the scope of this bug report anyway, because Bill's already given us a pretty good plan of action in his comment above.

FYI, currently (in F19 Beta) ifcfg files are written during installation:

1) in initramfs for devices activated there, eg:

without biosdevname:

ifcfg-eth0
DEVICE=eth0
HWADDR=XX:XX:XX:XX:XX:XX
NAME="eth0"

with biosdevname:

ifcfg-p3p1
DEVICE=p3p1
HWADDR=XX:XX:XX:XX:XX:XX
NAME="eth0"

2) in initramfs (anaconda-dracut part) for devices configured in kickstart:

ifcfg-<DEV>
DEVICE=<DEV>
HWADDR=XX:XX:XX:XX:XX:XX

<DEV> is --device kickstart option or result of match of <MAC> address specified in --device=<MAC> with sys/class/net/<DEV>/address

3) in anaconda

For devices without ifcfg created in initramfs we save (via NM API) NM default auto connections fired up by NM upon start (because of missing ifcfgs), changing its NM setting['connection']['id'] to device name before saving it 
(eg from Wired_Connection_1 to enp9s0)

ifcfg-enp9s0
NAME=enp9s0
HWADDR=XX:XX:XX:XX:XX:XX

Btw, saving permanent settings for auto connections is causing reconnection of the device.

4) in LiveCD NM default auto connection can be saved

ifcfg-Wired_Connection_1
NAME="Wired Connection 1"
HWADDR=XX:XX:XX:XX:XX:XX


Initramfs and anaconda (and system) should be made consistent regarding:

- ifcfg file name:
  I think using device name is what we'll need to keep, see device naming point below

- NAME value:
  Bug #965842 has been fixed, I should probably update case 2)

- DEVICE value
  Perhaps DEVICE shouldn't be written at all (current NM behaviour), not sure how initscripts and other tools would cope with that (bug #966433)

- device naming:
  in F19 Beta
  (a) systemd-udevd's predictable names are not applied in initramfs (1,2)
  (b) biosdevname is not honored after switchroot, ie in 3) which happens if a device was not used in initramfs.

  This can result in inconsistency in installed system, eg. ifcfg-enp9s0 file created in 3) for device which will be named (because of biosdevname) p3p1 in installed system.
  
Harald, is new systemd naming going to initramfs (think eg network device specification for boot from iscsi)?

(In reply to Radek Vykydal from comment #9)
> 
> Initramfs and anaconda (and system) should be made consistent regarding:
> 
> - DEVICE value
>   Perhaps DEVICE shouldn't be written at all (current NM behaviour), not
> sure how initscripts and other tools would cope with that (bug #966433)
> 
> - device naming:
>   in F19 Beta
>   (a) systemd-udevd's predictable names are not applied in initramfs (1,2)
>   (b) biosdevname is not honored after switchroot, ie in 3) which happens if
> a device was not used in initramfs.
> 
>   This can result in inconsistency in installed system, eg. ifcfg-enp9s0
> file created in 3) for device which will be named (because of biosdevname)
> p3p1 in installed system.

If DEVICE and HWADDR is specified in the ifcfg, then biosdevname names does have no effect.

>   
> Harald, is new systemd naming going to initramfs (think eg network device
> specification for boot from iscsi)?

good point, big oversight... adding 80-net-name-slot.rules to dracut now

(In reply to Radek Vykydal from comment #9)
> - DEVICE value
>   Perhaps DEVICE shouldn't be written at all (current NM behaviour), not
> sure how initscripts and other tools would cope with that (bug #966433)

initscripts, given an argument $1:

- looks for ifcfg-$1
- if that fails, looks for a config with NAME=$1
- if that fails, looks for a config whose HWADDR equals the mac addr of device $1
- if that fails, looks for a config where DEVICE=$1
- if that fails, throws an error.

Created attachment 760256 [details]
anaconda patch to install biosdevname if passed on boot commandline

Here's a patch to anaconda that installs biosdevname if passed on the commandline. I put it in pyanaconda/install.py for lack of a good generic place.

Created attachment 760268 [details]
patch for biosdevname rules

Here is the corresponding biosdevname patch to disable automatic action on anaconda and live boots.

It would break if we changed the boot options we use to start anaconda or the live image. So let's not do that.

*prod* Any opinions? We're hitting the end of the line for F19.

(In reply to Bill Nottingham from comment #11)
> (In reply to Radek Vykydal from comment #9)
> > - DEVICE value
> >   Perhaps DEVICE shouldn't be written at all (current NM behaviour), not
> > sure how initscripts and other tools would cope with that (bug #966433)
> 
> initscripts, given an argument $1:
> 
> - looks for ifcfg-$1
> - if that fails, looks for a config with NAME=$1
> - if that fails, looks for a config whose HWADDR equals the mac addr of
> device $1
> - if that fails, looks for a config where DEVICE=$1
> - if that fails, throws an error.

You forget, that regardless of by-name or by-path or by-id strategy, anaconda is writing HWADDR to ifcfg. So by-id always wins and rename_device always renames the devices according to HWADDR.

So, an admin, who wants to rely only on by-name or by-path (biosdevname or ID_NET_NAME_ONBOARD or ID_NET_NAME_SLOT or ID_NET_NAME_PATH) _always_ has to remove HWADDR from ifcfg-*.

So this whole mess just percolated to the top of my priority list (as it was never proposed as a blocker or FE so it never hit it before). Does Bill's description of the situation in the initial report - i.e. that F19 is still basically using biosdevname, when you boil it all down - hold true? Or have things changed?

I see posts like http://forums.fedoraforum.org/showpost.php?p=1657667&postcount=35 , and I start worrying. We definitely need to document whatever the behaviour actually is somehow.

The installer will use biosdevname, unless biosdevname=0 is passed. This will end up writing the data into the installed system such that biosdevname names are used post-boot barring admin intervention.

Thanks, written up at https://fedoraproject.org/wiki/Common_F19_bugs#biosdevname-vs-systemd . Please make any corrections or useful additions that occur to you there!

What a mess. Are you aware that Matlab - which _lots_ of people use - will not work or even install unless "normal" network devices (e.g. eth0) exist? (At least this was the case back when I installed it on F17, and the MathWorks indicated that they had no plans to change.) Fortunately, I don't use Matlab, but a huge number of people are addicted to it; for them, not being able to "fix" this problem by removing biosdevname will be a disaster. This will not enhance Linux adoption.

Why were the "normal" names a problem? They seem vastly more "predictable" than the new ones.

Um. We stopped using the old names when biosdevname was first introduced. In Fedora 15.

https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming

It's really not any use to anyone to start moaning about it now, or here. That ship sailed long ago. This is about conflict between two different mechanisms for doing 'consistent' device naming, not about doing it at all. We've been doing it for two and a half years.

I know you did. However, apparently the Mathworks doesn't - or considers Linux too trivial to care about.

What is somewhat pathetic is the constant need to "fix" that which is NOT BROKEN! Please stop.

This is not a discussion forum. Please stop. (But if you're looking for answers, read the damn feature page. I just linked it.)

Oh wow.  I started a thread on this very topic here:
http://www.forums.fedoraforum.org/showthread.php?p=1658897#post1658897

Having stumbled on this bug report, I can add that the current situation feels like a decision by committee and seems to deliver the worst of all worlds.  When I do:

ip link show

I see device names of the form pnpn, which I assume are the old-new biosdevname names.  But when I look at /etc/sysconfig/network-scripts/ifcfg-*, I see ifcfg-enpnsn formatted names, which are apparently the new-new way to name names. And the only way to tie the new-old names to the new-new names are to match MAC addresses in "ip link show" with the HWADDR field in the ifcfg-*files.  In my case, I have 5 NIC slots in 2 different systems, so this is a mess.

It's actually even more of a mess, because with 2 identical systems, each with 5 NIC slots, one NIC slot in one system decided to name itself eth2.  The other system called its corresponding NIC slot p2p2.  But then removing and reinstalling the biosdevname RPM changed that eth2 name to p2p2, so now both systems are at least consistently confusing.

When I yum remove biosdevname, then "ip link show" displays the new-new names that match the ifcfg-* files.  When I put the biosdevname package back, "ip link show" displays the old-new names again.  I am tempted to just remove the biosdevname package and keep it off, but after trying to read the various documents about all this, I'm afraid to run with that biosdevname removed, since it installs by default.  There must be a good reason to install it by default and add another layer of complexity to device names....right???  Or if not, just say so and I will gladly get rid of it.  

After reading through these comments, and since the new-new names are apparently here to stay, I would like to suggest that the default installation going forward just sticks to the new-new names, do not install the biosdevname package by default, document all this very clearly in the Fedora docs, and then please please **PLEASE** don't change the naming scheme again.  And provide an easy way for users to map the old eth* names to the new names so that apps that depend on the old names don't break.  

One other apparent consequence of all this - when I try to do, say, ifup p1p1, this fails unless the HWADDR field in the file named ifcfg-enp2s0 is present and correct.  Comment out the HWADDR field and ifup fails.  This used to work in older versions at least through f16, maybe f17, and turns out to be a pain for people building HA products that need to keep a consistent MAC Address during failover operations.

- Greg Scott

"There must be a good reason to install it by default and add another layer of complexity to device names....right???"

Not one that is especially relevant to your case, no. I mean, *this bug itself* is precisely the discussion about removing it from comps; you can see the reasons for and against doing so in the first few comments.

OK fair enough. And thanks.  I removed biosdevname and I'll just use the new-new names for my little project. 

I re-read the discussion about whether to include biosdevname by default in this bug.  I think I get the debate and the pro/con points of view.  No matter what decision is made, somebody loses because the new-new naming scheme is different than the old-new naming scheme.  

But what actually ended up in the field by default in F19 looks like a compromise by committee such that **everyone** loses.  Device names end up 1/2 one way and 1/2 the other way. By default, ifcfg-nnn files are named with the new-new names, but commands such as "ip link show" display the old-new names, and once-in-a-while, they display the traditional ethn names.  

So instead of the worthy goal of consistent and predictable device names, the half and half solution currently in place (1) doesn't work reliably and (2) adds complexity to names for no apparent benefit.  

If my vote counts for anything, I vote simple is good.  If the new-new naming method really is better and more generalized, just stick with it and get rid of biosdevname.  For apps that need traditional ethnnn names, surely we can come up with some kind of logical naming scheme to map the new-new "physical-sort-of" names to ethnnn logical names and make these spps happy.  

For community members who lived in the DEC VMS world in an earlier era, logical names might be the best long term solution to please everyone.  Think of logical names as kind of like an alias, but they are global and come with parsing rules.  And they live closer to the kernel than shell aliases.  With logical names in place, physical devices can have any naming scheme they want and apps can be satisfied by mapping logical names to the newest new physical device names.  Logical name definitions could be scripted and run very early in the startup process, so that apps and daemons and other packages can load later on and reference the logical names.  Use DEC VMS as an implementation model and it would pay great benefits for a long time.  And then we won't have to go through all this again next time a new bus or class of devices comes out.  

- Greg Scott

"But what actually ended up in the field by default in F19 looks like a compromise by committee such that **everyone** loses."

No, not really, it's just that it wasn't important enough for anyone to care hard enough to fix it in time. Fedora's development cycle is insanely short. Unless any given issue is actively eating babies, it's entirely normal for it not to get fixed in time for The Next Release. This one wasn't. We didn't really *design* it to be this way, this is just the way it happened to wind up.

"And then we won't have to go through all this again next time a new bus or class of devices comes out."

Both biosdevname and systemd's naming schemes are designed to handle that.

> Both biosdevname and systemd's naming schemes are designed to handle that.

But I'm not sure they do.  The naming scheme has a PCIE bus number and slot number, right?  So device enp5s4 is an Ethernet (en) device, port 5, slot 4, right?  What happens when the PCIE bus becomes obsolete and some new bus comes along and replaces it?  What happens if backplanes get more complex with ports and subports and so forth?  If I've learned anything over the years, it's that every time we think we have a generalized enough naming scheme, something will come along and break it.  

And what about apps that depend on the traditional ethnnn naming scheme?  Admittedly poorly written - who hard codes device names?  But those apps draw lots of users and it took some apps - such as iptraf - several months to recover from the F15 biosdevname changes.  And other apps apparently won't change, so every time the naming scheme changes, those apps and all those users go away forever.

So instead of forcing everyone to update their apps and promising, this time we really really mean it, the naming scheme won't change again (except that it may have to change in the future just like it did F15-->F19), how feasible would it be to implement a system of logical names similar to the way VMS did it a long time ago?

- Greg

Also, this paragraph in the writeup linked in comment 18 is wrong:

> In practice, as things have turned out with the final Fedora 19, it seems
> that the Fedora installer still uses biosdevname, and writes the interface
> names produced by biosdevname into the configuration files for each
> interface...

What actually happens is, the configuration files get the new-new systemd device names and the rest of the system uses the new-old biosdevname device names.  So it's half one way, half the other way.  And the only way to find which one maps with which one is compare MAC Addresses from "ip link show" with the HWADDR field of each config file.  

I would reword it like this:

In practice, as things have turned out with the final Fedora 19, it seems that the Fedora installer still uses biosdevname, but writes the interface names produced by the new systemd naming scheme into the configuration files for each interface.  In practice, this means the results from commands such as "ip link show" will present different device names than what the configuration files present.  The easiest workaround to this issue is, yum remove biosdevname.  When biosdevname is removed, all device names will be presented consistent with the new systemd naming scheme.  

- Greg

I have the same "bug".

since biosdevname is still in @core of fedora its really not recommend to remove it.
Btw. I thought that this has also something to do with biosdevname:
https://bugzilla.redhat.com/show_bug.cgi?id=496444
Since I couldn't turn off IPV6INIT on a per interface basis, i could only turn it off via sysctl
I talked in IRC today with che and he said i should report it, i don't know if it is a new bug or the other just didn't got resolved correctly.

Also i cloned the bug for Fedora 19:
https://bugzilla.redhat.com/show_bug.cgi?id=982740

I'm not sure since these are related.

Btw. some additional info.

After a clean or even an upgrade of Fedora you won't have biosdevname activated.
Your Interface will be named enpXsX but after the first kernel upgrade you will have biosdevname activated which confused me quite a while since i thought that the bug i posted above has something to do with this.

Greg: The way it was written was based on Bill's initial conclusion in this bug. I now know it's not correct as written, but I don't think we have fully understood the actual behaviour yet, and I'd rather wait for that before rewriting it. I've asked Bill to look into it more deeply based on the feedback here and elsewhere.

"And what about apps that depend on the traditional ethnnn naming scheme?"

They should fix that. It's a bug. The only other possible approach - continuing to call everything ethX for all time - is not particularly practical.

What I think is happening is that anaconda (via NM) is writing NAME= from checking udev for the device name attribute (which is what systemd thinks it should be called). NAME= isn't used to set the device name (DEVICE= is) - it's just used as an identifier for the configuration.

Still need to check the code on that, though. Radek?

In any case, I do believe that the two patches (biosdevname rules + anaconda snippet) and the comps change would still result in a more predictable system, even if there's something else going on here.

I'm primarily interested in getting an accurate description of F19's behaviour for the purposes of CommonBugs (see c#31). We definitely need to fix it to be a whole lot saner for F20, though, of course.

re: Adam

>>"And what about apps that depend on the traditional ethnnn naming scheme?"

> They should fix that. It's a bug. The only other possible approach -
> continuing to call everything ethX for all time - is not particularly
> practical.

Agreed.  Of course it's a bug.  Or a poorly written app, take your pick of what you want to call it.  But like it or not, the OS needs to accommodate popular apps, even if the apps are poorly written, because apps have more clout than the OS.  If the OS attracts lots of apps, then lots of users follow and you have a nice virtuous circle.  If apps start to leave, you lose users, which encourages more apps to leave and you have a nasty vicious circle.

One really nice tactic to attract and keep popular apps, without being tied to an obsolete naming scheme at the OS level, is a logical name facility.  It's a layer between names that apps use and physical names.  Apps refer to logical names and the OS translates the logical names to physical names.  

I am not complaining about the naming scheme change.  If it's the right thing to do, then do it and do it right.  But also keep a bridge to the old naming scheme so that old apps continue to work.  A logical name facility seems like the best long term way to do this.

- Greg

(In reply to Bill Nottingham from comment #32)
> What I think is happening is that anaconda (via NM) is writing NAME= from
> checking udev for the device name attribute (which is what systemd thinks it
> should be called). NAME= isn't used to set the device name (DEVICE= is) -
> it's just used as an identifier for the configuration.

> 
> Still need to check the code on that, though. Radek?

I tried to describe how ifcfg files are written during installation in comment 
#3.
I think you are talking about case 3) - here Anaconda asks NM for list of devices (NM's GetDevices dbus API) and takes their Interface property (eg enp9s0).  Then it finds for each device its default settings[1] (device and setting are matched by HwAddress), changes 'id' of the setting to the beforementioned Interface value (eg from 'Wired Connection 1' to 'enp9s0') and saves (using NM's Setting.Update() dbus API) configuration into ifcfg file.  So the ifcfg file is named (by 'id) ifcfg-enp9s0 and has NAME=enp9s0 value. The main reason is to have ifcfg file suffixed with device name. We just want to touch the ifcfg files as little as possible directly by anaconda - first, NM knows better his defaults and values, and second, we must be careful because of NM's (ifcfg-rh plugin) inotify mechanism on the files.  Also I think the NAME value doesn't make harm. The DEVICE value is not set/saved by NM and anaconda does not add either.

I still think that the real problem here is that udev does not use biosdevname 
scheme in installer even when the feature is on (it is by default), ie (b) from comment #9:

(In reply to Radek Vykydal from comment #9)

>.
> - device naming: 
>   in F19 Beta
>   (a) systemd-udevd's predictable names are not applied in initramfs (1,2)

... bug #972662

>   (b) biosdevname is not honored after switchroot, ie in 3) which happens if
> a device was not used in initramfs.

... bug #973179

Anaconda is just using names NM sees/reports, and makes NM dump its default auto configuration for devices with missing (not created in initramfs) ifcfgs into ifcfg files.

I don't see how writing out DEVICE= by anaconda in case 3) would help to improve the situation but we should be able to do it if really necessary.

[1] which are default auto connections NM brings up in case of missing ifcfg file when it starts, these settings are only in memory, not saved as persistent ifcfgs at the moment

My two cents partial solution ...

I'm regular Fedora user.
Until Fedora 18 I've been using always biosdevname=0 in my Fedora installations to have ethX naming for my Linux boxes.

I was very disappointed because in Fedora 19, during the installation, biosdevname=0 has no effect. Anaconda uses new names to write cfg files.

After reading this thread and http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ I finally found a solution for my need.

The solution requires two steps.
I just tried in a old Pentium 4, 32bit ISO, with one gigabit on board and a wlan usb attached.

1. Supplying "net.ifnames=0" and "biosdevname=0" at boot during the installation.
-  In this way Kernel recognized my interfaces as eth0, wlan0, etc.
-  And Anaconda also created /etc/sysconfig/network-scripts/ifcfg-eth0 correctly.

2. As Anaconda doesn't make this parameters persistent, after boot everything come back to "em1", etc. So next step:
- supply "net.ifnames=0" and "biosdevname=0" to /etc/default/grub file in kernel line.
- execute "grub2-mkconfig -o /boot/grub2/grub.cfg".
- Reboot.

Voilá. Come back to old behavior.

PS: My tries:
-------------
No parameters: NIC identified as "enp5s2"
Parameter biosdevname=0: NIC identified as "enp5s2"
Parameter net.ifnames=0: NIC identified as "em1"
Parameter net.ifnames=0 AND biosdevname=0: NIC identified as "eth0"

I, too, am a regular Fedora user. I have many scripts that depend upon persistent naming conventions introduced in the last major change. 

After being switched from our long-time NIC naming conventions of ETH0, ETH1, etc., to more descriptive names like EM1 (Embedded Motherboard 1), P2P1 (PCI Bus 2, Port 1), and so on, there is now a new set of totally random-seeming and meaningless NIC names.

What do "enp0s25" and "enp0s29f7u2" mean—if anything? What kind of names are these and how do they relate to reality? The previous new naming convention was at least designed to make a connection between logical NIC names and the physical ports on the hardware. The new new naming convention is horrible as it does not seem to relate to anything. 

Please return to the "EM1" and "P2P1" naming. I don't care what is happening underneath, but I certainly do care what things look like to my scripts and I cannot go around revising all of my scripts every time someone decides to change UDEV, DBUS and/or systemd. 

PLEASE KEEP NIC NAMES CONSISTENT AND MEANINGFUL!!!

My interim request is for someone to describe the methodology of these new names in a way that relates to the hardware.

Thank you.

It's even in the subject of this bug :)

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

If you don't want to read that, just go straight to the examples:
  http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20

And no, P2P1 is only slightly better than eth0, it has a lot of the same
issues that always arise when someone "invents" names by counting global
numbers upwards. Counters depend on overall system state, on cross-device
and sibling device dependencies, and are fragile and unpredictable when
things change in unexpected ways.

The new names will not win a price for being pretty, granted; but the logic is
so trivial, that it should be reasonable safe to assume that it works reliably
in all common cases.

There is zero system-state involved, not cross-device dependencies, no
enumeration order, no driver probing order, all device names are only composed
of the data of that one single device that i detected. And that was absolutely worth the change so far.

This is a bug report. It is not a discussion forum or a soap box. Please keep that kind of stuff to an appropriate location.

Apologies, Adam - and everyone. 

Thanks, Kay for responding. The system does make sense once explained.

(In reply to Radek Vykydal from comment #36)
> > - device naming: 
> >   in F19 Beta
> >   (a) systemd-udevd's predictable names are not applied in initramfs (1,2)
> 
> ... bug #972662

Fixed in RHEL-7's dracut-030

I installed Fedora 19 using PXE on a PowerEdge R610 and have the following observations. The system has four onboard network devices and one dual port add-in adapter on slot 2. During installation, dmesg from the shell (ctrl+alt+F2) showed the following -

1.

[    8.486337] systemd-udevd[341]: starting version 204
[    8.746893] systemd-udevd[386]: renamed network interface eth1 to em2
[    8.884005] systemd-udevd[387]: renamed network interface eth0 to em1
[    8.915135] systemd-udevd[388]: renamed network interface eth3 to em4
[    8.921022] systemd-udevd[389]: renamed network interface eth2 to em3
[    8.983877] systemd-udevd[386]: renamed network interface eth1 to p2p1
[   39.289998] systemd-udevd[492]: renamed network interface eth0 to p2p2

From the above, i expected the above names to be final because 71-biosdevname.rules sets NAME= the above names. 

PROGRAM="/sbin/biosdevname --policy physical -i %k", NAME="%c",  OPTIONS+="string_escape=replace"

But the next messages in 'dmesg' looked interesting -

[   75.892244] systemd-udevd[904]: renamed network interface em4 to eno4
[   75.980668] systemd-udevd[908]: renamed network interface em2 to eno2
[   76.071475] systemd-udevd[928]: renamed network interface p2p2 to enp5s0f1
[   76.170423] systemd-udevd[923]: renamed network interface p2p1 to enp5s0f0
[   76.368452] systemd-udevd[910]: renamed network interface em3 to eno3

The emN names became the udev enoN names and pXpY became enpN. I did not expect this because the 80-net-slot.rules has the following line

NAME!="", GOTO="net_name_slot_end"

and 71-biosdevname.rules sets NAME=%c (em1, em2 etc).

For em2 to become eno2, the NAME variable should be ""(null) as per the above. From the dmesg messages, it seems like NAME is null (atleast when emN became enoN). I am not sure how this could happen. Could it be something with udev where NAME is set to something, but it becomes NULL for some reason ? 

a. 71-biosdevname.rules -> ethN becomes emN, sets NAME
b. 80-net-slot.rules -> renames emN to enoN (though NAME was set).

But em1 remained em1, probably because that was used for PXE booting and before it could be renamed, it was brought UP and an IP was assigned.

2. The same did not happen at run time after installation completes and first boot completes. All names were emN ( though due to the renaming issue at install time, the config files were ifcfg-em1 for the first and ifcfg-enoN for the rest - they matches with the names that existed during install time)

3. Only ifcfg-em1 had DEVICE=em1. This interface was used for PXE booting. It also has the line, "generated by dracut".

Rest of the config files did not have the DEVICE= field. They only had NAME=. It seems like /lib/udev/rename_device looks for DEVICE= in 60-net.rules.

(In reply to Narendra K from comment #43)

You are probably hitting bug 973179. Also bug 988766 might be related.

(In reply to Radek Vykydal from comment #44)
> (In reply to Narendra K from comment #43)
> 
> You are probably hitting bug 973179. Also bug 988766 might be related.

Hello, thanks for the pointer. The bug 973179 seems to indicate that biosdevname suggested names are not used to rename the interfaces, but udev suggested (because of 80-net-slot.rules) names are being used (and the description seems to match the description mentioned in this bug).

But by looking at the dmesg, biosdevname names are being applied

[    8.746893] systemd-udevd[386]: renamed network interface eth1 to em2
[    8.884005] systemd-udevd[387]: renamed network interface eth0 to em1
[    8.915135] systemd-udevd[388]: renamed network interface eth3 to em4

But the there should not have been renaming of emN names to enoN names as currently happening below.

[   75.892244] systemd-udevd[904]: renamed network interface em4 to eno4
[   75.980668] systemd-udevd[908]: renamed network interface em2 to eno2

Please let me know if i am missing some detail here.

It seems like the NAME being set in 71-biosdevname.rules is not being seen by 80-net-slot.rules (or is not being respected/ignored for some reason) and udev goes ahead and renames the em2 to eno2. Could this be something with udev itself ? This behavior is not seen during run time (after installation completes and after first boot).

(In reply to Radek Vykydal from comment #44)
> (In reply to Narendra K from comment #43)
> 
> You are probably hitting bug 973179. Also bug 988766 might be related.

I do not have permission to view bug 988766.

Narendra, I believe that with biosdevname-0.5.0-2.fc20 (and dracut > 029, systemd > 206) the issue should be fixed in Fedora (F20 Alpha should work).

Nope.  Naming is still broken in Fedora 20.  I have a small system here with a Jetway motherboard and Jetway daughter card.  5 total wired NIC slots.  It also has an Intel wireless card.  Take a look at this - notice the ifcfg-*** files do not match the names from ip link show:

I can reconcile all this by matching up MAC Addresses and renaming/editing files appropriately.  But this should work right out of the box.

[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: p4p3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: p4p4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]# ls /etc/sysconfig/network-scripts/ifcfg*
/etc/sysconfig/network-scripts/ifcfg-lo
/etc/sysconfig/network-scripts/ifcfg-p2p1
/etc/sysconfig/network-scripts/ifcfg-p3p1
/etc/sysconfig/network-scripts/ifcfg-p4p1
/etc/sysconfig/network-scripts/ifcfg-p4p2
/etc/sysconfig/network-scripts/ifcfg-p4p3
[root@springil-fw ~]#

I have another system, nearly identical except the other one does not have the wireless card.  ip link show and the ifcfg-*** files seem to match on that one.  So the wireless card seems to be the trouble causer.

- Greg

Here is a table of MAC Addresses from ip link show and the ifcfg-nnn files that match the MAC Addresses. 

p4p2: link/ether 00:30:18:c0:6c:c6   ifcfg-p4p1 (wrong)
p4p3: link/ether 00:30:18:c0:6c:c7   ofcfg-p4p2 (wrong)
p2p1: link/ether 00:30:18:af:72:48   ifcfg-p2p1 (matches)
p3p1: link/ether 00:30:18:af:72:49   ifcfg-p3p1 (matches)
p4p4: link/ether 00:30:18:af:72:4a   ifcfg-p4p3 (wrong)

So the pattern is:

ifcfg-p4p3 --> should be ifcfg-p4p4
ifcfg-p4p2 --> should be ifcfg-p4p3
ifcfg-p4p1 --> should be ifcfg-p4p2

One correction on my comment number 50 I just posted above.  I did a fresh install, then did yum remove biosdevname and rebooted.  This was my workaround for device naming weirdness in F19 but I changed my mind this time and decided to try and keep the device names as delivered.  So I did yum install biosdevname and another reboot to put things back the way they were.  Now that I have all this documented, I will try another fresh F20 install on this same hardware and see what device names show up.

- Greg

And after a fresh F20 build on the same hardware as above, I can confirm the ifcfg-nnn files do not match what "ip link show" shows me.  The pattern is the same as in comments 50 and 51, but now after a brand new fresh F20 build.  

Here an extract from dmsesg.  Curious - it looks like udevd renamed all the NIC slots except eth1.  There's no mention in here of renaming eth1 to anything.  Of the 5 NICs, 4 are renamed, but not eth1. The Jetway motherboard has two onboard NICs and the daughter card has 3 additional NIC slots, for a total of 5 wired NIC slots, plus one wireless card.  

And even though dmesg shows no evidence eth1 was renamed to anything, when I do "ip link show", there's no mention of eth1.  Somehow, what used to be eth1 apparently ended up being called p4p3.  But there are no occurrences of the string "p4p3" anywhere in the dmesg output.  

.
.
.
[    5.697699] r8169 0000:02:00.0 eth0: RTL8168e/8111e at 0xffffc9000006c000, 00:30:18:c0:6c:c6, $
[    5.697711] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[    5.697906] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    5.698086] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[    5.702752] r8169 0000:03:00.0: irq 47 for MSI/MSI-X
[    5.703698] r8169 0000:03:00.0 eth1: RTL8168e/8111e at 0xffffc9000006e000, 00:30:18:c0:6c:c7, $
[    5.703710] r8169 0000:03:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[    5.703766] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    5.703808] r8169 0000:05:04.0: enabling device (0000 -> 0003)
[    5.704182] r8169 0000:05:04.0 (unregistered net_device): not PCI Express
[    5.704734] r8169 0000:05:04.0 eth2: RTL8169sc/8110sc at 0xffffc90010082000, 00:30:18:af:72:48$
[    5.704746] r8169 0000:05:04.0 eth2: jumbo features [frames: 7152 bytes, tx checksumming: ok]
[    5.704798] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    5.704828] r8169 0000:05:06.0: enabling device (0000 -> 0003)
[    5.705113] r8169 0000:05:06.0 (unregistered net_device): not PCI Express
[    5.705734] r8169 0000:05:06.0 eth3: RTL8169sc/8110sc at 0xffffc90010084000, 00:30:18:af:72:49$
[    5.705746] r8169 0000:05:06.0 eth3: jumbo features [frames: 7152 bytes, tx checksumming: ok]
[    5.705811] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    5.705840] r8169 0000:05:07.0: enabling device (0000 -> 0003)
[    5.706128] r8169 0000:05:07.0 (unregistered net_device): not PCI Express
[    5.706809] r8169 0000:05:07.0 eth4: RTL8169sc/8110sc at 0xffffc90010086000, 00:30:18:af:72:4a$
[    5.706822] r8169 0000:05:07.0 eth4: jumbo features [frames: 7152 bytes, tx checksumming: ok]
[    5.761300] i801_smbus 0000:00:1f.3: enabling device (0000 -> 0001)
[    5.761564] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[    5.815583] Bluetooth: Core ver 2.16
[    5.815658] NET: Registered protocol family 31
.
.
.
[    6.280334] systemd-udevd[414]: renamed network interface wlan0 to wlp1s0
.
.
.
[    6.337180] SELinux: initialized (dev sda1, type vfat), uses genfs_contexts
[    6.384406] systemd-udevd[417]: renamed network interface eth3 to p3p1
[    6.448371] systemd-udevd[416]: renamed network interface eth2 to p2p1
[    6.485997] systemd-journald[386]: Received request to flush runtime journal from PID 1
[    6.486728] type=1305 audit(1396631075.849:4): audit_pid=499 old=0 auid=4294967295 ses=4294967$
 subj=system_u:system_r:auditd_t:s0 res=1
[    6.537600] systemd-udevd[410]: renamed network interface eth0 to p4p2
[    6.544386] systemd-udevd[418]: renamed network interface eth4 to p4p4
[    7.678684] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    7.740318] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    7.882794] Ebtables v2.0 registered
[    7.931512] Bridge firewalling registered
[    8.847851] r8169 0000:02:00.0 p4p2: link down
[    8.847930] IPv6: ADDRCONF(NETDEV_UP): p4p2: link is not ready
[    9.005790] r8169 0000:03:00.0 eth1: link down
[    9.005847] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[    9.024224] r8169 0000:05:04.0 p2p1: link down
[    9.024280] r8169 0000:05:04.0 p2p1: link down
[    9.024305] IPv6: ADDRCONF(NETDEV_UP): p2p1: link is not ready
[    9.040434] r8169 0000:05:06.0 p3p1: link down
[    9.040440] r8169 0000:05:06.0 p3p1: link down
[    9.040509] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[    9.054183] r8169 0000:05:07.0 p4p4: link down
[    9.054227] r8169 0000:05:07.0 p4p4: link down
[    9.054270] IPv6: ADDRCONF(NETDEV_UP): p4p4: link is not ready
[    9.060453] iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S
[    9.343224] iwlwifi 0000:01:00.0: Radio type=0x2-0x1-0x0
[    9.416306] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[   12.209749] r8169 0000:05:07.0 p4p4: link up
[   12.209771] IPv6: ADDRCONF(NETDEV_CHANGE): p4p4: link becomes ready
[   23.848739] nf_conntrack: automatic helper assignment is deprecated and it will be removed soo$

Aw nuts, I should have looked more closely after my new fresh install.  After a brand new fresh install, this is what ip link show gives me - and this explains why nobody renamed device eth1.  

[root@localhost network-scripts]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: p4p4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@localhost network-scripts]#

But all the ifcfg- files are of the form ifcfg-p#p#.  So I renamed and edited them per comment 51 and rebooted.  Back up, now device p4p4 is missing, replaced with device eth4.  Well this is bizarre!  Well not really - eth4 is the original name of p4p4 before the renames that don't always rename kick in.  

So I did yum remove biosdevname and rebooted.  Then yum install biosdevname again and reboot.  And now ip link show shows me eth1 instead of p4p3.  This is frustrating.  The same hardware with the same build of the same Fedora version acts differently when I install it again.  

So from where I sit, biosdevname is still broken.

- Greg

It always gives me a headache trying to track these mechanisms, but it's worth remembering that both biosdevname and the systemd naming mechanism ultimately work through udev. However, I'm not sure both are logged. The absence of a log message doesn't actually mean that one of those isn't kicking in, I don't think.

It would be interesting, if possible, if you could compare a fresh install with biosdevname included against a fresh install without biosdevname included. At least passing 'biosdevname=0' on the command line, and possibly using a kickstart with biosdevname package listed for non-inclusion, i.e.:

%packages
blahblah
-biosdevname
%end

I don't have the kind of nice juicy multiple-interfaced system you have lying around for testing, unfortunately - all the testing I've done on this I've just done by sticking more virtual interfaces into a VM...

thanks!

It's not like I have this nice juicy multiple-interfaced system here forever.  Sooner or later, I need to deliver a completed firewall on it.

I don't have another fresh install to show you, but hopefully this will be more usable.  Details below - I did 3 cycles of yum remove biosdevname, reboot, yum install biosdevname, reboot.  With each cycle after installing biosdevname, the p#p# and eth# names were different than the last time.

Some kind of timing glitch?  I don't how how to work around this.

Details:

Starting with biosdevname in place

[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: p4p4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]# 

After yum remove biosdevname and reboot

[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: enp5s4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: enp5s6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: enp5s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#

yum install biosdevname and reboot - what was p4p4 is now p4p3.

[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: p4p3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#

Another cycle - remove biosdevname and install it back again.  This time what was eth1 becomes p4p3 and what was p4p4 becomes eth4.  

login as: root
root.10.105's password:
Last login: Sat Apr  5 04:49:49 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: enp5s4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: enp5s6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: enp5s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#
[root@springil-fw ~]#
[root@springil-fw ~]# yum install biosdevname
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package biosdevname.x86_64 0:0.5.0-2.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================
 Package                Arch              Version                   Repository         Size
============================================================================================
Installing:
 biosdevname            x86_64            0.5.0-2.fc20              fedora             36 k

Transaction Summary
============================================================================================
Install  1 Package

Total download size: 36 k
Installed size: 58 k
Is this ok [y/d/N]: y
Downloading packages:
biosdevname-0.5.0-2.fc20.x86_64.rpm                                  |  36 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : biosdevname-0.5.0-2.fc20.x86_64                                          1/1
  Verifying  : biosdevname-0.5.0-2.fc20.x86_64                                          1/1

Installed:
  biosdevname.x86_64 0:0.5.0-2.fc20

Complete!
[root@springil-fw ~]# reboot

Broadcast message from root@springil-fw on pts/0 (Sat 2014-04-05 04:54:03 CDT):

The system is going down for reboot NOW!

[root@springil-fw ~]#
login as: root
root.10.105's password:
Last login: Sat Apr  5 04:53:14 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: p4p3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#

(In reply to Greg Scott from comment #55)
> It's not like I have this nice juicy multiple-interfaced system here
> forever.  Sooner or later, I need to deliver a completed firewall on it.
> 
> I don't have another fresh install to show you, but hopefully this will be
> more usable.  Details below - I did 3 cycles of yum remove biosdevname,
> reboot, yum install biosdevname, reboot.  With each cycle after installing
> biosdevname, the p#p# and eth# names were different than the last time.
> 
> Some kind of timing glitch?  I don't how how to work around this.
[...]
> 
> yum install biosdevname and reboot - what was p4p4 is now p4p3.
> 

Hi Greg, would it be possible to give the test rpm from https://bugzilla.redhat.com/show_bug.cgi?id=782145#c41 
a try on your system and share the results ? It would be helpful to know, after installing the rpm,  if the names consistent across multiple reboots.

Also, could you please attach output of the following from your system ?

dmidecode
biosdecode
lspci -tv
lspci -vvvxxxx
biosdevname -d

Hi Narendra - 

Here is some of what you asked for.  The output from lspci -vvvxxxx is pretty big so I'll paste that in the next comment.  And I need to figure out how to run dmidecode and biosdecode.

[root@springil-fw ~]#
[root@springil-fw ~]# dmidecode
-bash: dmidecode: command not found
[root@springil-fw ~]#
[root@springil-fw ~]#
[root@springil-fw ~]# biosdecode
-bash: biosdecode: command not found
[root@springil-fw ~]#
[root@springil-fw ~]#
[root@springil-fw ~]# lspci -tv
-[0000:00]-+-00.0  Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller
           +-02.0  Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller
           +-1b.0  Intel Corporation NM10/ICH7 Family High Definition Audio Controller
           +-1c.0-[01]----00.0  Intel Corporation Centrino Advanced-N 6235
           +-1c.1-[02]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           +-1c.2-[03]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           +-1c.3-[04]----00.0  ASMedia Technology Inc. ASM1061 SATA IDE Controller
           +-1d.0  Intel Corporation NM10/ICH7 Family USB UHCI Controller #1
           +-1d.1  Intel Corporation NM10/ICH7 Family USB UHCI Controller #2
           +-1d.2  Intel Corporation NM10/ICH7 Family USB UHCI Controller #3
           +-1d.3  Intel Corporation NM10/ICH7 Family USB UHCI Controller #4
           +-1d.7  Intel Corporation NM10/ICH7 Family USB2 EHCI Controller
           +-1e.0-[05]--+-04.0  Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller
           |            +-06.0  Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller
           |            \-07.0  Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller
           +-1f.0  Intel Corporation NM10 Family LPC Controller
           +-1f.2  Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode]
           \-1f.3  Intel Corporation NM10/ICH7 Family SMBus Controller
[root@springil-fw ~]#
[root@springil-fw ~]#
[root@springil-fw ~]#
[root@springil-fw ~]# biosdevname -d
BIOS device: p2p1
Kernel name: p2p1
Permanent MAC: 00:30:18:AF:72:48
Assigned MAC : 00:30:18:AF:72:48
ifIndex: 4
Driver: r8169
Driver version: 2.3LK-NAPI
Firmware version:
Bus Info: 0000:05:04.0
PCI name      : 0000:05:04.0
PCI Slot      : 2
Index in slot: 1

BIOS device: p3p1
Kernel name: p3p1
Permanent MAC: 00:30:18:AF:72:49
Assigned MAC : 00:30:18:AF:72:49
ifIndex: 5
Driver: r8169
Driver version: 2.3LK-NAPI
Firmware version:
Bus Info: 0000:05:06.0
PCI name      : 0000:05:06.0
PCI Slot      : 3
Index in slot: 1

BIOS device: p4p1
Kernel name: wlp1s0
Permanent MAC: C8:F7:33:F3:9D:46
Assigned MAC : C8:F7:33:F3:9D:46
ifIndex: 7
Driver: iwlwifi
Driver version: 3.11.10-301.fc20.x86_64
Firmware version: 18.168.6.1
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : 4
SMBIOS Label: J8B4
Index in slot: 1

BIOS device: p4p2
Kernel name: p4p2
Permanent MAC: 00:30:18:C0:6C:C6
Assigned MAC : 00:30:18:C0:6C:C6
ifIndex: 2
Driver: r8169
Driver version: 2.3LK-NAPI
Firmware version: rtl_nic/rtl8168e-2.fw
Bus Info: 0000:02:00.0
PCI name      : 0000:02:00.0
PCI Slot      : 4
SMBIOS Label: J8B4
Index in slot: 2

BIOS device: p4p3
Kernel name: p4p3
Permanent MAC: 00:30:18:C0:6C:C7
Assigned MAC : 00:30:18:C0:6C:C7
ifIndex: 3
Driver: r8169
Driver version: 2.3LK-NAPI
Firmware version: rtl_nic/rtl8168e-2.fw
Bus Info: 0000:03:00.0
PCI name      : 0000:03:00.0
PCI Slot      : 4
SMBIOS Label: J8B4
Index in slot: 3

BIOS device: p4p4
Kernel name: eth4
Permanent MAC: 00:30:18:AF:72:4A
Assigned MAC : 00:30:18:AF:72:4A
ifIndex: 6
Driver: r8169
Driver version: 2.3LK-NAPI
Firmware version:
Bus Info: 0000:05:07.0
PCI name      : 0000:05:07.0
PCI Slot      : 4
Index in slot: 4

[root@springil-fw ~]#

Created attachment 915886 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

After removing the stock F20 biosdevname, rebooting, then installing the test biosdevname and rebooting, it's still messed up but messed up differently:

login as: root
root.10.105's password:
Last login: Sat Apr  5 04:55:07 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# cd /home/gregs
[root@springil-fw gregs]# rpm -i biosdevname-0.5.0-1test.fc18.x86_64.rpm
[root@springil-fw gregs]# reboot

Broadcast message from root@springil-fw on pts/0 (Sat 2014-04-05 06:33:24 CDT):

The system is going down for reboot NOW!

[root@springil-fw gregs]#
login as: root
root.10.105's password:
Last login: Sat Apr  5 06:33:10 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: p4p3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: enp5s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#

Created attachment 883029 [details]
Output from biosdecode per Narendra in comment 56

For anyone else reading this - you have to yum install dmidecode to make dmidecode and biosdecode work.

- Greg

Created attachment 883031 [details]
Output from dmidecode per Narendra in comment 56

Erased the test RPM, rebooted, then yum installed the stock F20 biosdevname, rebooted again.  Now all the names are p#p#.

[root@springil-fw ~]# rpm -e biosdevname-0.5.0-1test.fc18.x86_64
[root@springil-fw ~]# reboot

Broadcast message from root@springil-fw on pts/0 (Sat 2014-04-05 06:48:52 CDT):

The system is going down for reboot NOW!

[root@springil-fw ~]#
login as: root
root.10.105's password:
Last login: Sat Apr  5 06:34:27 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: enp5s4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: enp5s6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: enp5s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]# yum install biosdevname
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package biosdevname.x86_64 0:0.5.0-2.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================
 Package                Arch              Version                   Repository         Size
============================================================================================
Installing:
 biosdevname            x86_64            0.5.0-2.fc20              fedora             36 k

Transaction Summary
============================================================================================
Install  1 Package

Total download size: 36 k
Installed size: 58 k
Is this ok [y/d/N]: y
Downloading packages:
biosdevname-0.5.0-2.fc20.x86_64.rpm                                  |  36 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
  Installing : biosdevname-0.5.0-2.fc20.x86_64                                          1/1
  Verifying  : biosdevname-0.5.0-2.fc20.x86_64                                          1/1

Installed:
  biosdevname.x86_64 0:0.5.0-2.fc20

Complete!
[root@springil-fw ~]# reboot

Broadcast message from root@springil-fw on pts/0 (Sat 2014-04-05 06:50:07 CDT):

The system is going down for reboot NOW!

[root@springil-fw ~]#
login as: root
root.10.105's password:
Last login: Sat Apr  5 06:49:34 2014 from bethhp100b.infrasupport.local
[root@springil-fw ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p4p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c6 brd ff:ff:ff:ff:ff:ff
3: p4p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:c0:6c:c7 brd ff:ff:ff:ff:ff:ff
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:48 brd ff:ff:ff:ff:ff:ff
5: p3p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:49 brd ff:ff:ff:ff:ff:ff
6: p4p4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:30:18:af:72:4a brd ff:ff:ff:ff:ff:ff
7: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c8:f7:33:f3:9d:46 brd ff:ff:ff:ff:ff:ff
[root@springil-fw ~]#

I can confirm that NIC device names are apparently random after simple reboots using biosdevname-0.5.0-2.fc20 installed from comment 62 immediately above.  Before a reboot, device names were as shown above.  After the reboot, what was p4p4 became eth4.  I thought earlier it was from removing and reinstalling biosdevname.  But the names change after simple reboots.  

For what it's worth, I have another system here with the same 5 wired NICs.  That system acts fine across reboots.  The difference between the good and bad system is the Intel wireless NIC in the bad system.  I'll bet that wireless NIC somehow messes up the calculations biosdevname uses to figure out what's in what slot. That's probably why the ifcfg-nnn files did not match "ip link show" after the initial installation. Note that in all my testing, wireless device w1p1s0 always kept its kernel name.  Which is just fine by me because that makes it easy to pick out.  

I need to deliver both sytems today so I won't have this piece of hardware for troubleshooting any more.  I may have others later.  I ended up doing yum remove biosdevname and using the enp#s# kernel device names instead.  I renamed and edited the ifcfg-nnn files accordingly.  For this application, I don't care what the NICs are called, they just need to be consistent across reboots.  It would be a disaster if the device names went haywire when this is deployed at a remote site with nobody to look after it.

If you need hardware for troubleshooting, contact me privately and I can get you the exact specs and pricing for this system.  All HW is off the shelf.  

- Greg

Aw nuts.  I set up two more of those systems today with 5 wired NICs.  Same config as comment 63 above but with **no** wireless NIC.  After reboots, these units also sometimes showed ethnn device names instead of p#p# device names.  

I worked around the problem by removing biosdevname and using kernel names for everything.  I'll have to recall the other unit I delivered today that used biosdevname names.  It stayed consistent across reboots, but with other identical units behaving badly, sooner or later the one from this morning will also start behaving badly.

If I get a vote, I vote to just get rid of biosdevname.  What difference does it make whether a device is called p4p2 or enp3s0?  At least when it's called enp3s0, it keeps the same name across reboots. Why add a layer of complexity to give them biosdevname names?

it's kind of a historical thing - we got biosdevname first, and not too long ago, and then the systemd/udev mechanism came along and wanted to replace biosdevname. some of us were a bit antsy about changing the naming scheme twice in fairly quick succession.

unfortunately we wound up without a terribly clear resolution - both mechanisms are in the distro and we didn't really rigorously ensure that either or both work reliably, or define which one is the default. I said this for F20, but again, for F21, we really ought to nail this down. maybe just ditching biosdevname *is* the way to go.

Observations:

1. biosdevname depends on the availability of SMBIOS type 41 records to name onboard network devices and type 9 records to name add-in network devices in PCI slots. From the logs from comment #57,58, 60 and 61, it seems like the type 41 and type 9 records are incorrect.

From the 'lspci -vvvxxxx' output, the following output indicates all the NICs in the system.

# cat lspci-vvvxxxx |grep "Ethernet controller"
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
05:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
05:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)


The type 9 records from the dmidecode output attached (I have trimmed the records just to show the 'Designation' and 'Bus Address' fields.

Handle 0x0020, DMI type 9, 17 bytes
System Slot Information
        Designation: J6B2
        [...]
        Bus Address: 0000:00:01.0

Handle 0x0021, DMI type 9, 17 bytes
System Slot Information
        Designation: J6B1
       [...]
        Bus Address: 0000:00:1c.3

Handle 0x0022, DMI type 9, 17 bytes
System Slot Information
        Designation: J6D1
        [...]
        Bus Address: 0000:00:1c.4

Handle 0x0023, DMI type 9, 17 bytes
System Slot Information
        Designation: J7B1
        [...]
        Bus Address: 0000:00:1c.5

Handle 0x0024, DMI type 9, 17 bytes
System Slot Information
        Designation: J8B4
       [...]
        Bus Address: 0000:00:1c.6

From the attached 'lspci -vvvxxxx' output. the PCI devices as indicated in these type 9 records don't seem to be present in the system, except for 00:1c.3. The type 9 records need to have the PCI b/d/f of the add-in NIC on PCI slot. Also, biosdevname version 0.5.0 can recursively scan the bus if the type 9 records populate the PCI b/d/f of the bridge device under which NICs are present. From the attached 'lspci -tv' output, the type 9 records from the system don't seem to have that.

[root@localhost bz-965718]# cat lspci-vvvxxxx |grep 00:1c.3
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode])
[root@localhost bz-965718]# cat lspci-vvvxxxx |grep 00:1c.4
[root@localhost bz-965718]# cat lspci-vvvxxxx |grep 00:1c.5
[root@localhost bz-965718]# cat lspci-vvvxxxx |grep 00:1c.6

2. So it seems like biosdevname is falling back on PIRQ table (biosdecode output) in the absence of correct type 9 records. I am not yet sure where the issue here is.

3. The test rpm contained a fix for an issue where one or more interfaces from a single quad port NIC, got renamed to renameN. If the system does not have a quad port system, then it might or might not be running into this issue. The possibility of occurrence of this issue is more with a quad port Network Controller, though it might happen with a dual port card.

Hi Greg,

Could you please

1. Share the detail as to which PCI slot has which of the NICs in the system ? For example -

PCI slot 1 has one single port NIC with PCI b/d/f
PCI slot 2 has a dual port NIC with PCI b/d/f1 and PCI b/d/f 

for all the slots/NICs in the system ?

2. Attach the output from 'dmidecode -t 41 -u' and 'dmidecode -t 9 -u'

3. Check with the BIOS vendor about the SMBIOS type 9 records.

The systems I used for all the testing last week are deployed at customer sites and no longer available.  The good news is, I have two more systems coming.  I am out of town next week at the Red Hat Summit, so I should be able to get you what you need the following week. 

With this hardware, the motherboard has 2 NIC slots and a daughtercard has 3 more.  Here is a list of the hardware:

M350 Universal Mini-ITX enclosure
Jetway JNF9D-2550
Jetway AD3RTLANG 3 x Gigabit LAN Port Daughter
Board for Jetway J7F2WE1G5D, Jetway J7F2WE1G,
Jetway J7F2WE1G2E Motherboards
MEM-SO-DDR3-2GB
Sandisk 32GB ReadyCache SSD
PicoPSU-80 + 60W Adapter Power Kit
DF124010BM FANS
Top Motor 40x40x10mm Case Fans
M350-HDD Brackets
Intel Centrino Advanced-N 6235
Wireless Antenna SMA reverse +5dBi
Cable I-PEX reverse SMA

I'll see if I can find a contact at Jetway to work this.

- Greg

Please allow me to add my voice to this issue.  I have the same issues with pretty much any hardware with multiple NICs, it has literally caused my dept to switch away from Fedora.

Rebooting still causes NICs to be reordered.  IMO, this should be considered a critical blocker for Fedora 21.

+1 for Joshua above.

If my HW is not an isolated case then I urge the Fedora team in the strongest possible terms to come up with a resolution.  And the simplest seems to be just bite the bullet and get rid of biosdevname or at least make the default installation not use it.  If you're testing with virtual machines, clearly real hardware behaves differently. Thinking longer term - what happens when this code works its way into RHEL and we have RHEL servers with multiple NICs renaming themselves randomly at reboots.  I would not want to be on the wrong end of all those service calls.

(In reply to joshua from comment #68)
> Please allow me to add my voice to this issue.  I have the same issues with
> pretty much any hardware with multiple NICs, it has literally caused my dept
> to switch away from Fedora.
> 
> Rebooting still causes NICs to be reordered.  IMO, this should be considered
> a critical blocker for Fedora 21.

Hi, would it be possible to give the test rpm from 
https://bugzilla.redhat.com/show_bug.cgi?id=782145#c41
a try on your system ? 

Does the system have a single network controller with multiple ports or there are multiple network controllers with single ports on different PCI slots ?

The latest upstream biosdevname contains the following fix for an issue where one or more interfaces of a quad port network adapter are named renameN. 

Fix regression introduced by the addslot function
http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=biosdevname.git;a=commit;h=0bc6ce6d8da61153e7bfd1c3444ab06c0c83d0af

It would be great if you could pull this tree and share results. The test rpm has this fix included.

Also, please share the following output from the system.

dmidecode
biosdecode
lspci -tv
lspci -vvvxxxx
biosdevname -d

(In reply to Greg Scott from comment #67)
> The systems I used for all the testing last week are deployed at customer
> sites and no longer available.  The good news is, I have two more systems
> coming.  I am out of town next week at the Red Hat Summit, so I should be
> able to get you what you need the following week. 
> 
> With this hardware, the motherboard has 2 NIC slots and a daughtercard has 3
> more.  Here is a list of the hardware:
> 
[...]

Thanks. It is not clear from the type 9 records as to what is the correct/expected names of the NICs in the system. It would be helpful if you could help understand the expected names of the the NICs by inspecting physically which PCI slot is the NIC physically seated. For example, a dual port NIC on PCI slot 1, so that the expected name would be p1p1 and p1p2. 

'ethtool -i <interface name>' could be used to find the PCI bus/device/function of the network interface.

I have that same hardware config deployed at another site, so I can get you the ethtool info  below.  This one is with F19, not F20 and as you can see below, I set it up without biosdevname because of similar device naming inconsistencies in F19.  

Visual inspection of this hardware will not show anything about what NIC is in which PCIE slot.  The motherboard has 2 NIC slots and than a daughtercard had 3 more.  The whole thing fits in a mini ITX (I think that's the right word) enclosure about 7-8 inches square and about 1 inch thick.  So it probably has some fancy electronics emulating PCIE slots to make it all work  

[root@chicago-fw1 ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP  mode DEFAULT qlen 1000
    link/ether 12:34:56:07:61:94 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP  mode DEFAULT qlen 1000
    link/ether 12:34:56:01:52:54 brd ff:ff:ff:ff:ff:ff
4: enp5s4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state D OWN mode DEFAULT qlen 1000
    link/ether 00:30:18:a2:a3:3e brd ff:ff:ff:ff:ff:ff
5: enp5s6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qle n 1000
    link/ether 00:30:18:a2:a3:3f brd ff:ff:ff:ff:ff:ff
6: enp5s7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state D OWN mode DEFAULT qlen 1000
    link/ether 00:30:18:a2:a3:40 brd ff:ff:ff:ff:ff:ff
[root@chicago-fw1 ~]#
[root@chicago-fw1 ~]# ethtool -i enp2s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168e-3_0.0.4 03/27/12
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@chicago-fw1 ~]#
[root@chicago-fw1 ~]# ethtool -i enp3s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168e-3_0.0.4 03/27/12
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@chicago-fw1 ~]#
[root@chicago-fw1 ~]# ethtool -i enp5s4
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:05:04.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@chicago-fw1 ~]#
[root@chicago-fw1 ~]# ethtool -i enp5s6
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:05:06.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@chicago-fw1 ~]#
[root@chicago-fw1 ~]# ethtool -i enp5s7
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:05:07.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@chicago-fw1 ~]#

So, hum. To introduce a procedural note here: Greg's issue has rather taken over this bug, but as I read it, it doesn't actually involve the possible competition between biosdevname and the systemd mechanism, it's rather just that biosdevname does not behave as expected in your case, yes? (And, I'm guessing, Joshua's, although he doesn't provide any kind of detailed info, so all I can do in that case is guess.)

If so, could that perhaps be split off as a separate bug? Although, with the volume in this one, we might have to burn it down and start over.

Note, RHEL 7 already contains biosdevname, so it'd certainly be of interest to know if this bug affects RHEL 7. There is a public beta, though it's somewhat old at this point; do you have access to more current RHEL 7 code? If not, I can try and see if I can arrange for it somehow.

Thanks very much for all your feedback on this.

Yeah, I guess we got deep into troubleshooting. I'll be happy to open a new bug when my new hardware comes in if that's what the community wants.  From the point of view in the field - if Fedora is going to do biosdevname then it needs to be rock solid and right now it's not. It's been broken for at least 2 releases.  Everyone knows Fedora is bleeding edge and is the place to work out bugs.  But biosdevname is now appearing in RHEL and I have a hunch that RHEL 7 Beta will break the same way as F20 with the hardware I detailed in comment 67 above.  And I'm wondering what value biosdevname adds, other than giving the NICs a different name.  

Meantime, the systemd mechanism with the enp names seems solid and works.  I can count on devices keeping the same name from boot to boot. I haven't done an install yet without biosdevname so I am not able to judge how well it works making the ifcfg-nnn files match ip link show.  But from what I've seen so far, the systemd approach seems more solid. So let's just use it as the default with F21.  

But if Fedora wants to use biosdevname, I'm willing to help test to get it right.  I think everyone wants this settled for good.

As promised, I have more hardware configured as in comment 67.  This time I installed F20 as before, but edited the kernel command line when I booted the DVD with "biosdevname=0".  It came up as I expected using enp#s# for NIC names. And the MAC Addresses and names in the ifcfg-enp#s# files all match this time.  

Since this scheme is consistent and the other one is not, let's make this one the default behavior with F21 and beyond.  And back-port it to RHEL to save a few $million in service calls. 

- Greg

So, this has now been out of line with the Feature agreed by FESCo for Fedora 19 for, like, a year and a half:

https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames

"As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations."

https://fedorahosted.org/fesco/ticket/1022 <--- feature was accepted with no indication that biosdevname should remain the default

Let's damn well do something about it, already.

I propose two options, one really simple, one pretty simple.

1) Just drop biosdevname from comps, anaconda and (if necessary) dracut. The systemd mechanism will be the default. Advantage: simplest and most straightforward. Disadvantage: Anyone still wanting to use biosdevname on new installs will need to reconfigure manually post-install. Boo hoo.

2) Adjust biosdevname's udev rule so it's a dead letter unless 'biosdevname=1' is explicitly passed. Then it can remain in anaconda, dracut and the default install, but won't be used unless the user passes that command line parameter. Advantage: preserves the ability for the user to choose to use biosdevname. Disadvantage: somewhat more difficult to understand and document what's going on.

2) is actually a one-liner, in fact, a two-character-er: we just uncomment one line in the udev rule.

# uncomment the next line for biosdevname to be off by default
# GOTO="netdevicename_end"

becomes

# uncomment the next line for biosdevname to be off by default
GOTO="netdevicename_end"

with that change, I believe the biosdevname rule would never do anything unless 'biosdevname=1' was on the cmdline (it doesn't look like we ship anything else that sets ENV{UDEV_BIOSDEVNAME}). This is basically the change Bill proposed originally, only even simpler, it doesn't bother special-casing live/install modes. Since http://bugzilla.redhat.com/show_bug.cgi?id=1023609 , anaconda passes the 'biosdevname' cmdline parameter through to the installed system, so if you install with 'biosdevname=1', that would get passed through and things should work.

I honestly still prefer 1), just because then it's very simple and clear what's going on. No-one but Dell actually seems to like biosdevname any more, so far as I can tell. Having two of these things around is just getting silly, I'd really like it if we could just *ditch* one. But 2) is okay if we really, really want to still allow biosdevname usage.

and if there is some kind of issue with NetworkManager, let's deal with that *separately*, after fixing this.

(In reply to Adam Williamson from comment #76)
> 1) Just drop biosdevname from comps, anaconda and (if necessary) dracut. The
> systemd mechanism will be the default. Advantage: simplest and most
> straightforward. Disadvantage: Anyone still wanting to use biosdevname on
> new installs will need to reconfigure manually post-install. Boo hoo.

+1

(In reply to Adam Williamson from comment #76)
[...]

> 2) Adjust biosdevname's udev rule so it's a dead letter unless
> 'biosdevname=1' is explicitly passed. Then it can remain in anaconda, dracut
> and the default install, but won't be used unless the user passes that
> command line parameter. Advantage: preserves the ability for the user to
> choose to use biosdevname. Disadvantage: somewhat more difficult to
> understand and document what's going on.
> 

+1

[...]
> I honestly still prefer 1), just because then it's very simple and clear
> what's going on. No-one but Dell actually seems to like biosdevname any
> more, so far as I can tell. Having two of these things around is just
> getting silly, I'd really like it if we could just *ditch* one. But 2) is
> okay if we really, really want to still allow biosdevname usage.

I think it will be useful to provide an option to users who want to use biosdevname. Biosdevname provides meaningful names to interfaces based on the location of the interfaces on the system motherboard. Some of the features that biosdevname provides are

1. Naming multiport adapters

p2p1 p2p2 p2p3 p2p4

2. Naming network interfaces from NIC Partitions 

p2p1_1 --- pci slot 2 port 1 NIC partition 1
p2p2_2 --- pci slot 2 port 1 NIC partition 2

3. Naming network interfaces from SRIOV VFs

p3p1_0 --- pci slot 3 port 1 SRIOV VF instance 0
p3p1_1 --- pci slot 3 port 1 SRIOV VF instance 1

Having an option to enable biosdevname will provide a way for users who want the above features to use biosdevname till the time when systemd could provide these features.

Except those meaningful names don't stay the same from boot to boot with some hardware.  So they're not really meaningful, they're random.  

Imagine having a system in the field.  Maybe it's in the middle of nowhere acting as a firewall, or maybe running a SCADA system and controlling a nuclear power plant.  Or maybe it's a virtualization host and a bunch of virtual machines depend on it.  

Shut down the machine, boot it back up again, and now the NICs have different names.  Imagine the chaos and confusion.  Reconcile the NIC names, boot it again, and the NIC names change yet again!  Well - sometimes they change, sometimes they don't.  

We can argue the BIOS people do not follow the standard and that's why the NIC names change.  Maybe that argument is true, but it's also irrelevant.  If I can't count on biosdevname NICs always keeping the same names, I can't use it.   

If I get a vote from the field, I'd vote for Adam's choice #1.  Just remove it from installations so there's no chance it can get in the way and mess up a system.  

Also, for what it's worth, I just installed the RHEL 7 RC on one of my little hardware boxes.  It uses kernel enp names and not biosdevname names.

- Greg

Greg: in RHEL7 biosdevname is used on Dell boxes, and udev's namingscheme on everything else.

From working on both biosdevname (for RHEL) and udev's naming feature (upstream) I can only recomend gonig with Adam's first suggestion and drop biosdevname as soon as possible. The overlap of features is confusing and udev's implementation is a lot more robust.

The problem with biosdevname is: it enumerates interfaces sometimes. So it makes a not persistent enumeration over the present HW state.

(In reply to Harald Hoyer from comment #82)
> The problem with biosdevname is: it enumerates interfaces sometimes. So it
> makes a not persistent enumeration over the present HW state.

In less friendly words:

biosdevname invents its own numbers, based in the over-all system state. It
divides the one global ethX namespace into several smaller ones, which makes
the random name re-shuffling less likely, but it has the same basic conceptual problem: it derives the number for one device by counting over several other
devices in the system. As soon as this system state changes, unrelated names
might change too.

This makes bisdevname not useful, it is broken by design, and that design
cannot really be fixed. It should just no longer be used.

removed it from comps:
https://git.fedorahosted.org/cgit/comps.git/commit/?id=c1d40aae68d5b4d5ec170a82d02ef9a2daf7264d

I added a note for this change to the F21 Network release notes beat at https://fedoraproject.org/wiki/Documentation_Networking_Beat . Adding 'Documentation' keyword to make sure the real docs folks are aware.

*** Bug 929300 has been marked as a duplicate of this bug. ***