Testers Wanted: longterm kernel
Hi all, I am looking for feedback on a side project that I have been working on the last couple of months: Introducing a rolling longterm kernel package to Factory. # Motivation The previous distribution I used as my daily driver offered a LTS variant of the kernel and that always served me well, if some change in kernel development broke a feature that I was relying on. When I moved to Tumbleweed I felt that this was missing, but because of snapper and file system rollback, the impact was never so severe. With the announcement of slowroll I had the feeling that having a longterm kernel might fill a gap, for more stable workloads or software packages that have a dependency onto the kernel, but can not keep up with new kernel versions. Therefor I started to look into how feasible it would be to have a longterm kernel in Factory. # General vision Having a longterm kernel package that follows the rolling release model and will track the latest longterm kernel, once the stable kernel has moved to a higher version number. The configuration should be as similar as possible to the stable kernel. The kernel packaging should use existing infrastructure and processes that are used for the stable kernel, to avoid re-inventing the wheel. # Current state and open points I have a longterm kernel version (6.1.68) available for x86_64 under [0]. This version is using the existing systems and processes. I am now at a state where I think further feedback would be helpful. Known open points that I want to take care of before trying to get into Factory: - Move to the new longterm version (6.6) to get a grasp of the process and see what potential fallout the update might have for users - Find out if external kernel modules would have a problem with different kernel versions and if so find a solution [1] Where this will go is not clear at the moment, I talked with Bernhard and dimstar if there is general interest for a longterm kernel in Factory. It might be an option as a base for slowroll. But there has been no decision on how to proceed. Currently just evaluating if the longterm kernel is feasible for Factory, if openSUSE users would be interested and if a community maintainer can handle the workload, as I am not a kernel developer in my day job. If someone has a use case that does not depend on external kernel modules and some time over the holidays, I would really appreciate feedback, be it improvements or any other type (also if things work out ok and there are no complaints ;) ). Cheers, Robert p.s: without the help and support of others, this little experiment would have been impossible to do, I would like to specifically thank a couple of people for their support and patience with my questions: Michal, Takashi, Jiri and Marcus. I would also like to thank SUSE for the time they make available during hackweek, as I spend some of my time on the longterm kernel. p.p.s: you can install the longterm kernel by:
zypper addrepo http://download.opensuse.org/repositories/Kernel:/slowroll/standard/Kernel:s... zypper refresh zypper install kernel-longterm
[0] http://download.opensuse.org/repositories/Kernel:/slowroll/standard/ [1] https://bugzilla.suse.com/show_bug.cgi?id=1217824 -- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
Robert Frohl composed on 2023-12-19 14:07 (UTC+0100): ...
- Move to the new longterm version (6.6) to get a grasp of the process > and see what potential fallout the update might have for users...> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1217824
I have 16 SRs now, and don't anticipate creating more. They all look more or less like this: # zypper lr -p # | Alias | Enabled | GPG Check | Priority | URI --+----------+---------+-----------+----------+--------------------------------------------------------- 1 | NonOSS | Yes | (r ) Yes | 99 | http://cdn.opensuse.org/slowroll/repo/non-oss/ 2 | OSS | Yes | (r ) Yes | 99 | http://cdn.opensuse.org/slowroll/repo/oss/ 3 | Update | Yes | (r ) Yes | 80 | http://cdn.opensuse.org/update/slowroll/repo/oss/ 4 | openh264 | Yes | (r ) Yes | 99 | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/ # zypsei nel-def il | kernel-default | package | 5.14.21-150500.55.19.1 | x86_64 | (System Packages) il | kernel-default | package | 6.4.12-1.13 | x86_64 | (System Packages) il | kernel-default | package | 6.5.9-1.3 | x86_64 | (System Packages) # Before 6.6 replaces current 6.1, I don't see much point in adding the LT repo. Once it does though, I think I'd switch most over, if not all. I don't see a downside given lack of plans for newer hardware in foreseeable future. In my new repo template for LT, I currently have set priority to 75: [KernelLT] baseurl=https://cdn.opensuse.org/repositories/Kernel:/slowroll/standard/ enabled=1 gpgcheck=1 gpgkey=https://cdn.opensuse.org/repositories/Kernel:/slowroll/standard/repodata/rep... keeppackages=1 name=KernelLT priority=75 type=rpm-md # Would something else make better sense? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 19.12.23 16:01, Felix Miata wrote:
Robert Frohl composed on 2023-12-19 14:07 (UTC+0100): ...
- Move to the new longterm version (6.6) to get a grasp of the process > and see what potential fallout the update might have for users...> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1217824
I have 16 SRs now, and don't anticipate creating more. They all look more or less like this:
# zypper lr -p # | Alias | Enabled | GPG Check | Priority | URI --+----------+---------+-----------+----------+--------------------------------------------------------- 1 | NonOSS | Yes | (r ) Yes | 99 | http://cdn.opensuse.org/slowroll/repo/non-oss/ 2 | OSS | Yes | (r ) Yes | 99 | http://cdn.opensuse.org/slowroll/repo/oss/ 3 | Update | Yes | (r ) Yes | 80 | http://cdn.opensuse.org/update/slowroll/repo/oss/ 4 | openh264 | Yes | (r ) Yes | 99 | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/ # zypsei nel-def il | kernel-default | package | 5.14.21-150500.55.19.1 | x86_64 | (System Packages) il | kernel-default | package | 6.4.12-1.13 | x86_64 | (System Packages) il | kernel-default | package | 6.5.9-1.3 | x86_64 | (System Packages) # Before 6.6 replaces current 6.1, I don't see much point in adding the LT repo. Once it does though, I think I'd switch most over, if not all. I don't see a downside given lack of plans for newer hardware in foreseeable future.
Thanks for the feedback, I will update the thread if I make progress on any of the open points.
In my new repo template for LT, I currently have set priority to 75: [KernelLT] baseurl=https://cdn.opensuse.org/repositories/Kernel:/slowroll/standard/ enabled=1 gpgcheck=1 gpgkey=https://cdn.opensuse.org/repositories/Kernel:/slowroll/standard/repodata/rep... keeppackages=1 name=KernelLT priority=75 type=rpm-md # Would something else make better sense?
Looks sane to me. Cheers, Robert -- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
IMHO useful thing for Nvidia GPUs, Intel network drivers, etc. Possibly it will be usable with Leap 15.6 after glibc upgrade. Forum topic: https://forums.opensuse.org/t/testers-wanted-longterm-kernel-for-tw-slowroll...
Hi all, small update for the longterm kernel: earlier today the last 6.1 update reached the test repo (6.1.76) and I have a version for 6.6 ready. I am hoping that the new longterm kernel (specifically 6.6.15) will reach the test repo [0] on Sunday morning. I wanted to give a heads up in case some people do not want to update right away. From my POV there is nothing problematic that I am aware of, never the less it is the first major longterm kernel update that I am doing. Cheers, Robert On 19.12.23 14:07, Robert Frohl wrote:
Hi all,
I am looking for feedback on a side project that I have been working on the last couple of months: Introducing a rolling longterm kernel package to Factory.
# Motivation
The previous distribution I used as my daily driver offered a LTS variant of the kernel and that always served me well, if some change in kernel development broke a feature that I was relying on. When I moved to Tumbleweed I felt that this was missing, but because of snapper and file system rollback, the impact was never so severe.
With the announcement of slowroll I had the feeling that having a longterm kernel might fill a gap, for more stable workloads or software packages that have a dependency onto the kernel, but can not keep up with new kernel versions. Therefor I started to look into how feasible it would be to have a longterm kernel in Factory.
# General vision
Having a longterm kernel package that follows the rolling release model and will track the latest longterm kernel, once the stable kernel has moved to a higher version number. The configuration should be as similar as possible to the stable kernel. The kernel packaging should use existing infrastructure and processes that are used for the stable kernel, to avoid re-inventing the wheel.
# Current state and open points
I have a longterm kernel version (6.1.68) available for x86_64 under [0]. This version is using the existing systems and processes. I am now at a state where I think further feedback would be helpful.
Known open points that I want to take care of before trying to get into Factory:
- Move to the new longterm version (6.6) to get a grasp of the process and see what potential fallout the update might have for users - Find out if external kernel modules would have a problem with different kernel versions and if so find a solution [1]
Where this will go is not clear at the moment, I talked with Bernhard and dimstar if there is general interest for a longterm kernel in Factory. It might be an option as a base for slowroll. But there has been no decision on how to proceed. Currently just evaluating if the longterm kernel is feasible for Factory, if openSUSE users would be interested and if a community maintainer can handle the workload, as I am not a kernel developer in my day job.
If someone has a use case that does not depend on external kernel modules and some time over the holidays, I would really appreciate feedback, be it improvements or any other type (also if things work out ok and there are no complaints ;) ).
Cheers, Robert
p.s: without the help and support of others, this little experiment would have been impossible to do, I would like to specifically thank a couple of people for their support and patience with my questions: Michal, Takashi, Jiri and Marcus. I would also like to thank SUSE for the time they make available during hackweek, as I spend some of my time on the longterm kernel.
p.p.s: you can install the longterm kernel by:
zypper addrepo http://download.opensuse.org/repositories/Kernel:/slowroll/standard/Kernel:s... zypper refresh zypper install kernel-longterm
[0] http://download.opensuse.org/repositories/Kernel:/slowroll/standard/ [1] https://bugzilla.suse.com/show_bug.cgi?id=1217824
-- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
On 2/2/24 12:18, Robert Frohl wrote:
Hi all,
small update for the longterm kernel:
earlier today the last 6.1 update reached the test repo (6.1.76) and I have a version for 6.6 ready. I am hoping that the new longterm kernel (specifically 6.6.15) will reach the test repo [0] on Sunday morning.
I wanted to give a heads up in case some people do not want to update right away. From my POV there is nothing problematic that I am aware of, never the less it is the first major longterm kernel update that I am doing.
Cheers, Robert
Are there any plans to have the LT kernel packages available in TW ?
On 19.12.23 14:07, Robert Frohl wrote:
Hi all,
I am looking for feedback on a side project that I have been working on the last couple of months: Introducing a rolling longterm kernel package to Factory.
# Motivation
The previous distribution I used as my daily driver offered a LTS variant of the kernel and that always served me well, if some change in kernel development broke a feature that I was relying on. When I moved to Tumbleweed I felt that this was missing, but because of snapper and file system rollback, the impact was never so severe.
With the announcement of slowroll I had the feeling that having a longterm kernel might fill a gap, for more stable workloads or software packages that have a dependency onto the kernel, but can not keep up with new kernel versions. Therefor I started to look into how feasible it would be to have a longterm kernel in Factory.
# General vision
Having a longterm kernel package that follows the rolling release model and will track the latest longterm kernel, once the stable kernel has moved to a higher version number. The configuration should be as similar as possible to the stable kernel. The kernel packaging should use existing infrastructure and processes that are used for the stable kernel, to avoid re-inventing the wheel.
# Current state and open points
I have a longterm kernel version (6.1.68) available for x86_64 under [0]. This version is using the existing systems and processes. I am now at a state where I think further feedback would be helpful.
Known open points that I want to take care of before trying to get into Factory:
- Move to the new longterm version (6.6) to get a grasp of the process and see what potential fallout the update might have for users - Find out if external kernel modules would have a problem with different kernel versions and if so find a solution [1]
Where this will go is not clear at the moment, I talked with Bernhard and dimstar if there is general interest for a longterm kernel in Factory. It might be an option as a base for slowroll. But there has been no decision on how to proceed. Currently just evaluating if the longterm kernel is feasible for Factory, if openSUSE users would be interested and if a community maintainer can handle the workload, as I am not a kernel developer in my day job.
If someone has a use case that does not depend on external kernel modules and some time over the holidays, I would really appreciate feedback, be it improvements or any other type (also if things work out ok and there are no complaints ;) ).
Cheers, Robert
p.s: without the help and support of others, this little experiment would have been impossible to do, I would like to specifically thank a couple of people for their support and patience with my questions: Michal, Takashi, Jiri and Marcus. I would also like to thank SUSE for the time they make available during hackweek, as I spend some of my time on the longterm kernel.
p.p.s: you can install the longterm kernel by: > zypper addrepo http://download.opensuse.org/repositories/Kernel:/slowroll/standard/Kernel:s... > zypper refresh > zypper install kernel-longterm
[0] http://download.opensuse.org/repositories/Kernel:/slowroll/standard/ [1] https://bugzilla.suse.com/show_bug.cgi?id=1217824
-- Regards, Joe
On 02.02.24 23:38, Joe Salmeri wrote:
On 2/2/24 12:18, Robert Frohl wrote:
Hi all,
small update for the longterm kernel:
earlier today the last 6.1 update reached the test repo (6.1.76) and I have a version for 6.6 ready. I am hoping that the new longterm kernel (specifically 6.6.15) will reach the test repo [0] on Sunday morning.
I wanted to give a heads up in case some people do not want to update right away. From my POV there is nothing problematic that I am aware of, never the less it is the first major longterm kernel update that I am doing.
Cheers, Robert
Are there any plans to have the LT kernel packages available in TW ?
Yes, I was planning to push to Factory in the end, so that TW and slowroll can make use of kernel-longterm. Currently still in testing phase though. Originally planned to move to 6.6 and figure out if there are problems with KPMs. Have not had any time for the KPM part so far. There might also be further problems that I am not aware of yet, that would also need fixes. HTH -- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
Kernel:/slowroll:/Backport is for Leap 15.5? https://download.opensuse.org/repositories/Kernel:/slowroll:/Backport/standa... 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:/
On 05.02.24 19:56, Nikolai Nikolaevskii wrote:
Kernel:/slowroll:/Backport is for Leap 15.5? https://download.opensuse.org/repositories/Kernel:/slowroll:/Backport/standa...
Sorry, only planning for TW and slowroll.
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 they 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. Cheers, Robert -- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
Hi all, bigger update on the timeline, as I have changed my plans a bit. Bernhard asked if it would be possible to speed up the addition to Factory a bit and not wait for the KMP support, because that part was holding back slowroll. I decided last week that the perfect should not stand in the way of the good and therefor changed my plans to submit to Factory before finishing the KMP support. This means that kernel-longterm (6.6.17) should be available in Factory some time tomorrow, but without proper KMP support. I would like to thank all that helped with testing and hope that there are no problems. Testers could just move to the Factory version or continue to use the test repo as it will receive updates a bit earlier, serving as devel project from now on. Cheers, Robert On 02.02.24 18:18, Robert Frohl wrote:
Hi all,
small update for the longterm kernel:
earlier today the last 6.1 update reached the test repo (6.1.76) and I have a version for 6.6 ready. I am hoping that the new longterm kernel (specifically 6.6.15) will reach the test repo [0] on Sunday morning.
I wanted to give a heads up in case some people do not want to update right away. From my POV there is nothing problematic that I am aware of, never the less it is the first major longterm kernel update that I am doing.
Cheers, Robert
On 19.12.23 14:07, Robert Frohl wrote:
Hi all,
I am looking for feedback on a side project that I have been working on the last couple of months: Introducing a rolling longterm kernel package to Factory.
# Motivation
The previous distribution I used as my daily driver offered a LTS variant of the kernel and that always served me well, if some change in kernel development broke a feature that I was relying on. When I moved to Tumbleweed I felt that this was missing, but because of snapper and file system rollback, the impact was never so severe.
With the announcement of slowroll I had the feeling that having a longterm kernel might fill a gap, for more stable workloads or software packages that have a dependency onto the kernel, but can not keep up with new kernel versions. Therefor I started to look into how feasible it would be to have a longterm kernel in Factory.
# General vision
Having a longterm kernel package that follows the rolling release model and will track the latest longterm kernel, once the stable kernel has moved to a higher version number. The configuration should be as similar as possible to the stable kernel. The kernel packaging should use existing infrastructure and processes that are used for the stable kernel, to avoid re-inventing the wheel.
# Current state and open points
I have a longterm kernel version (6.1.68) available for x86_64 under [0]. This version is using the existing systems and processes. I am now at a state where I think further feedback would be helpful.
Known open points that I want to take care of before trying to get into Factory:
- Move to the new longterm version (6.6) to get a grasp of the process and see what potential fallout the update might have for users - Find out if external kernel modules would have a problem with different kernel versions and if so find a solution [1]
Where this will go is not clear at the moment, I talked with Bernhard and dimstar if there is general interest for a longterm kernel in Factory. It might be an option as a base for slowroll. But there has been no decision on how to proceed. Currently just evaluating if the longterm kernel is feasible for Factory, if openSUSE users would be interested and if a community maintainer can handle the workload, as I am not a kernel developer in my day job.
If someone has a use case that does not depend on external kernel modules and some time over the holidays, I would really appreciate feedback, be it improvements or any other type (also if things work out ok and there are no complaints ;) ).
Cheers, Robert
p.s: without the help and support of others, this little experiment would have been impossible to do, I would like to specifically thank a couple of people for their support and patience with my questions: Michal, Takashi, Jiri and Marcus. I would also like to thank SUSE for the time they make available during hackweek, as I spend some of my time on the longterm kernel.
p.p.s: you can install the longterm kernel by: > zypper addrepo http://download.opensuse.org/repositories/Kernel:/slowroll/standard/Kernel:s... > zypper refresh > zypper install kernel-longterm
[0] http://download.opensuse.org/repositories/Kernel:/slowroll/standard/ [1] https://bugzilla.suse.com/show_bug.cgi?id=1217824
-- Security Engineer, SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany, GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) GPG: D29F 82AA 9FD5 9D6E 74B1 6370 089E DB3D 230A 2404
participants (4)
-
Felix Miata -
Joe Salmeri -
Nikolai Nikolaevskii -
Robert Frohl