Hello!
I am giving Slowroll a spin because I like the idea of not getting hit by every single regression that might ship with packages, while also staying fairly current.
A year ago I was looking for the bleeding edge software because my hardware wasn’t actually fully supported yet (specifically my RDNA 4 GPU). Now that has changed and I don’t need to chase the absolute latest.
But recently there were several major regressions in kernel 6.19 for my card and I ended up staying on 6.18 for a while. Not a bad thing given that 6.18 was perfectly fine but also an LTS. There were some issues that made RDNA 4 cards crash. Then there was a major regression for my hardware where a change to IOMMU code caused the kernel to be unbootable with IO_PAGE_FAULTS, unless I turned off IOMMU or put it in passthrough mode.
This is what happened across distros (I don’t have data on openSUSE distros):
- CachyOS was one of the first to offer kernel 6.19, several users got hit by the IOMMU patch, Cachy backported an upstream patch that was not yet merged, but it solved the issue; they had a patched kernel by 6.19.5, so they were the fastest to present the bug to the users but also the fastest to fix it
- Arch was lagging behind on 6.18; Nothing was communicated to us testers as to why; I was one of their testers, when they sent 6.19.6 to the testing repos I reported the bug and they still released the kernel because they had more than 2 karma, and bear in mind you cannot give negative karma as a tester; at which point I stopped testing for them and switched distro; yes I had an LTS kernel to fall back to but it was the attitude I wasn’t fond of; I believe they waited for upstream 6.19.10 where it was merged, fair enough Arch is upstream first
- Fedora does often delay new kernels but I think they were a bit slower this time because they were preparing for 44; this is what I switched to temporarily from Arch while I was trying to find my new home; They were on 6.18 and when 6.19.6 reached their testing repos, I filed a bug and I was able to speak to one of their kernel developers directly; I linked the unmerged patch from the kernel mailing list, he backported it, I tested it worked and gave confirmation and only then Fedora released kernel 6.19 into the wild.
Then mesa 26.0 came out and some of my games crashed and locked up my entire PC, apparently a Ray Tracing bug with that mesa version, fixed with a .1 or .2 iirc.
Slowroll is supposed to backport security patches and some more major bugs as far as I understand. So you are not necessarily stuck with a bug for a month.
Would bugs such as the above get patched? As they only affected certain hardware, would they be deemed important enough? In theory Slowroll is perfect on paper for me, but in practice having a single developer behind it, albeit a super responsive one as far as I can see, does put time constraints on bug fixes.
Any insight would be appreciated.
@Xariann Hi, not a Slowroll user, but perhaps @bmwiedemann can reposond to your query?
There is always rolling back to a previous snapshot if using btrfs, likewise there is tumbleweed-cli to go back in history or stay on a snapshot release. Or you can cherry pick history packages to install etc…
You can configure zypper config to keep as many kernels you like, just make sure you have a big /boot/efi partition as openSUSE is using systemd-boot as the default (I use 4GB).
No one is forcing you to update, but it can cause issues for some setups.
@malcolmlewis Oh yes I know 
Snapper snapshots out of the box that works with encryption is very much one of the reasons I am here.
Just some bugs you don’t know they happen until your PC stops booting… And spend some time to find info about it to feel reassured your hardware isn’t giving out on you.
Edited for clarity.
Then I would suggest keeping an eye on the Tumbleweed changes as they offer some additional info on what changes will appear in the likes of slowroll.
https://download.opensuse.org/tumbleweed/iso/
For example: https://download.opensuse.org/tumbleweed/iso/Changes.20260423.txt
I’ve been running Tumbleweed and MicroOS based releases for a number of years, never had any major issues, systems have always booted… On my primary desktop it can either be running Intel ARC or Nvidia and use ext4… LVM, encryption etc are not used here either, well on Aeon it uses encryption.
Thank you will certainly do and it’s good to hear about the reliability.
Also re-reading my OP I think it sounds like I had the mesa bug and then complained that Slowroll is supposed to hold back things until they are fixed.
I wasn’t on Slowroll when that bug hit, in the message I was just pivoting to Slowroll to mean it could be a good solution.
I would just point out that Slowroll is not a “One Man Distro”; the hard work is done on Tumbleweed, then Bernhard chooses when to snapshot and/or cherry pick selected patches and publishes those in the Slowroll repos.
Also bear in mind that Tumbleweed has to clear openQA before being published, unlike other rolling distros, so if there is a major bug it is likely to be discovered there first.
@Xariann then I would suggest checking out tumbleweed-cli?
I have two day to day systems running Tumbleweed, all has been fine. I am concentrating on Intel ARC at present, so the other system has Nvidia ( a fresher install, so using systemd-boot)…
Point taken on the one-man-distro.
As to openQA, can it catch hardware specific issues? I thought a lot of it was on VMs, the IOMMU bug for example didn’t happen in a virtual machine on my PC, just on bare metal.
And for sure I am not expecting to never have a bug. I mean I was testing on Arch to help out. I am just trying to figure out the modus operandi of the distros and how easy it would be to report the bugs.
Thank you, I am looking at it now, I didn’t know it existed.
No, of course; but in those cases you can revert to the last snapshot or head over at https://download.opensuse.org/history/ where you can find some 3 weeks of released snapshots, downgrade and lock the culprit package and wait for a fix.
Aye, yes I know about snapshots
That is not my focus with my OP though. Easy but triage is an excellent feature I agree with you, I am asking about bug prevention/fixing on Slowroll specifically.
1 Like
AFAIK only if there are bug reports…
For an example if I look at the change logs for GraphicsMagick;
Tumbleweeds last entry;
* Mon Apr 20 2026 ...
- added patches
CVE-2026-33535: Out-of-Bounds write of a zero byte in X11 display interaction [bsc#1260874]
* GraphicsMagick-CVE-2026-33535.patch
* Mon Apr 13 2026 ...
- added patches
CVE-2026-26284: Heap overflow in pcd decoder leads to out of bounds read. [bsc#1258765]
* GraphicsMagick-CVE-2026-26284.patch
* Fri Mar 20 2026 ...
- added patches
CVE-2026-28690: missing bounds check in the MNG encoder can lead to a stack buffer overflow (bsc#1259456)
* GraphicsMagick-CVE-2026-28690.patch
Vs Slowroll’s last entry;
* Fri Mar 20 2026 ...
- added patches
CVE-2026-28690: missing bounds check in the MNG encoder can lead to a stack buffer overflow (bsc#1259456)
* GraphicsMagick-CVE-2026-28690.patch
So it’s behind the times by two CVE’s…
2 Likes
This might be an unfortunate point in time since instead of the usual daily or so Slowroll update there was a gap between 20260417 and 20240425 because of mirrors out of sync (most of)
https://build.opensuse.org/package/show/openSUSE:Slowroll/GraphicsMagick says it landed one day before your comment, so not sure where you got the old changelog from.
In general, major updates such as Mesa version updates wait for the monthly update. Kernels do get 6.19.x updates during the month. We have kernel-longterm to stay on 6.18 until next year (also available in Tumbleweed)
@bmwiedemann perhaps the src rpm came from an out of date mirror then?