On first boot after an install from a gnome live iso, sometimes drakx-finish-install cannot access the network. It looks like a conflict between drakxnet and networkmanager. Result is that the online media is not added. Reproducible: Steps to Reproduce:
CC: (none) => tmb
When the network does work, the user is not given an option to configure the network, so they cannot set the hostname.
Whiteboard: (none) => 4alpha1
Created attachment 4237 [details] Output of journalctl -ab, from the first boot after install.
Colin, I think this can be a fallout of the dropped interface renaming, that drakx tools maybe does not cope with nicely yet... the times it work I assume networkmanager got to the hw control first
CC: (none) => mageia
(In reply to Thomas Backlund from comment #3) > Colin, > > I think this can be a fallout of the dropped interface renaming, that drakx > tools maybe does not cope with nicely yet... > > > the times it work I assume networkmanager got to the hw control first So this but is more in drakx-net, then? Without networkmanager, with the new alpha 1 KDE Live DVD, it is impossible to get a WLAN connection (I did not try LAN)
CC: (none) => mageia, marja11, pablo, thierry.vignaud
s/but/bug/
Thomas, well the interface renamed is not dropped as such. udev can still do the renaming quite happily when no other interface with the same name exists. The bit that was dropped was the racey stuff that attempted to detect rename clashes etc. e.g. try to rename eth0 to eth1, when eth1 already exists and even when renaming eth1 out the way first, some other kernel device might pop up and claim it before we can rename our eth0 to that name! But renaming code still exists for "normal" renames. Dave, do you have any /etc/udev/rules.d/ content after the install? Perhaps the installer is using the udev rules generators that have been removed? I don't think so, but worth checking.
That said, perhaps the rules to generate our default configs are firing on the first name (kernel assigned) and not the 2nd name (what udev decides) and not writing the config file properly with the NM_CONTROLLED=no bit in the config.
The tests I've been running so far have all been clean installs. After the install, /etc/udev/rules.d/ is empty.
Cool, can you also check if you have files in /etc/sysconfig/network-scripts/ifcfg-* relating to the "old" eth* names or just the newer style names. I suspect that some kind of race exists somewhere but not quite sure which bit happens first. It might not be obvious from the files in here what's going on either as we may need to catch it in the act on first boot to really know where the problem lies.
Just ifcfg-enp0s3 and ifcfg-lo.
Are you sure that it's not just shorewall blocking the interface it doesn't know about? Is enp0s3 listed in /etc/shorewall/interfaces?
Yes, it's listed in /etc/shorewall/interfaces.
CC: (none) => eeeemail
Created attachment 4394 [details] Output of journalctl -ab|grep -e Network -e finish -e ifplug As shown in this log, I configured the network during first boot after install from the 2nd build of the gnome live cd, right after finish-install runs the ifup enp0s3, NetworkManager is deactivating device, which is preventing the adding of online repos. This was in a vb guest.
Whiteboard: 4alpha1 => 4alpha3
Created attachment 4395 [details] Output journalctl -ab|grep -e Network -e finish -e ifplug Here's the output from the same command on an install using the kde4 live x86_64 live dvd, where the network was properly started, and the online media added. This install is on real hardware.
Incidentally, finish-install writing the hostname to /etc/hosts is redundant these days... nss_myhostname is always available.
Sometimes this is also caused by the modem: my test laptop sometimes does not get connected via the eth0 cable, though nothing is wrong. Resetting the modem (which connects all computers in the house to the net) fixes the problem then
In my case, I have a router in between my two computers and the dsl modem. The other computer's network activity continues, and I can get the network working by using mcc to delete the interface configuration and then using mcc to recreate the nic configuration.
Did this continue to be an issue for the final release?
Closing as OLD since there was no answer to the last comment. Please reopen if still valid.
Status: NEW => RESOLVEDResolution: (none) => OLD