Description of problem: Upgrading from kernel-4.13.9-300.fc27.aarch64 which came in Fedora-Minimal-27-1.6.aarch64.raw.xz to kernel-4.14.7-300.fc27.aarch64 breaks networking. I don't have access to console but with the new kernel, I no longer see the board to renews its DHCP lease and respond to pings or sshd. This is in spite of manually creating the dtb symlink as workaround for bug 1528575. Version-Release number of selected component (if applicable): kernel-4.14.7-300.fc27.aarch64 How reproducible: Deterministic. Steps to Reproduce: 1. Have Banana Pi M64 with working networking with kernel-4.13.9-300.fc27.aarch64. 2. Upgrade to kernel-4.14.7-300.fc27.aarch64. 3. In /boot, rm -f dtb ; ln -sf dtb-4.14.7-300.fc27.aarch64 dtb 4. reboot Actual results: The board does not seem active on network. Expected results: Networking working as with previous kernel. Additional info: Reverting the saved_entry in /boot/efi/EFI/fedora/grubenv to the previous version and reverting the /boot/dtb symlink (I do this on the SD card mounted in my laptop because I don't have a way to do it on the board) make networking work again.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.15.3-300.f27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I'm sorry to report that upgrading to kernel-4.15.3-300.fc27.aarch64 does not seem to fix the issue.
I don't have serial console to do interactive troubleshooting so I don't really know what is happening there ... checking the journal after I've rebooted back to 4.13.9-300.fc27.aarch64, there does not even seem to be a record of boot into that 4.15.3, so the problem likely isn't the networking at all -- the kernel simply does not boot.
To investigate some more, I flashed Fedora-Minimal-Rawhide-20180220.n.0.aarch64.raw.xz with kernel-4.16.0-0.rc2.git0.1.fc28.aarch64 and it boots and DHCPs fine. I then flashed back Fedora-Minimal-27-1.6.aarch64.raw.xz and then installed kernel{,-core,-modules}-4.16.0-0.rc2.git0.1.fc28.aarch64.rpm (and of course updated /boot/dtb). After reboot, things do not work. So then I've replaced the /boot/initramfs-4.16.0-0.rc2.git0.1.fc28.aarch64.img which was generated during the package installation (file size 18841270) with the file from the Fedora-Minimal-Rawhide-20180220.n.0.aarch64.raw.xz install (file size 52326700). I've rebooted and things work. So the problem seems to be the initramfs produced during package installation, rather than the kernel per se.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.