Testers Wanted: longterm kernel (for TW Slowroll)

https://bugzilla.suse.com/show_bug.cgi?id=1217824

2 Likes

I will help if I am able. Couldn’t figure the issues from the bugzilla report. I have a slowroll qemu libvirt vm if that works for what you need. I can run it as much as is needed. I also run gentoo in a vm and compile kernels from sources there frequently so I have some experience with the basics of that.

Let me know what is needed and I’ll see what I can do.

tom kosvic

Things to try:

  • can you install kernel-longterm ?
  • does it boot?
  • can you build a kmp package for it with osc build? e.g. openSUSE:Factory/v4l2loopback
1 Like

It would also help if you install the longterm kernel, boot into it and run whatever workload you have. If there are no problems that would also help me grasp what is working and what is not working.

I suspect that most things should work fine, but never hurts to get confirmation.

I expect problems with kernel modules coming from Factory, but beside that any new problems (with things that depend on the kernel for example) would be interesting to know about.

Are there any benefits to running kernel-longterm vs kernel-default? I have Slowroll on two external USB solid state drives and the hardware I connect either one to, is from 2011, the CPU is an AMD Athlon II x2 260, dual-core.

More stability. Good for drivers - Nvidia, Intel Ethernet & WiFi, etc.
If you want more stability you may use Leap.

The longterm kernels are maintained by upstream and get released with new bug fix releases every ~two weeks.

The main difference to between longterm and following the stable kernel is that there are no new features introduced. Which means that if you need one of the new features you would likely want to follow the stable kernel.
These new features also mean that there are regressions and/or bugs. Therefor some functionality could break for a couple of minor versions. If you want to avoid these regressions and don’t need any of the new features then the longterm kernel could provide more stability for the systems that you run.

That said there can also bugs in the longterm kernel releases, but far fewer.

As Svyatko said there is also the hope that the external kernel modules(nvidia, network drivers, virtual box) are more stable for longterm kernel users, but that is something that I still need to work on.
Part of the idea to introduce the longterm kernel is to have a base for slowroll that is more stable then the stable kernel, because Leap will go away at one point. Therefor this could be a step to find a replacement for the more stable system setups that would have used Leap.

HTH

1 Like

This is horrible.
Clarification: community will get SLE (SLES) as a source code, but without packaged DEs & other stuff.
And there is SUSE ALP in some future.

Point taken, I should have been a bit more clear here that there will be more Leap versions and that there is no reason to look for alternatives at the moment.

That said: there is currently no workable proposal what will happen to Leap once SLE is discontinued (that I am aware of). With the current level of engagement of the openSUSE community in Leap maintenance a continuation of Leap is not feasible IMO.
So I do think that it makes sense to look for technical alternatives for a stable openSUSE distribution while there is still time to evaluate and discuss options. Maybe slowroll and to a smaller extend the longterm kernel can fill that role at one point in a couple of years. At the very least the openSUSE community can evaluate if that would be an option.

1 Like
1 Like

I have installed kernel-longterm on one of my Slowroll installs (on external USB SSD). It was not on the default entry on GRUB, I found it on the additional options entry. It booted into the desktop login and my web browsers work.

One of the posters on the mailing list thread, indicated the Priority was set to 75 when the new repo was added, so I added it here using that same Priority. If it should be different, kindly advise.

Linux onnsr 6.1.70-1.g80524fb-longterm #1 SMP PREEMPT_DYNAMIC Mon Jan 1 14:10:12 UTC 2024 (80524fb) x86_64 x86_64 x86_64 GNU/Linux

1 Like

FTR: I am planning to update to 6.6 over the weekend. 6.1.76 is the last version for the 6.1 kernel stream.

Kernel:/slowroll:/Backport is for Leap 15.5?
https://download.opensuse.org/repositories/Kernel:/slowroll:/Backport/standard/

It is better to call LTS kernel as LTS, not as Slowroll:

https://download.opensuse.org/repositories/Kernel:/slowroll/
as
https://download.opensuse.org/repositories/Kernel:/LTS/

And
https://download.opensuse.org/repositories/Kernel:/slowroll:/
as
https://download.opensuse.org/repositories/Kernel:/LTS:/

So far, no issues with the new 6.6 longterm kernel on Slowroll. Thank you.

2 Likes

sorry, looks like I am managing my notifications not to well. I responded to this via Factory ML, but did not notice it here.

Kernel:/slowroll:/Backport is for Leap 15.5?

No, only planning to submit to Factory: meaning slowroll and tumbleweed will get the kernel once it is ready.

It is better to call LTS kernel as LTS, not as Slowroll:

The naming is an artifact from the git server. The branches are named after the products the kernels go into. This kernel is aimed at slowroll, but will also reach TW as a (welcome) side effect.

The name is also only a problem now, once submitted to Factory users will not have to deal with the test repo anymore.

Just posted this to the Factory ML:

TLDR: kernel-longterm should become available in Factory some time tomorrow and testers could move to the Factory version if they want to.

Thank you very much for an LTS kernel option.

But there are some bugs introduced into it specifically w.r.t. how kexec functions, the problem is that kexec does a firmware reboot instead of a kexec reboot.

Bugzilla report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1220541

@bmwiedemann Could you describe the process by which kernels are added to update repo? I migrated from Tumbleweed to Slowroll to get away from the buggy 6.7.6 kernel but soon after Slowroll’s update repo also added this in.

@rfrohl Could you check which backports were applied to long term kernel 6.6.18 that caused it to have the kexec bug same as the new kernel 6.7.6?

I’d be happy to provide any additional information for troubleshooting, either here or in the bugzilla report.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.