Description of problem: The very first 'dnf update' after a Fedora 26 install kills the network connection. After re-establishing networking manually, the next dnf update succeeds. Version-Release number of selected component (if applicable): For my own tests, from a Fedora-WS-Live-26-1-5 fresh install. Not sure about the install from Epitech. How reproducible: Always (5 out of 5) Steps to Reproduce: 1. Install Fedora 26 with default options from Fedora 26 live 1-5 2. After install, login in the installation 3. Run 'sudo dnf update' Actual results: The 'dnf update' starts normally, then is interrupted with an error message indicating that some packages are still in the cache and how you can clean the cache. At that stage, network connection has been lost (I tested by running a browser and attempting to load web pages). Expected results: dnf update should complete and, if it needs to touch the network, should be able to stop and restart it without interrupting its own update process. Additional info: I have seen this 5 times so far: - The first time in VMware Fusion 8.5, one case where I could not restart the network either by connecting / disconnecting from the VM UI or restarting the network in the guest. The network appears as wired Ethernet, and lspci gives me "02:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)" - The second and third time in KVM guests running on Fedora 26 hosts. - The fourth time on a Fedora 26 clean install on a Lenovo 470p test laptop. There, the network was Wi-Fi, and just going to the system settings and reactivating the network was sufficient to resume the dnf update successfully. - The fifth time on my son's Lenovo 470s laptop, where the base Fedora 26 had been installed by his school, Epitech. Same symptoms as on mine. One thing that is specific to the network environment where I did all these tests is that I run my own DNS and DHCP servers from a Raspberry Pi, so that DHCP requests automatically give me DNS names. I have not yet tested if the problem reproduces outside of my home network.
We don't believe DNF can cause network disconnect. Could you debug more and check if some other software isn't causing this?
Tried a couple more times, and this time I did not reproduce. Will still try a couple more times. But there may be something more to this than mere dnf.
I have tried to reproduce a couple more times from an ISO image stored on an NFS server, and that never failed. It did fail again when I booted from a USB key, so I ran the integrity check on that key, and the check failed. I had run the test once the first time I used the key, but not lately. So for now, I would close the bug and attribute that to a bad installation medium.
Ok, lets close it.