4beta1 DVD 64 (1st Build) default kde installation During installation, at the summary stage, wired network shows as Not Configured Noticed also with all live isos also where wired network had to be manually connected. Reproducible: Steps to Reproduce:
Assigned to Colin as I suspect it has to do with the interface renaming. I'll attach report.bug when it's finished
CC: (none) => davidwhodgins, ennael1, thierry.vignaud, tmbWhiteboard: (none) => 4beta1
Created attachment 4472 [details] report.bug.xz
Created attachment 4473 [details] journal.txt from first boot
Created attachment 4478 [details] Results of ifup enp0s3 command As shown, stage 2 is failing to start the network, due to the arping failing. On the Mageia 3 host, /sbin/arping -q -c 2 -w 3 -D -I eth0 192.168.10.115 returns with no output.
Note that for comment 4, this is using the Mon Nov 4 23:00:27 CET 2013 i586 dvd, under vb, with the wired connection set to using bridged networking in the guest configuration settings.
Under the installed system, network is not starting on boot. systemctl -a enable network.service network.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig network on After that, it is starting on boot. I'm surprised it's using a sysvinit script, instead of a systemd service.
Yes using 2nd build, 64 bits dvd I notice in summary -> services that the services network network-up and resolvconf are not selected by default, which I think should always be activated by default.
CC: (none) => dvgevers
(In reply to Dave Hodgins from comment #6) > I'm surprised it's using a sysvinit script, instead of a systemd service. This is pretty much the only job the initscripts package has left - bringing up static network. Obviously network manager does some of that job too. We'll likely stick with the initscripts network setup for a while yet. Perhaps for mga5 we can switch to the newer stuff which is being worked on as we speak by the CoreOS guys. This should allow us to replace initscripts completely I think... (still that's very much speculation!) I'll take a closer look as soon as I can.
1) I've noticed for a while that if you ESC out of graphical boot, systemd is giving an error about failing to bring up network.service, although the wired network is started fine by the time you log in. Haven't pursued this yet. 2) IIRC the install summary has always displayed the wired interface as unconfigured even if you had been using it to do a network install. This made some sense because it was only configured to the extent that stage1 configured it for the install, which doesn't give the user all of the drakconnect options.
CC: (none) => ftg
(In reply to Frank Griffin from comment #9) > 1) I've noticed for a while that if you ESC out of graphical boot, systemd > is giving an error about failing to bring up network.service, although the > wired network is started fine by the time you log in. Haven't pursued this > yet. Yeah I think this is our old friend NetworkManager integration... I'll take another look if we merge the latest initscripts... or even if we don't. It's certainly a bit odd to give an error when it's handled by NM. > 2) IIRC the install summary has always displayed the wired interface as > unconfigured even if you had been using it to do a network install. This > made some sense because it was only configured to the extent that stage1 > configured it for the install, which doesn't give the user all of the > drakconnect options. So this isn't new and somewhat expected? Not sure about the requirement of enabling network service tho'. Ahh, seems initscripts %post was converted to a %posttrans and the comparing of $1 broke the bits that are needed to enable it... This was a change done recently to break ordering cycles, but it seems the checking of $1 wasn't noticed (I think I mentioned it as a warning in the email discussing it). It should be converted back to a %post (at least partially).
initscripts-9.41-19.mga4 reverted back to %post to fix this
(In reply to Colin Guthrie from comment #10) > > So this isn't new and somewhat expected? Not sure about the requirement of > enabling network service tho'. > Note that all of my installs are network installs from a local cauldron mirror using wired ethernet. So what I see may not be representative of what people using the ISOs see, or would expect to see.
This is actually new, hence the bug report.
Not fixed in classic installations. Wired network still shows as 'not configured' at the summary stage and configuring it there fails the connectivity test with 'A problem occurred'. Live isos now connect ok.
Installations from the classic isos connect OK, just network in the installer which is the problem.
what for ? connectivity test ? (we have alredy bugs for that)
At Summary stage of installation from classic isos. Where wired would previously work OOTB (nework::ethernet::whatever or similar) it now shows in red as 'not configured'. When it is manually configured there it then fails the connectivity test with 'A problem occurred'
Created attachment 4491 [details] List of modules not loaded in stage 2, that are loaded in running system. The attached list of modules are those loaded in the running system, where networking and usb stick mounting are working, that are not being loaded in stage 2, where both are failing.
related to https://bugs.mageia.org/show_bug.cgi?id=11600 certainly It's a dup then (stage2 not being able to load modules with new stage1)
Still valid with Mageia-4-beta1-i586-DVD]$ cat DATE.txt Wed Nov 6 23:16:10 CET 2013
At summary of installation of 4beta2 (3rd prerelease round, 64 bits) the wired network is not configured.
CC: dvgevers => (none)Hardware: i586 => AllWhiteboard: 4beta1 => 4beta2
Then it's not bug #11504 (which could have been another possible convict)
Colin, Thierry, any idea on that one? It still happens in beta2 isos
Applicable to 32 bit 4RC (classical iso, 1st prerelease round)
Whiteboard: 4beta2 => 4RC
Priority: Normal => release_blockerBlocks: (none) => 11704
Blocks: (none) => 11954
OK, so I've been looking at this one with latest RC ISOs. It's due to a missing /etc/sysconig/network-scripts/ifcfg-xxxx file. Creating one manually at the monitor selection screen (before the summary) allows it to show up as configured on the summary screen and the network is brought up and updates are installed correctly (the switch to GTK3 + Mutter means he GUI still needs some love I'm afraid) So the only thing missing is whatever writes the config. Now, udev should do this when it's installed due to 81-net.rules, but this is not installed in the stage2 and in fact we cannot rely on this in the installer anyway - it's something we should be doing manually in the installer somewhere before the summary stage. Will keep digging!
OK, so there is some code that reads /tmp/network and /tmp/ifcfg-* files when stage2 initialises. Perhaps this is the root cause. These files no longer exist and thus the device is not configured - i.e. it was always stage1's job to write these in the past and now that we use dracut it doesn't work that way? I'm not 100% of this analysis because this bug was opened only two days after my dracut commits which makes me thing it pre-dates the dracut change... I'll keep digging.
OK, problem found. If I boot the lastest ISO with: linux rd.break=pre-pivot Then go into /tmp and do: echo "NETWORKING=yes" >network echo "DEVICE=enp0s3 BOOTPROTO=dhcp ONBOOT=yes" >ifcfig-enp0s3 (where my device is called enp0s3) Then I type exit (twice IIRC) and the installer kicks in as normal. With these two files in place, the device is properly marked as configured when we get to the summary screen, updates are installed properly, and after installing, my desktop is properly working and network is up (in GNOME, NM is installed and it uses the device properly). So I think the fix is basically just to make the dracut mgainstaller module write these files from udev rules. Should be pretty trivial to do and it should resolve this bug! Will work on that now.
Status: NEW => ASSIGNED
(I meant ifcfg-enp0s3 in the above comment... I typoed an extra "i" in there)
Well done colin, sounds like a simple fix!
OK, so looking at the code in mdk-stage1/network.c the only time it writes those files is when it genuinely initialises the network. Booting from boot.iso still does this, and writes those files and thus completes with the network configured. No idea about live ISOs. So ultimately, I'm currently a little confused as to why this is any different as to what came before? Did this used to work on MGA3? (I'll download an ISO and do a test shortly to confirm but if someone knows....) It would be quite trivial to add a default network file and ifcfg-xxx file (which can then get overwritten by the stage1 stuff with real details) and thus even ISOs will kick off with a default config that works and updates can be applied without manual configuration. Note that currently, doing a manual configuration worked fine for me also and updates were applied. Have I misinterpreted this bug in anyway or is my analysis/suggestion in this and the last comment correct?
OK, it seems to show up fine in an MGA3 ISO install and shows as configured. So something has changed in the code. Indeed there are no /tmp/* files from stage1 so it must be in the drakx code somewhere... I'll look further.
Looking at MGA3 ISO, the ifcfg-* file is created after package installation but before bootloader preparation.
commit 500719ec13c52d494b6e17067e81243be83b76f8 Author: Colin Guthrie <colin@...> Date: Sun Jan 5 19:33:43 2014 +0000 Nuke the use of /etc/iftab (it's no longer useful) mga#11592 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=500719ec13c52d494b6e17067e81243be83b76f8
commit 8859bff312e8b6064b6f1a20f8c5a647bf5e5d2b Author: Colin Guthrie <colin@...> Date: Sun Jan 5 19:35:38 2014 +0000 Nuke the use of udev rules for network device names Persistent device names make it no longer relevant. mga#11592 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=8859bff312e8b6064b6f1a20f8c5a647bf5e5d2b
commit 21c4a89f2b05625e362d7ff78a7fb2b1d4a9302a Author: Colin Guthrie <colin@...> Date: Sun Jan 5 19:56:50 2014 +0000 Nuke an ethN regexp that prevents network coming up in installer mga#11592 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=21c4a89f2b05625e362d7ff78a7fb2b1d4a9302a
Thierry, can you check my perl on the above commits (particularly the last one - not sure if $_ is properly populated after removing the /eth[0-9]/ bit) and if all is well, spin a new drakx-net? This *should* resolve the bug (the last commit is the most important). I checked the /etc/iftab thing and couldn't find any use of it anywhere and don't know of any third party utils that use it any more either.
This is OK. $_ automatically got the value of each element of @all_dev, one by one
Great, thanks for that Thierry! Hopefully the next round of ISOs will solve this bug thanks to your stage2 submission. Can't test it with the boot.iso+net install as the /tmp/network + /tmp/ifcg-* files mean that it's configured OK. I'll do more tests when the next ISOs are available :)
Note that I replied to your commit the following: Blino did explicitely a match: http://gitweb.mageia.org/software/drakx/commit/?id=332d925103bf25a304bc17c84f68dc90e93f5514 Instead of whitelisting eth devices (which does not work with new persistent device names), we may want to blacklist some devices instead (ppp, isdn, ...).
Hmm, yeah a backlist seems like a good idea.
Fixed here, thanks! Ok for everyone ?
Closing then
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED