Bug 12316

Please ask for /root/drakx content if needed.

Please attach it

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

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?

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.

(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 :-)

(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.

So guys anything we can do for Mageia 5?

CC: (none) => ennael1

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

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

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

That's not urpmi, that's systemd/udevd

(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.

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.

Ping

CC: (none) => nic

Unclear to me who you are pinging or what about.
Actually, to me, unclear why NEEDINFO should apply...

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?

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)

(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" :)

Is that bug still relevant after several releases in the new naming world???

(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