Bug 12316 - Install/upgrade does inconsistent network interface naming.
Summary: Install/upgrade does inconsistent network interface naming.
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 6
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard: 4RC IN_ERRATA
Keywords:
Depends on:
Blocks: 11704 11979 15637
  Show dependency treegraph
 
Reported: 2014-01-15 18:02 CET by Dick Gevers
Modified: 2017-01-17 10:29 CET (History)
8 users (show)

See Also:
Source RPM: drakx-net
CVE:
Status comment:


Attachments
report.bug from upgrade (213.89 KB, application/octet-stream)
2014-01-16 16:56 CET, Dick Gevers
Details

Description Dick Gevers 2014-01-15 18:02:53 CET
Description of problem:

Install 4RC and I have interfaces enp5s0f0 and wlp4s0 for ethernet card and wifi.

When doing an upgrade from M3.1 to 4RC this does not work in the same manner:

During install (upgrade) of 4RC:

Summary -> Firewall asks which interfaces should be protected and offers "eth0" from M3, as well as "enp5s0f0" as separate option, but this is obviously the new name of the same interface and it gives "wlan0" for which it does not offer a modern name (it does create it in install, apparently not in upgrade).


After finishing install and rebooting ifconfig shows not enp5s0f0, only eth0, but /etc/shorewall/interfaces lists both.

But /etc/shorewall6/interfaces only shows eth0, not enp5s0f0

Neither has the modern equivalent for wlan0, only the old form.


IMHO when upgrading it should show only new style names, or keep old style names and not offer new ones, and do so consistently for network scripts as well as packages shorewall and shorewall-ipv6.

https://bugs.mageia.org/show_bug.cgi?id=11928 may be somewhat related, but I suspect it best to treat this separately.



Reproducible: 

Steps to Reproduce:
Dick Gevers 2014-01-15 18:04:15 CET

Blocks: (none) => 11704
Whiteboard: (none) => 4RC

Comment 1 Dick Gevers 2014-01-15 18:07:54 CET
Please ask for /root/drakx content if needed.
claire robinson 2014-01-15 18:10:27 CET

Blocks: (none) => 11979

Comment 2 Thierry Vignaud 2014-01-16 06:33:46 CET
Please attach it

Source RPM: (none) => drakx-net
Keywords: (none) => NEEDINFO
CC: (none) => mageia, thierry.vignaud

Comment 3 Colin Guthrie 2014-01-16 10:07:30 CET
This is kinda a problem generally to be honest.

If you use the DVD, you're booting into an environment that uses the new names (unless you you pass net.ifnames=0 on the kernel).

This casues the installer to use new names.

BUT, the decision was taken (arguably rightly so) to stick with the old names for upgrades.

Sadly, we simply don't know what setup is best until it's too late. We cannot look at a users system (and thus find which naming scheme they use) until it's too late and we've already initialised our network.

Really the installer would have to gain some remapping tools to remap the interface names to get this correct (it's feasible but probably quite some work to pin down where it's needed and get it working)


Note that this problem existed before the device renaming anyway. If a system has multiple interfaces eth0 and eth1, it's totally possible that the installer would detect these in a different order to the system being upgraded and write the incorrect interface names to various config files. The best way to fix this is to use a scheme that will result in predictable names without any config which is what we're now doing.

Regarding the data written to shorewall, is it harmless or did it cause active problems? Your system after upgrade should be using interfaces called eth* right?
Comment 4 Dick Gevers 2014-01-16 16:56:24 CET
Created attachment 4801 [details]
report.bug from upgrade

@tv per #c2: report.bug.xz attached

@coling per #c3: I did not experience problems, because the upgraded system was upgraded as test only and used maybe 15 minutes only. Cannot say what problem might appear later (in theory or otherwise).
The said boot was using interface eth0 yes, but I see there was also written a file /etc/sysconfig/network-scripts/ifcfg-enp5s0f0 in addition to an already existing file /etc/sysconfig/network-scripts/ifcfg-eth0

But I am not competent to predict whether or not this might create any undesirable effect in future use.
Comment 5 Thierry Vignaud 2014-01-16 17:52:02 CET
(In reply to Colin Guthrie from comment #3)
> Really the installer would have to gain some remapping tools to remap the
> interface names to get this correct (it's feasible but probably quite some
> work to pin down where it's needed and get it working)

Well initscripts used to rename interfaces depending on HWADDR in ifcfg-foobar.
Also we'd /etc/iftab that you just droped a week ago :-)
Comment 6 Colin Guthrie 2014-01-16 17:59:48 CET
(In reply to Thierry Vignaud from comment #5)
> (In reply to Colin Guthrie from comment #3)
> > Really the installer would have to gain some remapping tools to remap the
> > interface names to get this correct (it's feasible but probably quite some
> > work to pin down where it's needed and get it working)
> 
> Well initscripts used to rename interfaces depending on HWADDR in
> ifcfg-foobar.
> Also we'd /etc/iftab that you just droped a week ago :-)

:p

That's not really the problem tho'. Renaming interfaces is still totally supported and can be done in udev rules. It's *strongly* recommended to not rename to something eth* based tho', e.g. at home my interfaces are called "lan", "wan" and "wifi" in my server! This avoids name clashes with the kernel assigned names of other cards (e.g. maybe I get an eth0 device from the kernel, and my udev rule says to rename it to eth1. But as I'm just about to process the rename, the kernel allocates eth1 to some other device it's just initialised - boom conflict!)

The problem here is that if you have renaming (regardless of how it's specified - udev or initscripts) configured in your MGA3 machine, then use the *installer* via a DVD to do an upgrade, it pick up on the renames specified by the installed system. This is not new but with a stark change this time to predictable names, it's a little more apparent. Going forward, having predicable names is a win for this kind of situation, tho' the underlying problem will *always* be there if the user has custom udev rules doing some renaming and uses the installer to upgrade.
claire robinson 2014-09-08 17:32:52 CEST

Blocks: (none) => 14069

Comment 7 Anne Nicolas 2015-02-21 15:48:14 CET
So guys anything we can do for Mageia 5?

CC: (none) => ennael1

Comment 8 Rémi Verschelde 2015-03-21 00:15:14 CET
Moving to the Mageia 6 tracker, no activity on this bug for more than one year, it's probably not the worst release blocker for Mageia 5 right now.

CC: (none) => remi
Blocks: 14069 => 15527

Marja Van Waes 2015-04-06 22:58:58 CEST

Blocks: (none) => 15637

Samuel Verschelde 2015-05-21 12:47:02 CEST

Whiteboard: 4RC => 4RC FOR_ERRATA

Comment 9 papoteur 2015-05-31 17:16:21 CEST
Copied the errata entry from Mageia 4 to 5
https://wiki.mageia.org/en/Mageia_5_Errata#Network_interfaces_naming

CC: (none) => yves.brungard_mageia
Whiteboard: 4RC FOR_ERRATA => 4RC IN_ERRATA

Samuel Verschelde 2015-06-02 10:06:14 CEST

Target Milestone: --- => Mageia 6

Comment 10 Luca Olivetti 2015-06-22 11:12:04 CEST
FYI, I just upgraded a server from mga4 to mga5 using urpmi and it changed the interface name from eth0 to ens160 (thus borking the network, firewall, etc.)

CC: (none) => luca

Comment 11 Thierry Vignaud 2015-06-22 11:48:34 CEST
That's not urpmi, that's systemd/udevd
Comment 12 Samuel Verschelde 2015-06-22 12:40:03 CEST
(In reply to Luca Olivetti from comment #10)
> FYI, I just upgraded a server from mga4 to mga5 using urpmi and it changed
> the interface name from eth0 to ens160 (thus borking the network, firewall,
> etc.)

Updated Errata with "Note: at least one user reported that after upgrading via urpmi or the blue "upgrade" icon in the system tray, their eth0 interface was renamed permanently to a name using the new scheme." 

Feel free to edit.
Comment 13 Luca Olivetti 2015-06-22 15:18:33 CEST
But will be the new name stable or will it change randomly again depending on the mood of the systemd/udev/whatever developers?
For the time being I put the HWADDR in /etc/sysconfig/network-scripts/ifcfg-eth0 so the name stays eth0 (and I'll do that on the other servers I'm going to upgrade), but I worry that even that will fail somewhere down the line.
Comment 14 Nic Baxter 2016-01-04 06:02:50 CET
Ping

CC: (none) => nic

Comment 15 Dick Gevers 2016-01-04 10:15:55 CET
Unclear to me who you are pinging or what about.
Actually, to me, unclear why NEEDINFO should apply...
Comment 16 Nic Baxter 2016-01-04 10:40:30 CET
I have been working my way through NEEDINFO bugs that have not seen any action in a while. I was not sure what to do about this one so I sent a ping to provoke a reply. Would another approach been better?
Comment 17 Dick Gevers 2016-01-04 11:08:43 CET
Looking more closely, I see tv applied the keyword with c#2
so I should have removed it with c#4 ... my bad!

Keywords: NEEDINFO => (none)

Comment 18 Samuel Verschelde 2016-01-07 11:07:00 CET
(In reply to Nic Baxter from comment #16)
> I have been working my way through NEEDINFO bugs that have not seen any
> action in a while. I was not sure what to do about this one so I sent a ping
> to provoke a reply. Would another approach been better?

Yes, a full sentence is always better than a simple "ping" :)
Comment 19 Thierry Vignaud 2016-07-11 18:53:53 CEST
Is that bug still relevant after several releases in the new naming world???
Comment 20 Marja Van Waes 2016-07-12 17:07:20 CEST
(In reply to Thierry Vignaud from comment #19)
> Is that bug still relevant after several releases in the new naming world???

I doubt it. There is or was a new issue with wlan*/wlp* and eth*/enp*, but that's unrelated to this one.

Status: NEW => RESOLVED
CC: (none) => marja11
Resolution: (none) => OLD

Samuel Verschelde 2017-01-17 10:29:39 CET

Blocks: 15527 => (none)


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