Never seen a distro deliver updates this fast.

[Jojobinha_2009]

I mean it's even faster than Arch!
The 5.11.12 kernel was released literally 9 hours ago...

Went to do my usual emerge update and bam!

5.11.12 is here up and running already!


Love this distro!

[eccerr0r]

Okay, this is getting ridiculous, got 5.4 -> 5.10 -> 5.11 stabilized in a matter of weeks... this isn't "stable" ...

[NeddySeagoon]

eccerr0r,

5.4 and 5.10 are LTS kernels. 5.11 is not.
That looks a bit odd.

[eccerr0r]

I guess I'm assuming that it really got stabilized, I didn't check... but the 5.4 -> 5.10 transition did happen fairly recently, and if 5.11 did as well, that's just weird.

(I had been running 4.14.* ... and *just* updated to 5.4 on all my boxes... more electricity to burn... )

[asturm]

5.11 is not stable. 5.4 was stable for a *long* time.

Code: Select all

$ eshowkw gentoo-sources
Keywords for sys-kernel/gentoo-sources:
              |                             |   u           |  
              | a   a     p s   a   r       |   n           |  
              | m   r h   p p   l i i m m s | e u s         | r
              | d a m p p c a x p a s 6 i 3 | a s l         | e
              | 6 r 6 p p 6 r 8 h 6 c 8 p 9 | p e o         | p
              | 4 m 4 a c 4 c 6 a 4 v k s 0 | i d t         | o
--------------+-----------------------------+---------------+-------
   4.4.257    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.4.257   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.261    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.261   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.262    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.262   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.263    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.263   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.264    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.4.264   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.265    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.265   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.257    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.9.257   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.261    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.261   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.262    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.262   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.263    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.263   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.264    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.9.264   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.265    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.265   | gentoo
--------------+-----------------------------+---------------+-------
  4.14.221    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.14.221  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.225    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.225  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.226    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.226  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.227    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.227  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.228    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.14.228  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.229    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.229  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.175    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.19.175  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.181    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.181  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.182    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.182  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.183    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.183  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.184    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.19.184  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.185    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.185  | gentoo
--------------+-----------------------------+---------------+-------
    5.4.97    | + + + ~ + + + + ~ ~ o o ~ ~ | 6 o 5.4.97    | gentoo
--------------+-----------------------------+---------------+-------
   5.4.105    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.105   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.106    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.106   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.107    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.107   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.108    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.108   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.109    | + + + ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 5.4.109   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.110    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.110   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.24    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.24   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.25    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.25   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.26    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.26   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.27    | + + + ~ ~ ~ + + ~ ~ ~ o ~ ~ | 6 o 5.10.27   | gentoo
--------------+-----------------------------+---------------+-------
[I]5.10.28    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.28   | gentoo
--------------+-----------------------------+---------------+-------
    5.11.6    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.6    | gentoo
--------------+-----------------------------+---------------+-------
    5.11.7    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.7    | gentoo
--------------+-----------------------------+---------------+-------
    5.11.8-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.8-r1 | gentoo
--------------+-----------------------------+---------------+-------
    5.11.9    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.9    | gentoo
--------------+-----------------------------+---------------+-------
   5.11.10    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.10   | gentoo
--------------+-----------------------------+---------------+-------
   5.11.11    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.11   | gentoo
--------------+-----------------------------+---------------+-------
   5.11.12    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.12   | gentoo

[Hu]

If I recall correctly, Gentoo marks LTS kernels as stable, and non-LTS kernels as testing. Whether any of those series are stable enough is a function of upstream's project management. In theory, both 5.4 and 5.10 should be stable, because they are built on their respective Linus releases, with appropriate backports from later kernels. If you're happy with the 5.4 line's hardware support and software features, you can stay in that line for as long as upstream releases LTS kernels for it.

[Ionen]

Gentoo does their own testing as well and won't stabilize a kernel if there's known issues that may impact a lot of users (5.10.x notably waited a while because of an intel gpu issue I recall), nor would it ever get stabilized without (at least) the usual 30-days period unless a major issue was found in stable and there's an urgency.

And as already stated, 5.11 is not stabilized. Note that even on ~testing you can use some stable packages (like the kernel) by using '-~amd64' in package.accept_keywords if preferred.

[eccerr0r]

Ok good...sigh still need to update again...

[figueroa]

I only recently upgraded to the 5.4 kernel series, for LTS reasons. I was on 4.4 and 4.9 both for a long time and now plan to stay with 5.4 on my main system for at least a couple of years. I have the following in /etc/portage/package.mask:

Code: Select all

>=sys-kernel/gentoo-sources-5.5

I always upgrade pretty quickly to new stable point releases.

On my #2 machine that only does server duties as well as a remote server, I'm still at 4.9 and it meets all my needs. I won't change either of those till obsolescence draws closer in late 2022. Everything works great and I don't need any grief. They would still be on 4.4 except that I got itchy feet back when Spectre and Meltdown became new things. The LAST think I need to do is be on the bleeding edge of new kernels.

[sdauth]

I'm doing the same as figueroa.
Masking all sys-kernel/gentoo-sources :
echo "sys-kernel/gentoo-sources" >> /etc/portage/package.mask
and only unmask the kernel series I want, and nothing else :
echo "=sys-kernel/gentoo-sources-5.4*" >> /etc/portage/package.unmask

From what I read, 5.4 LTS is going to last longer than 5.10 LTS so I'm sticking with 5.4. Of course pure stable because I don't want to build a new kernel every week.

Back with the thread, yeah some packages are fast to receive updates (even on "stable" channel) but sometimes when looking at my accept.keywords file I regret the lack of maintainer for some packages. I try to always open a "version bump" bug when some packages are old. I'm not confident enough to do the maintainer job myself.

[Goverp]

IIUC just 'cos it's LTS doesn't mean there won't be fixes (backported from latest and greatest) every week, but they should be relatively painless.
There may be fewer changes, but they still happen. 5.10 has had 28 updates; 5.4, 110, and 4.9 is up to 256!

[sdauth]

Yes of course. I mean I don't put sys-kernel/gentoo-sources in accept.keywords, I let Gentoo kernel team to stabilize when needed. The default way when you're on stable to sum up.
This way, kernel bump only happens once a month (sometimes more or sometimes less when there is a sec issue or whatever)

[pietinger]

[...]I have the following in /etc/portage/package.mask:

Code: Select all

>=sys-kernel/gentoo-sources-5.5

I highly recommend to add this also:

Code: Select all

>=sys-kernel/linux-headers-5.5

[Ionen]

[...]I have the following in /etc/portage/package.mask:

Code: Select all

>=sys-kernel/gentoo-sources-5.5

I highly recommend to add this also:

Code: Select all

>=sys-kernel/linux-headers-5.5

Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

Plus there's some packages that won't build with old headers like pax-utils-1.2.9 needs >=5.8
Edit: and pax-utils' requirement was needed for a glibc-2.33 fix, not an issue right now if still using 2.32 but eventually it'll come bite when stable

[pietinger]

Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

Really ? I cant believe.

You know what happens if you compile a programm against a header-file telling there is a new abi in the kernel ... and the kernel itself doesnt have it ... ?!

[Ionen]

Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

Really ? I cant believe.

https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F

[figueroa]

IIUC just 'cos it's LTS doesn't mean there won't be fixes (backported from latest and greatest) every week, but they should be relatively painless.
There may be fewer changes, but they still happen. 5.10 has had 28 updates; 5.4, 110, and 4.9 is up to 256!

Not every point releases comes into the stable tree. That's been making stable kernel maintenance more like a monthly activity, more or less. I'm happy with that pace of activity.

[timeBandit]

You know what happens if you compile a programm against a header-file telling there is a new abi in the kernel ... and the kernel itself doesnt have it ... ?!

Absolutely nothing, unless said program actually calls the new ABI. Code written to the pre-existing interface would not notice any additions. I could amend my kernel headers with last week's grocery list expressed as a series of function prototypes*, rebuild my entire system, and nothing untoward would happen--because no code on my system orders groceries.

*Grocery-purchasing API specification is left as an exercise for the reader. Grocery list provided on request.

[Hu]

If the code did try to use that new ABI, it would get ENOSYS (for missing system calls) or possibly some other error for missing extensions to existing system calls. It is a bug if the caller (1) works properly with old headers and (2) fails when using new headers with an old kernel. Callers are permitted to depend on new features and simply fail when run on old kernels, but if they can run on an old kernel, then they must run correctly even when made aware of extensions that the running kernel lacks. Typically, glibc handles this transparently by observing that the running kernel lacks the new feature, and falling back to an older system call that can do the job.

[Goverp]

I'd forgotten the slower rate of updates on a stable kernel; my new box needed ~arch a year or so ago. Now it's a case of emerge --update; make oldconfig; make install every week (+ other bits of course); at least the new box is so fast it still takes less time.

[Ionen]

Typically, glibc handles this transparently by observing that the running kernel lacks the new feature, and falling back to an older system call that can do the job.

If "really" wanted to, removing that support would involve using --enable-kernel= on glibc, in case of glibc-2.33 it has code specific to kernels up to 5.8.0 on amd64 (5.4.0 for 2.32), if you wanted to strip all the old cruft it'd be --enable-kernel=5.8.0 and then "now" it wouldn't run on old kernels -- not that this is really worthwhile.

By default it still uses =3.2.0, so even if you use linux-headers-5.11 it should run on a 3.2.0 kernel. So it's a pretty wide range of old kernels even if wanted to chroot using an ancient minimal cd with a old kernel.

[pietinger]

Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

I had read this recommendation, but I had in my mind that it is wrong to use newer linux headers than your used kernel version. But I was not able to remember why I had this in my mind. By accident I found today the source:

Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel.

https://www.kernel.org/doc/html/latest/ ... stall.html

So, we have two contradictory recommendations ?

[Hu]

The other part of Ionen's post addresses your concern. A user program which uses kernel headers version 1 cannot see kernel features introduced in kernel headers version 2. A user program which uses kernel headers version 2 can see features from both version 1 and version 2, and can choose which to use. A kernel matching the kernel header version 1 interface does not offer version 2 features, and so cannot run a program which requires those features. However, as I said in my post that Ionen quoted, the user program could choose to try version 2 and, if that fails, use version 1 instead of aborting the program. As Ionen's post elaborates, glibc has internal support for exactly this, and the packager can choose how much of that internal support to enable. With the =3.2.0 that Ionen mentions, glibc will include enough fallbacks to try older version features all the way down to what Linux v3.2.0 supported, but presumably can have a hard requirement on v3.2.0 features, and fail outright on v3.1.0. If the package picks a newer --enable-kernel= when building glibc, fewer fallbacks are included, and the resulting glibc binaries can therefore have a hard requirement on a newer kernel, all the way up to the version specified by the packager. Assuming no bugs in the glibc support, this means you can upgrade kernel headers arbitrarily far into the future and, as long as you keep the --enable-kernel= parameter unchanged, you retain support for the older kernels.

Since glibc supports this and is the standard path to make system calls (via libc wrapper functions), most user applications are automatically as compatible as the glibc on which they run. Only special programs that bypass glibc and use kernel headers directly are at risk of having a higher minimum due to a kernel header upgrade.

[pietinger]

Hu,
thank you very much for this detailed explanation.

[pietinger]

I thought about:

[...] Only special programs that bypass glibc and use kernel headers directly are at risk of having a higher minimum due to a kernel header upgrade.

... and how Gentoo is handling linux-headers: If you emerge stable gentoo-sources (6.1 at the moment) you will get (automatically) linux-headers 6.1 ... and not 6.3 (newest at the moment).

So, is it correct if I recommend to not use the newest linux-headers ... or does Gentoo handles linux-headers wrong ?