Comments
mjg
WFM
Also, this solves https://bugzilla.kernel.org/show_bug.cgi?id=44161 for me (ACPI BAT/CHR events on older Samsung Ultrabooks).
If you are bitten by the dracut bug head over to the dracut update https://bodhi.fedoraproject.org/updates/FEDORA-2019-38c666fc03
Changing karma to +1 +1 here.
While the kernel installs and boots there is a reproducible segfault for dracut-install (https://bugzilla.redhat.com/show_bug.cgi?id=1685932) with the current dracut. It s not clear yet whether this a dracut issue or a kernel 5.0 issue. So +1 one for the working update, -1 for the segfault during dnf update.
Maybe it's worth amending this with "Fix CVE-2019-8912 (rhbz 1678685 1678686)" (bb99dec73, current tip of f29 in dist-git)?
https://bugzilla.redhat.com/show_bug.cgi?id=1659225 filed (@jcline let me know if you need more).
(addition to the previous comment: 4.19.3 worked as well, the 4.19. kernel before that did not)
Fedora 4.19 kernels before 4.19.5 and after show an acpi crash for me on an old HP/compaq 6715b laptop with an AMD Turion. Same crash with 4.19.8, whereas 4.19.5 did work. Low and behold: the koji build https://koji.fedoraproject.org/koji/taskinfo?taskID=31411873 ("atomacpi") works, the kernel boots as usual. acpitool -c says:
CPU type : AMD Turion(tm) 64 X2 Mobile Technology TL-60 Min/Max frequency : 800/2000 MHz Current frequency : 800 MHz Frequency governor : ondemand Freq. scaling driver : powernow-k8 Cache size : 512 KB Bogomips : 3989.80 Bogomips : 3989.80 Function Show_CPU_Info : could not read directory /proc/acpi/processor/ Make sure your kernel has ACPI processor support enabled.
This package has been pushed to F28 but not F29. The dependencies are messed up but I'm not sure whether the problem is in -3 or in the earlier versions. Rebuilding my package impressive which depends on python2-pygame (unversioned) and reinstalling helped.
Maybe it is as simple as a missing explicit Provides: python2-pygame for the subpackage.
In any case, having this in F28 forces maintainers of depending packages to bump their F28 versions for a fix - and not pushing it to F29 is not quite what we are supposed to do.
wfm
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
This is without extra smt kernel parameters or sysfs fiddling
wfm
wfm
The way the kernel folks handled retpoline (gcc build in extra koji buildroot) was the best they could do to get those safer kernels out quickly and still have reproducible builds.
koji buildroots are available for everyone to do their scratch builds with. There's also a gcc-retpoline copr if you want to do builds there, using a retpoline gcc.
I'm wondering what happened to the packaging guidelines, though. 4.14.4 pushed to F26 stable when F27 has 4.14.3, and 4.14.4 not even in testing for F27.
I'm fully aware that those are in fact "different packages" for the different branches, but it breaks (or at least complicates) any F26->F27 upgrades, which is why packaging guidelines forbid it.
mupdf mupdf-gl wfm
Has the f26 branch in dist-git been rewound, or what commit has this update been built from? Following the kernel package in dist-git and bodhi should be self-explanatory from the info that is there (log, changelog, comments) - but it's far from that.
Unfortunately, this update has been pushed to stable for F29 before even submitting an update for F30 at all. It breaks system-upgrade from F29 to F30 completely!
Since the previous version is not in updates any more users are forced to downgrade all the way down to the F29 base version, which is no good version for the dist-upgrade.