If you do a fresh install on a wired host and configure networking in the Summary step, the installer creates an interface called "eth0". When you boot the new system, the wired interface is now "enp2s0". The eth0 configuration, while still there, isn't used because no match can be found for eth0, and the configuration for enp2s0 is whatever harddrake chose. No user is going to find this intuitive or understandable. It's just going to look like whatever customization he did during install got thrown away. I assume the kernel drivers are setting the new names, so I'm not sure why the install kernel isn't setting the same ones. Incidentally, the naming change is probably going to play hell with VBox users who set their virtual network interfaces to "bridged", since VBox records the real-machine interface name to which the virtual one is connected. Reproducible: Steps to Reproduce:
CC: (none) => mageia, mageiaSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=10947Assignee: bugsquad => thierry.vignaud
*** Bug 11192 has been marked as a duplicate of this bug. ***
CC: (none) => junk_no_spam
Hardware: i586 => All
Whiteboard: (none) => 4alpha2CC: (none) => davidwhodgins
Same problem here: - System install creates an eth0 interface, which it tests and issues the "Felicitations..." message - which evidently works - After boot, I have no network connection. The system wants to use an eno1 interface that cannot be made to connect, Drakconnect (setup a new network interface) offers eno1, but no eth0. Drakconnect (remove a network connection) offers to delete eno1 and eth0). If I delete eth0, I can than newly configure eno1 and make it work - a work around. I did not manage the other way round (deleting eno1) since eth0 does still not show up in set up a new network connnection. I think the priority and severity should be raised: for a couple of weeks this has been a total show-stopper for me, until I found this workaround.
CC: (none) => juergen.harms
CC: (none) => ennael1, tmbSeverity: normal => criticalPriority: Normal => release_blocker
CC: (none) => wilcal.int
I am now experiencing this error on one of my platforms, not in Vbox and my Dell 64-bit laptop connects to the wired network just fine with M4A3.
My reported bug: https://bugs.mageia.org/show_bug.cgi?id=11309 is probably a dup of this one.
OK, so latest news just to keep this bug updated. Installer was missing a udev rule needed to calculate the new names. Sadly, because of the way our network-based stage1 works, the network might be up already by the time udev starts in stage2 which prevents the network device rename. The solution is to move udev into stage1, which may mean rebasing it on dracut rather than our custom init and networking scripts. A good solution here is to use dracut to generate stage1, so we will be looking into this next.
fixed http://gitweb.mageia.org/software/drakx/commit/?id=00c8fea70d10e3738b70d9eeb2cc9413bdf58eaf ?
And stage1 is now somewhat udev aware.
(In reply to Manuel Hiebel from comment #6) > fixed > http://gitweb.mageia.org/software/drakx/commit/ > ?id=00c8fea70d10e3738b70d9eeb2cc9413bdf58eaf ? Well, I would say almost there. Still left a ifcfg-wan0 :( on my clean install of Mageia-4-beta1-x86_64-DVD.iso -rw-r--r-- 1 root root 70 Nov 15 16:54 ifcfg-enp3s0 -rwxr-xr-x 1 root root 276 Nov 15 16:54 ifcfg-enp4s0 -rwxr-xr-x 1 root root 254 Nov 5 06:14 ifcfg-lo -rwxr-xr-x 1 root root 38 Nov 15 16:41 ifcfg-wlan0 -rw-r--r-- 1 root root 40 Nov 15 16:11 ifcfg-wlp2s0
CC: (none) => junknospam
(In reply to Manuel Hiebel from comment #6) > fixed > http://gitweb.mageia.org/software/drakx/commit/ > ?id=00c8fea70d10e3738b70d9eeb2cc9413bdf58eaf ? FWIW, no, this didn't fix it. It has to be done in stage1 for net installs at least which as, Thierry pointed out now happens. Dunno where the ifcfg-wlan0 comes from tho'. I suspect the presence of such a config file shouldn't be used as a fully indicative as to whether or not the problem is solved tho'. But rather what the interface is currently called and what values the installer injected into config files.
There is a related issue: Installing Mageia4 Beta1, Configuring the "personal firewall". At the end comes the question on which interface to apply the rules just requested. There are now 2 checkboxes being proposed: one for "eno1" (comes up unchecked), one for "Ethernet+" (comes up checked). Either that also needs to be fixed, or the user must get some info explaining this incomprehensible choice. Not dramatic, but an unexperienced user is rather nervous at this stage of an installation.
(In reply to Colin Guthrie from comment #9) > Dunno where the ifcfg-wlan0 comes from tho'. My WAG would be the application that is executed when you see the message "Checking for new hardware"
(In reply to Bit Twister from comment #11) > (In reply to Colin Guthrie from comment #9) > > Dunno where the ifcfg-wlan0 comes from tho'. > > My WAG would be the application that is executed when you see the message > "Checking for new hardware" Oops, since the date/time were the same for ifcfg-wlan* it has to be in the installer. I deleted ifcfg-wlan0, rebooted and it was not re-created. I did run a diff before deletion and they were identical.
Assignee: thierry.vignaud => mageia
I think this is fixed now in recent builds right?
(In reply to Colin Guthrie from comment #13) > I think this is fixed now in recent builds right? Yep, an install yesterday uses the new interface names from stage 1 on, thanks !
Status: NEW => RESOLVEDResolution: (none) => FIXED