How to install a realtime kernel in Fedora Silverblue

Hi there good folks,

I’m wondering about the question in the title: how am I supposed to install a realtime kernel in Fedora Silverblue?

For now uname -a says: Linux [redacted] 5.17.11-300.fc36.x86_64 #1 SMP PREEMPT Wed May 25 15:04:05 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux.

Tried to layer a rt kernel by rpm-ostree install kernel-rt (as one would do with dnf in regular Fedora), but says there’s no such package.

ALTERNATIVELY: is there a way to set up flags to my kernel so that it works like a realtime one?

Excuse me if questions are dumb, I’m a newbie and want to work on audio with Silverblue, which is why I’m asking for a rt kernel.

Regards,

  • A
2 Likes

This is a difficult one to answer. RHEL and CentOS at least used to ship an RT kernel. I don’t know that Fedora ever did, but there was a 3rd party repo called PlanetCCRMA that I believe was out of Stanford that used to publish RT kernels for Fedora, but I don’t believe it’s active anymore. That said, the Linux kernel has changed a lot in recent years with scheduling such that some of the reasons for the RT kernel are no longer an issue for the mainline one. Between Fedora IoT and the new wireplumber stuff that can handle JACK, I suggest trying your stuff on the current standard Fedora kernel as you might be surprised at how well it does for RT use cases out of box now.

That said, you can also compile your own kernel for Fedora with PREEMPT. Here’s the guide to how to build a custom kernel. Just layer in the rpms from the output.

1 Like

While PlanetCCRMA’s homepage is outdated, it looks like they have f36 packages. Of course, use it at your own risk. I have no idea how well it’s maintained anymore since the last version they explicit supported was Fedora 30. Building your own kernel might be more sane, honestly.

http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/36/x86_64/repoview/letter_p.group.html

2 Likes

Be careful with this page. It has not been maintained for years. The commits that have happened in the recent years were only formatting without updating content. The “secure boot” section seems to be the newest one but it is still 3 years old (the other parts are even older). Likewise 3 years ago, this page and some others were marked for “review needed”. It is still marked as such: see the adoc file (4th line) and the readme. Unfortunately, the Quick Docs are not in a good condition atm and you have to be careful with them.

1 Like

Two things:

  • Those instructions are generally still valid. I’ve referred to them myself when compiling kernels in recent years
  • Please consider contributing updates to the docs if you see errors

A review is welcomed if you verified the content and the processes on this page. See the readme for more information about how to do the review. At the moment, it is marked the way it is because no one did review or update its content for a long time. And this can prove dangerous in some pages, which is why it should not be automatically considered that everything is fine until it breaks the system of a user. This is why I warn. Currently, the Docs team has no time to focus on the Quick Docs content because we have to work on the release and other Docs, and on finding some (interim) solutions for the open issues. And even for that our time is not sufficient. As far as I know, our work on the Quick Docs is currently limited to move them from Pagure to GitLab (this is likely to happen soon). But I’m not involved in that process.

As member of the Docs team: we have much more pages to update than we can. That our little team does updates, reviews and corrections on all the pages that are consolidated at docs does not work out. My focus is currently on the Install Guide, and maybe to find a solution for “critical Docs” to get separated from those we can no longer maintain. Concerning the Quick Docs, it has to be seen how and where they develop (and how to maintain them on the longer term). This is the reason why I, on the other side, not feel well currently in encouraging people to put efforts in them until the issues have been clarified. You see, it is a more complicated issue :wink:

If you compare the Quick Docs to a package, it could be said that they are orphaned: this does not mean that everything inside is wrong but that we do no longer know what is still valid and what not (or even dangerous). And therefore, we do not actively encourage to use them atm.

But to avoid misunderstandings: your point is a valid one! The limited external interactions, contributions and inputs are major issues - or a symptom of it (depending on the perspective :wink: ). There is not just the way of being full member of Docs or “user only”, but also the “casual contribution” in between.

1 Like

In that case, I will defer to you one this one :sweat_smile: . I used to contribute by editing back when it was on wiki and I helped with the old Sys Admin guide draft (like 10+ years ago), but I sadly haven’t been in the docs game lately.

All that to say, I don’t want to hijack this topic, so maybe we can followup elsewhere. As for the OP, these specific steps in this sections should be enough to get started in the right direction. This is the method I generally use (replacing f28 with f36).

1 Like

Sorry guys for not replying for a sizeable amount of time.

However, when I see all this stuff above I decided to stick to my regular kernel :smiley: I’m a newbie and will probably mess things up. That paired with the desire to try this if there are any benefits, convinced me to leave my system as it is.

Thanks for your replies anyway.

  • A
1 Like