Comments

109 Comments

It hasn't even been 24 hours yet. Things tend to get pushed once per day unless there is a critical security issue which requires a special push.

Well, Greg is. One of them was already working upstream, but the patch pulled into stable needed an additional patch to fix the bug, not sure yet on the others, but in all cases the revert is the safe option for stable as the regressions were introduced by the addition of these patches.

There were a couple of regressions, and a 5.13.18 has been released today with just a couple of (critical to some workloads) reverts.

There is a 5.14.5 with a couple of reverts that should take care of this.

@gbcox so it clearly is not a regression in this update. Yes, I am aware of the issue, I have not seen any movement from upstream to fix it.

@martinpitt It is not so much a "not supports" as we do not do certification on Fedora, so the assumption was people who cared about FIPS were using RHEL. When the rawhide bug was filed, RHEL people did start working to figure out the issue, so the testing is valid because it does get a response. I just didn't think it was of value to backport the fix. Now that I know there are users, I am happy to do so.

Sorry, to be honest, I didn't expect anyone was actually using fips in Fedora, the options were more about keeping things tested for RHEL. It looks like the fixes for that were done in rawhide recently, and I can bring them back for 5.13.8

@mattf thanks for posting the workaround here. I was aware of it, but on PTO and honestly was not given a heads up on the security issue coming, or I would have timed all of this differently. It is important to get this update out, I will be working on getting a proper fix in for the AMD issue over the weekend.

Build updated, this fixes a critical security issue now.

@ibims yes, it is building now, this update will be changed to include it.

Looks like you lost the host controller, did you open a bug with an attached dmesg and such? I didn't see it.

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.