@jkemp Sorry, that sounded a bit more harsh than I intended. "Your fault" makes it sound as though you should know better, which is not entirely true, but yes, it is a result of your actions in turning on secure boot. Turning it back off and reinstalling akmod and the nvidia driver should get you working again.

@jkemp yes, that is entirely your fault. You turned on secure boot, a kernel module that is not shipped in the Fedora kernel is not secure boot signed, and thus can't be loaded if secure boot is enabled. This has nothing to do with the kernel being broken, the kernel is doing exactly what it is supposed to in this scenario. If you wish to run secure boot and the nvidia module, you will need to create a new key and upload that to your UEFI, and use that key to sign every module that you build.

As for kernel-headers, 6.1.5 is the most recent and will remain the most recent unless a critical bug fix shows up for the UAPI headers. The kernel-headers package is used to build userspace code, and is not used for building kernel-modules at all. kernel-devel is the package which includes the headers and infrastructure to build kernel modules.

@gbcox Not sure where you got the impression that the fix was included in 6.1.6, I see no mention of that at all. It is not in linus' tree yet, and thus not a candidate for upstream stable updates yet. I am keeping an eye on it and will pull it into Fedora once upstream is happy with it.

Yes, nvidia is still broken, no, this is NOT a regression from the current stable kernel 6.1.5. It has to do with a bad hack that we have to carry because their driver is broken. The nvidia hack will be restored with 6.1.7 when it ships this week. In the meantime, there is no reason to keep people running systems without broken proprietary drivers from getting an update with actual bug fixes.

Yes, nvidia is still broken, no, this is NOT a regression from the current stable kernel 6.1.5. It has to do with a bad hack that we have to carry because their driver is broken. The nvidia hack will be restored with 6.1.7 when it ships this week. In the meantime, there is no reason to keep people running systems without broken proprietary drivers from getting an update with actual bug fixes.

@wayne6001 That particular failure is in name resolution and nothing to do with 2fa. That said, if you have 2fa enabled, you simply add your authenticator's code after the password as all one string in the password field, and logs can be submitted with 2fa. If submission of a log file fails for whatever reason, you can always try to submit again with:

fedora_submit.py -l /path/to/logfile

We actually need this version for the kernel build so we can pass --skip_encoding_btf_enum64 as libbpf is too old on f36 to work without it on newer kernels.

This update has been unpushed.

This update has been unpushed.

It turns out there are some btrfs issues with this one, pulling it back 6.0.5 should be building soon.

This update has been unpushed.

It turns out there are some btrfs issues with this one, pulling it back 6.0.5 should be building soon.

@markec because the release was too late to count on for Fedora 37 with freezes and such. Fedora 37 will ship with 5.19, and 6.0 will be available as an update after Fedora 37 ships.

@nivag can you explain how this fails to boot? Does 5.19.12 boot on that system? The only difference between the 2 kernels is a revert of some i915 patches which can potentially damage laptop hardware. If you are seeing any issue not related to i915, it is likely systemd or firmware related. We need to figure it out though because the longer it takes for this update to make stable, the more exposure users have to potential damage.

@fschwarz Thanks for the clarification. I should have a fix for that in 5.19.9 when it ships. I was just making sure it wasn't something else, and thanks again for the workaround explanation here.

@fschwarz I do appreciate adding clarity about the issue to this update where people can see it. I am curious though, why after you make an entire post explaining how it is not a kernel issue at all, you add to that negative karma, and failed test case on kernel regression. Was there a different issue?

Cachedrop is racey, particularly on lower end hardware. I am not concerned with cachedrop failures.

@gtwilliams you just explained how it is not a kernel problem. I am guessing if you recreated your initramfs for 5.19.2 it would fail in the same way. Might be worth tracking down what changed there though, dracut or systemd are likely culprits. Updates on those packages often appear as kernel issues because an initramfs doesn't get regenerated when those packages are updated, so any problems they cause with the initramfs don't appear until your next kernel update unless you happen to regenerate the initramfs for other reasons.

Fedora did not build the 5.18.14 kernel because every single patch (other than the version bump itself) was included in the Fedora 5.18.13 build and there were only 2 or 3 of those patches which were not included in our 5.18.12 build. We shipped retbleed mitigations with 5.18.12, the day it went public. Upstream stable waited a bit to work out some of the issues, but yes, from a code standpoint, we did ship 5.18.14, we just called it 5.18.13, so it is not a new regression in this kernel. And I am still waiting for the f35 build of 5.18.16 to finish.

So you are saying that this AMD issue is new with our 5.18.15 kernel and did not appear before then? I was under the impression that it came in with the 5.18.14 stable kernel (retbleed mitigation), and Fedora specifically has been shipping those patches since 5.18.12. Also, it is not exactly a large number of users, but enough to form a simple pattern. My reasoning was this, there are a number of valid fixes in 5.18.15, and as far as I am aware, no actual regressions compared to the Fedora 5.18.13 kernel we are currently shipping.