arcivanov: That is not a kernel issue, and is not a problem with this package. The kernel install scripts are owned by systemd, and no kernel update and work around a bug in them.


Verified this fixes the microcode bug with 6.6 kernels.

======================================================================== Early CPIO image ======================================================================== drwxr-xr-x 3 root root 0 Nov 15 18:00 . -rw-r--r-- 1 root root 2 Nov 15 18:00 early_cpio drwxr-xr-x 3 root root 0 Nov 15 18:00 kernel drwxr-xr-x 3 root root 0 Nov 15 18:00 kernel/x86 drwxr-xr-x 2 root root 0 Nov 15 18:00 kernel/x86/microcode -rw-r--r-- 1 root root 39172 Nov 15 18:00 kernel/x86/microcode/AuthenticAMD.bin ======================================================================== Version: dracut-059-5.fc38


Verified this fixes the microcode issue: Image: /boot/initramfs-6.6.1-300.fc39.x86_64.img: 40M ======================================================================== Early CPIO image ======================================================================== drwxr-xr-x 2 root root 0 Nov 15 19:00 . -rw-r--r-- 1 root root 2 Nov 15 19:00 early_cpio drwxr-xr-x 2 root root 0 Nov 15 19:00 kernel drwxr-xr-x 2 root root 0 Nov 15 19:00 kernel/x86 drwxr-xr-x 2 root root 0 Nov 15 19:00 kernel/x86/microcode -rw-r--r-- 1 root root 106496 Nov 15 19:00 kernel/x86/microcode/GenuineIntel.bin ======================================================================== Version: dracut-059-16.fc39


@mattf oddly enough, the kernel has nothing to do with that. I believe the problem lies in grub, though it could be systemd which is where install-kernel is. You aren't the first one to see this recently.


Seems to be working here on aarch64.

I suppose I don't know how silverblue communicates the support model there, but I would assume the issue tracker is around the code in those repositories for composing silverblue, etc. Any actual system issues are likely tied to packages installed in silverblue and bugzilla is the place to track them where maintainers are actually paying attention to those bugs. I could be wrong though, I haven't really read the silverblue docs. For future reference though, most things around hardware drivers will fall to kernel. blank screens, suspend/resume issues, etc.

It is known, it is tracked in the upstream bug mentioned here, and in Bug 2240859, where I scratch build with a fix is linked. The fix for at least 2 of them will be in 6.5.6. I am not sure why kernel bugs are being filed in github for silverblue as those aren't looked at by the kernel folks. I don't think there has ever been a kernel bug that only impacts silverblue.

This update has been unpushed.

I was hoping to get the lockup issues resolved before pushing an update, but given the disclosure of StackRot, I am afraid we need to push to stable so that at least users who are not impacted by the lockup bug are covered.

So does that mean that the issue is improved with updated firmware?

@g6avk remember when rolling back or updating linux-firmare to test, it typically doesn't matter what version is on the system, it matters which firmware was on the system when the initramfs was made. So changing firmware versions doesn't make any difference unless you make a new initramfs or install a new kernel. This is also why firmware can break something, and it not show up until a week or 2 later when a kernel update ships.

mbrode what is the problem with mount.cifs? Bug number?

@py0xc3 This is clearly not a new regression in 6.3.5 compared to the current kernel in updates. By continuing to give negative karma to each update when there is not a NEW regression, you are saying that no one else should be able to get their bugs fixed until your bug is fixed.

@runekl and anyone else hitting the xfs issue, please take a look at

Thanks for letting me know. I was hoping it was my backport of the CVE fix, just because it would mean I could probably track it down easily. I am guessing this is limited to certain XFS filesystems as I run mostly XFS here, and have not seen it. Perhaps some defaults that xfsprogs used at a specific time, or filesystems created with certain kernels... We can try to track it down in bz 2208553. I will not push this rebase to stable.

@runekl I was hoping to not push this to testing until I can get confirmation that it seems to be the cause of the issue. It is a scratch build at the moment.

@runeki it could be entirely my fault, there was an XFS CVE, I backported a patch for it, and may have missed a dependency somewhere. Upstream stable hasn't picked it up yet. That is what the kernel I posted above is testing, I reverted that patch. Seems if this were in the upstream kernel, others would have noticed and complained as well.

For those reliably hitting the xfs problem, mind giving a try when it finishes? Should be an hour or so.

Honestly, the issue with firefox should be investigated, but it is not my primary concern, the XFS issue is the reason that I haven't pushed this to stable. If you can add anything regarding the XFS issues to it would be appreciated. I run almost exclusively XFS with a bit of ext4 here, and I have not seen the issue locally on any machine.

@tilltyr as mentioned in the bug you linked, this is not a kernel issue. It was a linux-firmware issue, and the fix will also happen there. The reason firmware issues can appear to be tied to a kernel version is because those firmware get copied into the initramfs, and do not change when you change the version of linux-firmware installed on the system unless you also regenerate an initramfs. You should be able to revert your firmware packages to an earlier version of linux-firmware, and recreate your initramfs to end up with a working 6.2.7 kernel.