OpenMandriva Lx release 6.0 (Vanadium) Rock for x86_64
Desktop environment (KDE, LXQT…):
Operating System: OpenMandriva Lx 6.0
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Kernel Version: 6.14.2-desktop-3omv2590 (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62,7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080 Ti
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C37
System Version: 1.0
Description of the issue (screenshots if relevant):
I’m trying to find and install an updated kernel (…hopefully with latest exploit fixes!!) but found nothing useful. System update reports ‘nothing to do’ and a dnf search for kernel-desktop only offers the standard kernel plus a plethora of unintelligible prefixes like: adfs appletalk efs hfs orangefs(??), and absolutely NO version numbers. DNFDrake is also of no use. I tried a general Internet search, checked the wiki, searched on the forum, but found absolutely NO relevent info. I did find a link to: abf.openmandriva.org/openmandriva/kernel/build_lists, but they’re only relevent for cooker, not Rock. I only have the following repos enabled: Main Extra Restriced Non-Free.
Could someone tell me how to find and install an updated kernel for OM Rock please? Thanks.
Relevant informations (hardware involved, software version, logs or output…):
You can use the latest Cooker kernel. Currently for x86_64 and znver1 that is version 7.0.4. Do not know if it would work with the proprietary nvidia driver.
Just chiming in on this, bec I was also trying to understand how to get updated kernel a few days ago – so it may be a common question / forum area that needs to be added.
But, of course, it could just be that I’m unfamiliar with the forum.
I’m running Rock & have been for about 6 mos or something. (previously ran Ubuntu from 2018 til switching to Rock.
Now, I’m contemplating moving to Rome (faster update schedule, right?).
But, it would be nice to know if I update to Rome if that give me kernel fixes for the latest exploits (really mostly thinking about) :
CVE-2026-43284
CVE-2026-43500
Is there a list here somewhere that shows kernel version and fixed CVEs?
I really like OpenMandriva and I also saw that BIG FAT WARNING & got my daily update scripts updated to use that, so that was very helpful.
A good guess would be those you mention were in kernel 7.0.3 which @bero recently backported to ROME. But this is me speculating not verified fact. I can verify that at this moment the latest OM Cooker kernel is 7.0.4, and the latest at kernel.org is 7.0.6 which I am sure we will have as soon as possible.
Best would be to talk directly to developers at the OpenMandriva Chat channel. OR follow the mailing list for kernel.org. For example OM kernel 7.0.4 is built on the same version from kernel.org so whatever they have fixed in that version we would have.
Users of any version on OMLx are welcome to use the latest Cooker kernel. Do not worry about it being a “Cooker” kernel. Why don’t we put latest kernel in ROME or Rock straight away? Testing, sometimes the latest kernel version breaks something. For example if you install a Cooker kernel and that breaks say your wifi or audio, boot in to the previous kernel, and report on OM Chat what happened and wait for devs to advise. If you are asked to provide more information or logs please do so, that is how these things get fixed. If you choose to use a Cooker kernel you are a tester!
All OM versions (or branches) are designed to keep the 3 most recently installed kernel versions for this reason.
Most ROME and Rock users do not need or want the absolute latest kernel version with no testing.
Who says we do not do anything about critical vulnerabilities? Kernel 7.0.3 was backported to ROME rather quickly before our devs realized that (a) it did not fully address the issues at hand and (b) kernel.org was a bit chaotic this past week:
uro:
notably upstream was a complete shitshow this week, multiple releases with many untested and as a result prematurely applying patches to make releases that were subsequently superceded
berolinux:
Essentially before I was done backporting 7.0.3 to Rock, it was clear that it didn’t fully solve the problem
So right now waiting for a version that actually does before sending it to both ROME and Rock
7.0.8 looks good so far
uro:
other distros also paused making releases due to this fiasco
Those are direct quotes form OpenMandriva Cooker Chat channel where our developers work. One or more of our developers is a member of kernel.org. Our developers do talk with people at other Linux projects. They are not working in a vacuum.
As far as why we don’t use LTS kernels I do not know. If it is really that important to someone I keep telling Y’all where to talk directly to developers or just read their conversation, OM Chat.
Edit: Thanks @vulonkaaz, @raddevus, and @KevB-42 for asking some good questions. I hope my answers are helpful and useful for our users. I realize what is obvious to insiders/contributors like me is not so obvious to users especially new users.
About the LTS kernels:
berolinux:
there is simply no reason whatsoever not to move to a newer kernel release unless you rely on patches to make a particular SoC work or something
There’s no reason why we shouldn’t just throw 7.0.8 (or 7.0.9 if it turns out 8 still doesn’t work) at rock
Edit: kernel 7.0.8 just started building for Cooker. That means it has been tested by the developer locally on his box. Then some testing in Cooker and if it does what is expected and all works OK for those using Cooker then and only then would it be backported to ROME and Rock.
I will state first-hand that I am no kernel developer.
Often simply having to wait on responses from upstream is a big hold-up on releases and in other cases there are delays pending testing results before upstream make releases/fixes - this is understandable in order to provide the best software for downstream users.
IMO this week reflected badly on the Linux Foundation who appeared to be rushing premature releases (prior to thorough testing by the developers/subsystems making those patches) that were untested by the usual kernel test mechanisms and in a few cases early versions of patches that were superseded on the same day as new patch revisions hours after a release, resulting in multiple releases with many bug fixes but very unclear information coming from upstream in regard to the status.
IMO, this doesn’t fix the public opinion in regard to the past weeks shenanigans, which the Linux Foundation need to simply do better in communications with both distro maintainers and with end-users in order to both prevent a “panic” situation (exacerbated by social media agents) and to provide solid & clear information for Linux users which users can rely on.
I installed the new kernel-desktop and kernel-headers package from the last cooker build on my Rock install and it seems to mostly work fine but networkmanager can’t autoconfigure ipv4 anymore for some reason, I had to run sudo dhclient for internet to work again and it seems i have to do that each time i boot until i actually solve the issue
also i get that message for like a second when i boot (then it just boot normally)
I still believe LTS kernels would be a better choice for the Rock branch, a stable branch is supposed to be feature freeze but with security updates which is exactly what LTS versions provide, I haven’t seen any package update on my system since last year which make me believe we might not get as many security updates as we should have
I think that is a legitimate question. I have said before the IMO ROME is a better choice for individual users. The security advantages of more frequent upgrades are rather significant.
Whether that is good, bad, enough, not enough, or just right I don’t know.
I would go to OpenMandriva Chat channel with that or you can open a new thread with a descriptive title and either way you need some evidence of the problem like logs, ect. Edit: I do not know which kernel version you installed. We have not had any reports of problems with NetworkManager in ROME since we backported kernel 7.0.3. Nor have we had any reports against any 7..x.x kernel vs. NetworkManager in Cooker, but that is all I know. I would suspect this is NetworkManager being finicky which it is but need more evidence no know anything for sure.
