Soltros OS LTS Switching to Long-Term Kernels

Starting now, all LTS releases of Soltros OS will ship with long-term support kernels instead of the standard Fedora kernels. I'm kicking this off with the 6.12 LTS kernel from kwizart's COPR repository.

Why the Change?

Let's be clear: this isn't about fast moving packages. Soltros OS is designed to seamlessly transition between Fedora releases (41 to 42 to 43) while you just keep getting updates. That's working exactly as intended.

The problem is Fedora's kernels tend to break things. Sometimes it's a driver regression, sometimes it's a change that breaks specific hardware configurations, sometimes it's just weird bugs that shouldn't be there. For an LTS release where stability is the entire point, that's not acceptable.

Long-term kernels stick with a single major version and only get bug fixes and security updates. No new features, no risky changes, just stability. That's what LTS needs.

What This Means for You

If you're running Soltros OS LTS, your system will now track the kernel-longterm releases from the kwizart COPR. When kwizart publishes a new LTS kernel (like when 6.12 eventually gets replaced by the next LTS branch), Soltros will follow along.

For most users, this is completely transparent. You'll get kernel updates through the normal update process, just like before. The difference is that these updates will be within the same LTS branch rather than jumping to newer kernel versions.

Benefits

Better stability for production systems
Fewer random breakages from kernel updates
Easier to maintain external kernel modules
Still get security fixes and important bug fixes

Want Bleeding Edge?

If you want a bleeding edge kernel, use the unstable releases. They track in-dev Fedora and get all the latest kernel versions as they land. That's what they're there for.

LTS is for stability. Unstable is for everything else.

The Technical Details

For those curious about implementation, I'm removing the default Fedora kernel packages and installing kernel-longterm directly during the container build process. Here's what that looks like:

# Remove default kernel packages and install kernel-longterm
RUN dnf5 -y remove --no-autoremove kernel kernel-core kernel-modules \
    kernel-modules-core kernel-modules-extra || true && \
    echo "Installing kernel-longterm..." && \
    if dnf5 -y install kernel-longterm kernel-longterm-core \
       kernel-longterm-modules kernel-longterm-modules-extra; then \
        echo "kernel-longterm installed successfully"; \
    else \
        echo "Failed to install kernel-longterm"; \
        echo "Falling back to default kernel installation"; \
        dnf5 -y install kernel kernel-core kernel-modules || true; \
    fi

Why not use rpm-ostree override? Simple: I'm building container images, not composing ostree commits. The container build process uses standard dnf5 operations to swap out packages. I remove the stock kernel packages first, then install the longterm variants. If something goes wrong with the longterm installation, the build falls back to reinstalling the default kernel so the image doesn't break.

The build process automatically detects and builds initramfs for whichever kernel gets installed, so everything just works out of the box.

Questions?