(Oof, commented on the wrong build - reposting here)
echo 1 > /sys/bus/pci/devices/0000\:07\:00.4/removebefore suspending. Without that, the system would fail to suspend and graphics would be corrupted, requiring a reboot. No idea how that device (
07:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1) ended up causing graphics corruption, but the effect was consistent and its fix under this build is consistent too.
Sorry, forgot to add: also fixes a severe suspend/resume issue on this laptop (failed to suspend, graphics corruption) without the need to
echo 1 > /sys/bus/pci/devices/0000\:07\:00.4/remove (07:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1) any more.
#1785957 too, unfortunately.
Although, 5.4.5-300 did seem to fix a nasty suspend/resume bug that seems related to Ryzen USB hub power management (which itself can be hacked around by dropping the device from the PCI tree before suspending, rescanning after resume).
BTW is 5.4.5-301 still on track for testing?
TL;DR question: previous build for the same version made new kernel unbootable, is this a known issue/fixed now?
I notice that this obsoleted FEDORA-2019-cadb2ea4bf. I accidentally had that earlier one installed, together with a kernel update, in the same
dnf update --enablerepo=updates-testing --security transaction. The new kernel version was unbootable (missing modules it seems).
I booted into an older kernel, noticed that new kernel wasn't really fully installed (one of the
kernel-* packages was not listing as installed for that version, forget which).
grub back to 2.02-84, deleted the (partially installed) new kernel, rebooted again, installed the new kernel, and this time all looks normal, new kernel version is bootable.