Comments
jforbes
I was not planning to build 5.12.16 as all of the changes in that release were for the mt76 wifi driver (less common outside of router type devices), and arch hexagon. combined with the fact that 5.12.17 is already out for review, I felt okay skipping .16. I will be building 5.12.17 when it releases this week.
Boot hangs at "Reached target Initrd Default Target" have nothing to do with kernel update, and are a result of interaction between dracut and dbus updates. Either downgrade dracut to 0.53 and regenerate the initramfs or follow https://bugzilla.redhat.com/show_bug.cgi?id=1976653
For those of you seeing boot issues with this kernel, can you please make sure you have either dracut 0.53 or 0.55-2 installed and regenerate the initramfs? It seems that 0.54 broke a lot of systems, and 0.55-2 fixed (some of) them. If you fail with 0.55-2 try 0.53 and report back. I certainly do not want to send out a kernel which breaks boot on a number of systems, but I think in this case, the kernel isn't actually the problem. I would like to verify.
@spockfish Sure, it can be backported since it is queued for upstream. As the bug was filed against bluez, and no one bothered to reassign it to kernel once it was determined that the problem was fixed there, I had no way of knowing about it. I don't get Cced on bugs for packages I don't maintain.
As to the negative karma, it is not a regression from the currently stable kernel (5.12.9). There are plenty of bugs in the kernel at any given time. Giving negative karma because your bug isn't fixed in an update is like saying everyone who is impacted by the numerous bugs this update does fix should have to wait for their fixes until your specific bug is fixed. Negative karma should be used for new regressions, not for new updates which do not happen to fix an existing bug in what is currently on stable.
@atim If it does, it is incidental. A variation of the patch posted in the upstream bug that was linked in the ticket is queued for 5.12.7, and there is a scratch build[1] I made of 5.12.7-rc1 which is listed as a 5.12.6-301.fc34 that you can test to verify. This particular official update for 5.12.6 does not contain that patch though. I expect 5.12.7 to build tomorrow at some point.
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=68688143
The exclude will go in the '[rawhide]' section, as the the others should be 'enabled=0'.
Some of the virtualbox drivers required for a guest have been mainlined to the point that it is possible to run a virtualbox guest without using out of tree drivers. There is still more to be done, and nothing on the host side.
Rawhide kernel nodebug should never be overwritten by a debug kernel. I create that repository by hand, it isn't scripted at all. Perhaps you do not have an excludepkgs entry for kernel* in your rawhide config?
As to the shutdown, if vbox locks up, and the service definition has no timeout, systemd will wait forever until it is properly shut down. If it is locked up, obviously it won't shut down. This is entirely in how they wrote the entry for the service. They could have included a timeout for say 1:30 or 5 minutes or whatever, and then systemd would just ignore a lack of response and shut the system down, but if there is no timeout, it will wait until the service tells it that it has exited cleanly. In their case, I am sure they wish to ensure guests have shutdown cleanly.
While virtualbox is "open source" it has not ever been upstream for the host services. I don't even recall an attempt being made in earnest over the past decade. If they don't care to do so, upstream isn't going to bother to make sure that it works. Sometimes they have to play catch up, and they have chosen to shoulder that burden themselves. There is nothing I can do about it.
I am pushing this to stable, as it fixes various things for a number of people. I am aware of the ath11k issue, unfortunately it took the upstream maintainer a bit to respond with which patch was missed for stable to fix that. They have responded, and I did include that patch in the 5.12.6 builds which are building now and should be available in updates-testing very soon.
I am pushing this to stable, as it fixes various things for a number of people. I am aware of the ath11k issue, unfortunately it took the upstream maintainer a bit to respond with which patch was missed for stable to fix that. They have responded, and I did include that patch in the 5.12.6 builds which are building now and should be available in updates-testing very soon.
The git snapshot kernels are debug kernels. The rcX kernels without a git snapshot are not. If virtualbox does not work with debug kernel configs, that is an interesting data point, but really something that virtualbox needs to fix. If you are interested in testing and keeping up to date with development series kernels, I might recommend only updating kernels on the rcX builds (typically built on Mondays) or changing your config to only update kernels from Rawhide kernel nodebug repositories. https://fedoraproject.org/wiki/RawhideKernelNodebug
@spockfish The upstream author of the commit which broke it has pointed out the dependent commit which was missed in stable. I have pulled that into the fedora 5.12 tree and it should appear in the 5.12.6 updates
This does not install on several arches (arm, aarch64, ppc64le, and s390x) breaking any build that requires it. Example log https://kojipkgs.fedoraproject.org//work/tasks/8515/66878515/root.log
Not sure if it is a regression or not since I never used pipewire before this version, but with my F34 upgrade yesterday on one system, I get a reproducible failure on initial login. A 'systemctl --user restart pipewire.service' will fix things until the next reboot. https://bugzilla.redhat.com/show_bug.cgi?id=1953820
Somehow the feedback never made it here, but this dracut update breaks creating initramfs for a large number of users.
@storm Do not regen your initramfs for 5.11.10. This is not a kernel issue, I was debugging this with someone in #fedora-devel and they regenerated all of their initramfs, leaving no kernel bootable. I would guess the issue is in either the systemd update in updates-testing right now, or the dracut update that dropped a couple of days ago.
@tysimon While it is indeed dependent on nVidia folks to support upstream stable kernels, the last I heard was that graphics were working find with 5.9.x kernels, but CUDA was broken. Unfortunate, but hardly "unusable". That said, I believe nVidia drivers are at 455.45 versions, and 390xx is pretty out of date.
Not for quite a while it is in RC3 right now. F33 will get 5.9 very soon, and 5.10 in a couple of months.
Yes, that was found after it was pushed, the fix is in 5.8.9 which is in updates-testing right now.
Looks like you lost the host controller, did you open a bug with an attached dmesg and such? I didn't see it.