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
[-- 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 --]
[-- 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 --]
[-- 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 --]
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>.
[-- 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 --]
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>.
[-- 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 --]