Created attachment 1647848 [details] lsmod output following boot (no working/configured networking) N.B. I haven't been able to sufficiently understand the cause of the problem, so this may be filed against the wrong component. Starting at the kernel but may need moving up the stack. Advice welcome. Description: Desktop machine is a Dell with a wired network socket, realtek chipset. This worked fine under Fedora 30 and many previous versions of Fedora, configured via Gnome system settings/NetworkManager. The kernel module for the nic is r8169. After upgrade to Fedora 31 the network interface does not appear as available within NetworkManager. However, if I: # rmmod r8169 && modprobe r8169 then the nic is automatically detected by NetworkManager, configured, and everything works. As a temporary workaround I've added a systemd service and timer which runs the rmmod then modprobe 20 seconds after startup; this hack makes the machine usable again. Investigation (inconclusive): I'm unclear whether this is kernel or systemd issue, or something else. I've checked a few things but am now stumped as to what/where to look. Comparing an lsmod immediately after boot (no configured/working networking) and after the module load (network works) reveals no significant difference, only a one-higher reference count for the radeon module. I'm attaching the outputs of these lsmod commands. Comparing the output of "ip a" before and after module reload shows a difference in available devices: enp4s0 before module reload but not after; and p5p1 only after reload. p5p1 is the device NetworkManager can see and then configures. I'll attaching the output of the "ip a" command below as well. I've found some previous reports/bugs: - https://ask.fedoraproject.org/t/fedora-31-realtek-ethernet/4577 looks like the same problem from the description provided. No solution provided, but potentially provides a second independent report of the problem. - https://ask.fedoraproject.org/t/wired-connection-realtek-rtl8111-8168-8411-returns-activation-of-network-connection-failed-on-fedora-30/1731/25 seems to be a different problem since the network device isn't UP in this report; however I followed some of the debugging suggestions. - Potential similarities to some elements of https://bugzilla.redhat.com/show_bug.cgi?id=1650984 although an older bug (early 2019), where rmmod/modprobe of r8169 resolves the reported issue until a permanent bug fix is provided. Working through this bug possibly suggests that, since it was solved, there have been changes to the realtek drivers? (no separate realtek module is loadable any more AFAICT). - https://bugzilla.kernel.org/show_bug.cgi?id=204343 suggest some recent (December 2019) changes in/around the realtek module and the dependencies asserted by r8169. - An older bug with a r8169 problem on resuming from suspend, probably unrelated: https://bugzilla.redhat.com/show_bug.cgi?id=1580079 I'm including these links and the command outputs in the hope these provide a clue for someone more knowledgeable of how the kernel, systemd, and NetworkManager should function together in a working system.
Created attachment 1647849 [details] lsmod output after r8169 module reload (networking working/configured)
Created attachment 1647850 [details] Output of "ip a" following reboot (no working/configured network)
Created attachment 1647851 [details] Output of "ip a" after r8169 module reload (networking works)
Created attachment 1647852 [details] Filtered dmesg output
Created attachment 1647853 [details] Filtered lspci output
I've solved the problem. Reassigning the bug to NetworkManager, and leaving the bug open given it feels like this upgrade path should be supported. I resolved the issue by deleting all the wired networking profiles in gnome system settings, however it's a little more subtle than that: (1) The settings dialogue didn't show a wired network adapter at all on boot (since the upgrade to F31). (2) On running "rmmod r8169 && modprobe r8169" the network adapter automatically configured and appearing in the gnome settings dialogue. At this point I had earlier deleted the old profile and created a new one. (3) But to get the network card to work on boot, I needed to delete the profile in settings, then *not* create a new profile, then reboot. After reboot networking was working and a new default profile automagically created. I was led to check this after booting into the F31 Live image where there was an automatically configured and working wired network interface. In retrospect this makes some sense: I assume it's something to do with a new device naming policy combined with the ordering of the NetworkManager service after systemd network setup. When I reloaded the r8169 module NetworkManager took control of the device, and the device name was set up accordingly; thus any profile I created from that point ((2) above) would be tied to the same old-system device name and would fail on boot just as the legacy profile had. Deleting all the profiles then immediately rebooting allowed NetworkManager to take control from the start. I should point out that this network card has never been configured with anything other than the gnome system settings dialogue, and has always been NetworkManager managed. The profile had been given a name, but that's all. So frustrating it wasn't converted on upgrade. For what it's worth, the device name shown by "ip a" is now 'enp4s0', i.e. the one shown by "ip a" on booting after the F31 upgrade, but when gnome settings wasn't showing an interface to configure. I guess showing the configuration interface was blocked by NetworkManager expecting the device name still to be 'p5p1'. No evidence this is a "Common Bug" but it would have saved many hours had there been some documentation on that page, or in the Release Notes. Could this be added please?
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.