As the team is developing the LTS product and deciding on a concrete kernel plan, I wanted to share some concrete data from my experiences.
I have not had a stable ublue os for several months. I am running a pretty “popular” configuration: Lenovo Thinkpad T14s with AMD 7840U (780m GPU). Similar specs to my APU are also found in several gaming handhelds, framework laptops, etc.
Starting on kernel 6.13 I started experiencing kernel freezes. The system would completely lock out and require a hard reboot using power button to become functional. At the time I was on bluefin GTS, the most “LTS-ish” product that was offered.
No 6.13, 6.14, 6.15 kernel release has managed to fix the issue, though anecdotally it has gotten better in recent releases. Early testers are finding 6.16 also has not fixed the issue either.
There are dozens of threads on this by users over the past few months, but just a sample of some for the 6.15 release:
If this was a regression for one kernel release it could be fine, but across 3-4 releases and months makes me skeptical of relying on non-LTS kernels going forward given I have pretty standard hardware well supported by upstream (no nvidia, etc). Especially because ublue’s vision of a chrome-os like distro that can automatically update and stay out of the way.
Ideally, I would like a bluefin LTS option that follows Ubuntu LTS where it stays on the LTS kernel but with an option to enable HWE kernels for those that want a newer kernel or have newer hardware. Similarly Debian with its default LTS kernel and backported kernel option. The HWE/backported kernel also tends to be slower than upstream so it also usually offers a stable path. bootc can make it easy to rebase back and forth to the image with the kernel of your choice.
Luckily my laptop is not currently used for any critical work so I can put up with these issues until they are resolved. I love ublue’s vision and tech stack so hoping to continue using it for a long time and installing it on my family’s other machines.
One more thing to add: LTS kernels seem to be released once a year which is a pretty good cadence for many folks and fits well with the cadence that LTS/GTS go at (which is already 6-12 months behind the latest).
I think we’ll just roll with this, stock 6.12 on lts, and then lts-hwe we can use the kmods kernel, but we’ll want to gate those still, which we can decide later.
Well, mostly by stock does it mean whatever Centos is at for the life of the release (meaning same kernel + gnome for 3 years?)
I was hoping more for something like “switch to the current LTS kernel when it becomes N-1 and keep it on that until the next LTS kernel becomes N-1 and have gnome at N-1 as well throughout”.
So something in between stock LTS and GTS. Then lts-hwe can just swap the kernel with an hwe one for those that don’t want to wait a year for next LTS kernel.
Not a deal breaker as being easily able to rebase between LTS and lts-hwe means I could switch back and forth as needed…
@supermair I am using bluefin-dx-nvidia-open:stable which as of the update yesterday has kernel 6.14.11. I have not had any stability issues except some very minor package related things (there has been some volatility with bluez lately as they - Fedora upstream - work through some regression) - but nothing major.
We’ll figure out gating for -testing down the line, thinking of probably gating these to the last minor point release before bumping. We want this kernel to be new, but not newer than Fedora.
Every time we add a kernel we need new akmods for them so not keen on committing to the linux LTS kernel as of yet, staying on 6.12 is “free” for us because Cayo needs it too so we’re just reusing that work.
by stock does it mean whatever Centos is at for the life of the release (meaning same kernel + gnome for 3 years?)
