* Which kernel series to use in the installer and for installed systems?
@ 2021-05-27 17:17 Leo Famulari
2021-05-27 18:10 ` Vagrant Cascadian
0 siblings, 1 reply; 8+ messages in thread
From: Leo Famulari @ 2021-05-27 17:17 UTC (permalink / raw)
To: guix-devel
At the time of the recent 1.3.0 Guix release, the "default" linux-libre
kernel series was the 5.11 series [0]:
------
(define-public linux-libre-version linux-libre-5.11-version)
(define-public linux-libre-pristine-source linux-libre-5.11-pristine-source)
(define-public linux-libre-source linux-libre-5.11-source)
(define-public linux-libre linux-libre-5.11)
------
In upstream parlance [1], 5.11 was a "stable" series, meaning it would
get updates until the next major release, 5.12.
Soon after the Guix 1.3.0 was released, we updated our default kernel to
5.12, because 5.11 became unsupported, as planned.
However, this caused a regression for at least one user [2].
I'm not sure exactly how the situation could be improved. Maybe the
installer and the operating-system declarations that it generates could
instead use one of the "longterm" [1] kernel series?
I'm not totally comfortable steering users to these longterm kernels
series, since they are more buggy and less featureful than newer kernel
series, but at least they do not change very much.
What do you think?
[0] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm?h=v1.3.0#n892
[1] https://www.kernel.org/category/releases.html
[2] https://bugs.gnu.org/48604
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-05-27 17:17 Which kernel series to use in the installer and for installed systems? Leo Famulari
@ 2021-05-27 18:10 ` Vagrant Cascadian
2021-05-27 18:43 ` Leo Famulari
2021-05-27 20:02 ` Mark H Weaver
0 siblings, 2 replies; 8+ messages in thread
From: Vagrant Cascadian @ 2021-05-27 18:10 UTC (permalink / raw)
To: Leo Famulari, guix-devel
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On 2021-05-27, Leo Famulari wrote:
> I'm not sure exactly how the situation could be improved. Maybe the
> installer and the operating-system declarations that it generates could
> instead use one of the "longterm" [1] kernel series?
>
> I'm not totally comfortable steering users to these longterm kernels
> series, since they are more buggy and less featureful than newer kernel
> series, but at least they do not change very much.
>
> What do you think?
Would it be too complicated to include both the latest LTS kernel and
the most recently packaged kernel in the installer, and default to using
the same kernel for the installation?
Then, if one kernel didn't work for someone, they could try the install
with the other kernel without having to download a separate image.
Of course, it bloats the installer having a second kernel on it... and
maybe the increased complexity to explain which to choose would be too
much...
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-05-27 18:10 ` Vagrant Cascadian
@ 2021-05-27 18:43 ` Leo Famulari
2021-05-27 19:36 ` Vagrant Cascadian
2021-05-27 20:02 ` Mark H Weaver
1 sibling, 1 reply; 8+ messages in thread
From: Leo Famulari @ 2021-05-27 18:43 UTC (permalink / raw)
To: Vagrant Cascadian; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
On Thu, May 27, 2021 at 11:10:21AM -0700, Vagrant Cascadian wrote:
> Would it be too complicated to include both the latest LTS kernel and
> the most recently packaged kernel in the installer, and default to using
> the same kernel for the installation?
I'm a bit confused about what you are suggesting? Do you mean, offering
both of those versions in a menu to the user?
> Of course, it bloats the installer having a second kernel on it... and
> maybe the increased complexity to explain which to choose would be too
> much...
The installer does not "include" built packages, aside from what is used
by the installer's OS.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-05-27 18:43 ` Leo Famulari
@ 2021-05-27 19:36 ` Vagrant Cascadian
0 siblings, 0 replies; 8+ messages in thread
From: Vagrant Cascadian @ 2021-05-27 19:36 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On 2021-05-27, Leo Famulari wrote:
> On Thu, May 27, 2021 at 11:10:21AM -0700, Vagrant Cascadian wrote:
>> Would it be too complicated to include both the latest LTS kernel and
>> the most recently packaged kernel in the installer, and default to using
>> the same kernel for the installation?
>
> I'm a bit confused about what you are suggesting? Do you mean, offering
> both of those versions in a menu to the user?
Yes, at the installer's grub (or other bootloader) menu.
>> Of course, it bloats the installer having a second kernel on it... and
>> maybe the increased complexity to explain which to choose would be too
>> much...
>
> The installer does not "include" built packages, aside from what is used
> by the installer's OS.
Yes, but if you're using the installer, it will choose to install *some*
kernel on the installed system, so it could pick the most similar kernel
(e.g. linux-libre vs. linux-libre-lts) on the initial install...
There may be cases where a newer kernel wouldn't run on a particular
piece of hardware, or where the older LTS kernel wouldn't run, so making
it easy to pick between those two seems worth considering if there are
not too many other drawbacks.
So, my answer to the question "which kernel ...?" is ... maybe both!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-05-27 18:10 ` Vagrant Cascadian
2021-05-27 18:43 ` Leo Famulari
@ 2021-05-27 20:02 ` Mark H Weaver
2021-06-02 7:33 ` Efraim Flashner
1 sibling, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2021-05-27 20:02 UTC (permalink / raw)
To: Vagrant Cascadian, Leo Famulari, guix-devel
Hi,
Vagrant Cascadian <vagrant@debian.org> writes:
> Would it be too complicated to include both the latest LTS kernel and
> the most recently packaged kernel in the installer, and default to using
> the same kernel for the installation?
Sounds good to me. More specifically, I would suggest offering the user
a choice between using the latest stable kernel, or using the latest
kernel from the most recent LTS series at the time of installation.
If the user chooses the latter option, the installer would produce an OS
configuration containing "(kernel linux-libre-X.YY)", where X.YY is
latest LTS series at installation time.
The idea is that if they choose the LTS kernel option today,
'linux-libre-5.10' would be put into their OS config, so they would stay
on the 5.10 kernel series until they explicitly update to a later
series. This is a good choice for production systems where stability is
more important than running the latest code, and even for ordinary users
who wish to have control over when major kernel updates are done.
I would recommend avoiding the 'linux-libre-lts' variable, because it
fails to provide the primary benefit that LTS kernels are meant to
provide: the ability to postpone potentially disruptive major kernel
upgrades until a time of the user's choosing, when the user is prepared
for possible breakage. Users who put 'linux-libre-lts' in their OS
configurations should expect that a major kernel upgrade will happen
several years before it is needed, and could happen unexpectedly any
time they upgrade their system. Unless they carefully inspect the
'guix' command output _every_ time they upgrade their system, users of
the 'linux-libre-lts' variable are unlikely to notice a major kernel
upgrade until it has already been done.
Thoughts?
Thanks,
Mark
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-05-27 20:02 ` Mark H Weaver
@ 2021-06-02 7:33 ` Efraim Flashner
2021-06-05 18:09 ` Mark H Weaver
0 siblings, 1 reply; 8+ messages in thread
From: Efraim Flashner @ 2021-06-02 7:33 UTC (permalink / raw)
To: Mark H Weaver; +Cc: Vagrant Cascadian, guix-devel
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
On Thu, May 27, 2021 at 04:02:46PM -0400, Mark H Weaver wrote:
> Hi,
>
> Vagrant Cascadian <vagrant@debian.org> writes:
> > Would it be too complicated to include both the latest LTS kernel and
> > the most recently packaged kernel in the installer, and default to using
> > the same kernel for the installation?
>
> Sounds good to me. More specifically, I would suggest offering the user
> a choice between using the latest stable kernel, or using the latest
> kernel from the most recent LTS series at the time of installation.
>
> If the user chooses the latter option, the installer would produce an OS
> configuration containing "(kernel linux-libre-X.YY)", where X.YY is
> latest LTS series at installation time.
>
> The idea is that if they choose the LTS kernel option today,
> 'linux-libre-5.10' would be put into their OS config, so they would stay
> on the 5.10 kernel series until they explicitly update to a later
> series. This is a good choice for production systems where stability is
> more important than running the latest code, and even for ordinary users
> who wish to have control over when major kernel updates are done.
>
> I would recommend avoiding the 'linux-libre-lts' variable, because it
> fails to provide the primary benefit that LTS kernels are meant to
> provide: the ability to postpone potentially disruptive major kernel
> upgrades until a time of the user's choosing, when the user is prepared
> for possible breakage. Users who put 'linux-libre-lts' in their OS
> configurations should expect that a major kernel upgrade will happen
> several years before it is needed, and could happen unexpectedly any
> time they upgrade their system. Unless they carefully inspect the
> 'guix' command output _every_ time they upgrade their system, users of
> the 'linux-libre-lts' variable are unlikely to notice a major kernel
> upgrade until it has already been done.
>
> Thoughts?
>
> Thanks,
> Mark
>
IIRC the Debian installer offers linux, linux-major.minor and
linux-major.minor.point in the installer. I don't really understand why
and how a newer kernel would make things stop working, but I could see
offering linux-libre, linux-libre-lts and linux-libre-5.10 (using the
1.3.0 release as the example).
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-06-02 7:33 ` Efraim Flashner
@ 2021-06-05 18:09 ` Mark H Weaver
2021-06-06 8:43 ` Efraim Flashner
0 siblings, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2021-06-05 18:09 UTC (permalink / raw)
To: Efraim Flashner; +Cc: Vagrant Cascadian, guix-devel
Hi Efraim,
Efraim Flashner <efraim@flashner.co.il> writes:
> I don't really understand why
> and how a newer kernel would make things stop working,
Newer kernels _usually_ work fine, but occasionally things break, and
that's much more likely to happen when switching to a newer kernel
series. It happened to me quite recently, when a couple of us found
that early 5.12.x kernels would lock up a Thinkpad X200 within minutes
of booting. See <https://bugs.gnu.org/48604>.
For those who can afford to deal with breakage like this at unscheduled
times, the 'linux-libre' variable is likely the best choice. For those
who prefer stability, I recommend 'linux-libre-X.YY' for some LTS series
X.YY.
The 'linux-libre-lts' variable seems to me the worst of both worlds, and
likely to lead to some people getting burned from unexpected kernel
upgrades that they might not have been expecting. If 'linux-libre-lts'
is included as an option, I recommend adding text that makes it clear to
users that automatic upgrades to newer LTS series will happen without
warning, years before such upgrades are needed.
What do you think?
Regards,
Mark
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Which kernel series to use in the installer and for installed systems?
2021-06-05 18:09 ` Mark H Weaver
@ 2021-06-06 8:43 ` Efraim Flashner
0 siblings, 0 replies; 8+ messages in thread
From: Efraim Flashner @ 2021-06-06 8:43 UTC (permalink / raw)
To: Mark H Weaver; +Cc: Vagrant Cascadian, guix-devel
[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]
On Sat, Jun 05, 2021 at 02:09:59PM -0400, Mark H Weaver wrote:
> Hi Efraim,
>
> Efraim Flashner <efraim@flashner.co.il> writes:
> > I don't really understand why
> > and how a newer kernel would make things stop working,
>
> Newer kernels _usually_ work fine, but occasionally things break, and
> that's much more likely to happen when switching to a newer kernel
> series. It happened to me quite recently, when a couple of us found
> that early 5.12.x kernels would lock up a Thinkpad X200 within minutes
> of booting. See <https://bugs.gnu.org/48604>.
>
> For those who can afford to deal with breakage like this at unscheduled
> times, the 'linux-libre' variable is likely the best choice. For those
> who prefer stability, I recommend 'linux-libre-X.YY' for some LTS series
> X.YY.
>
> The 'linux-libre-lts' variable seems to me the worst of both worlds, and
> likely to lead to some people getting burned from unexpected kernel
> upgrades that they might not have been expecting. If 'linux-libre-lts'
> is included as an option, I recommend adding text that makes it clear to
> users that automatic upgrades to newer LTS series will happen without
> warning, years before such upgrades are needed.
>
> What do you think?
>
> Regards,
> Mark
>
I know if I were using the zfs kernel module I'd want to use the most
recent lts release. I like the idea of labeling it something like:
* linux-libre (tracks the latest kernel release)
* linux-libre-lts (tracks most recent long-term support release, with
upgrades to newer versions automatically)
* linux-libre-5.10 (current long-term support release, supported until
December 2026)
I know upstream uses 'stable' to mean the current release, but I
personally find the terminology confusing.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-06-06 8:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-27 17:17 Which kernel series to use in the installer and for installed systems? Leo Famulari
2021-05-27 18:10 ` Vagrant Cascadian
2021-05-27 18:43 ` Leo Famulari
2021-05-27 19:36 ` Vagrant Cascadian
2021-05-27 20:02 ` Mark H Weaver
2021-06-02 7:33 ` Efraim Flashner
2021-06-05 18:09 ` Mark H Weaver
2021-06-06 8:43 ` Efraim Flashner
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).