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:
Blocks: (none) => 11704Whiteboard: (none) => 4RC
Please ask for /root/drakx content if needed.
Blocks: (none) => 11979
Please attach it
Source RPM: (none) => drakx-netKeywords: (none) => NEEDINFOCC: (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.
Blocks: (none) => 14069
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) => remiBlocks: 14069 => 15527
Blocks: (none) => 15637
Whiteboard: 4RC => 4RC FOR_ERRATA
Copied the errata entry from Mageia 4 to 5 https://wiki.mageia.org/en/Mageia_5_Errata#Network_interfaces_naming
CC: (none) => yves.brungard_mageiaWhiteboard: 4RC FOR_ERRATA => 4RC IN_ERRATA
Target Milestone: --- => Mageia 6
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 => RESOLVEDCC: (none) => marja11Resolution: (none) => OLD
Blocks: 15527 => (none)