Mailing List Archive

Greetings,

On Friday, 2024-01-05 18:46:09 +0100, I myself wrote:

> ...
> since a few month or so off and on my laptop fails to resume from hiber-
> nation due to the "dirty bit" being set on the ext4 "/home" partition.

I was reading this flickering by on the screen, and it wasn't quite cor-
rect. Meanwhile I found this in my "openrc.log":

fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
Not automatically fixing this.
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
*** Filesystem was changed ***
Writing changes.
/dev/sda1: 368 files, 116600/258078 clusters
/dev/sdb1: recovering journal
/dev/sdb1: Clearing orphaned inode 54789026 (uid=1000, gid=1000, mode=0100600, size=32768)
/dev/sdb1: Clearing orphaned inode 54788311 (uid=1000, gid=1000, mode=0100600, size=553900)
/dev/sdb1: clean, 172662/61054976 files, 36598898/244190385 blocks
* Filesystems repaired

So one cause always is some problem on disk "/dev/sda1/" ("/boot/") and
another cause are one or more orphaned inodes on disk "/dev/sdb1/"
("/home/"). But while the values of offset, original and backup for
"/dev/sda1/" are always the same when this happens, the number of or-
phaned inodes on "/dev/sdb1/" and the inodes itself change from occur-
rence to occurrence. Besides it only happens sporadically when resuming
from hibernation, not every time. More precisely, the problem surfaces
when resuming from hibernation but could as well be caused during the
hibernation process itself.

Does this ring some bell somewhere what could cause this?

Sincerely,
Rainer

On Sunday, 14 April 2024 19:41:41 BST Dr Rainer Woitok wrote:
> Greetings,
>
> On Friday, 2024-01-05 18:46:09 +0100, I myself wrote:
> > ...
> > since a few month or so off and on my laptop fails to resume from hiber-
> > nation due to the "dirty bit" being set on the ext4 "/home" partition.
>
> I was reading this flickering by on the screen, and it wasn't quite cor-
> rect. Meanwhile I found this in my "openrc.log":
>
> fsck.fat 4.2 (2021-01-31)
> There are differences between boot sector and its backup.
> This is mostly harmless. Differences: (offset:original/backup)
> 65:01/00
> Not automatically fixing this.
> Dirty bit is set. Fs was not properly unmounted and some data may be
> corrupt. Automatically removing dirty bit.
> *** Filesystem was changed ***
> Writing changes.
> /dev/sda1: 368 files, 116600/258078 clusters

Why have you set your /boot to be mounted at boot?

You can run 'fsck.fat -v /dev/sda1' after you unmount it to remove the dirty
bit (if not already removed) and then change your fstab to 'noauto'. Just
remember to remount /boot before you make any changes to your boot manager/
kernels.


> /dev/sdb1: recovering journal
> /dev/sdb1: Clearing orphaned inode 54789026 (uid=1000, gid=1000,
> mode=0100600, size=32768) /dev/sdb1: Clearing orphaned inode 54788311
> (uid=1000, gid=1000, mode=0100600, size=553900) /dev/sdb1: clean,
> 172662/61054976 files, 36598898/244190385 blocks * Filesystems repaired
>
> So one cause always is some problem on disk "/dev/sda1/" ("/boot/") and
> another cause are one or more orphaned inodes on disk "/dev/sdb1/"
> ("/home/"). But while the values of offset, original and backup for
> "/dev/sda1/" are always the same when this happens, the number of or-
> phaned inodes on "/dev/sdb1/" and the inodes itself change from occur-
> rence to occurrence. Besides it only happens sporadically when resuming
> from hibernation, not every time. More precisely, the problem surfaces
> when resuming from hibernation but could as well be caused during the
> hibernation process itself.
>
> Does this ring some bell somewhere what could cause this?
>
> Sincerely,
> Rainer

Unlike the /boot partition, the /home partition has data written to it
regularly. The ext4 fs does not perform atomic writes - it is not a CoW fs.
Therefore a sudden unsync'ed shutdown could leave it in a state of corruption
- IF for some reason data in memory is not either fully written to disk or
retained in memory. The way ACPI interacts with firmware *should* ensure the
S3 system state does not suspend I/O operations halfway through an inline
write operation ... but ... MoBo firmware can be notoriously buggy and is
typically frozen/abandoned within a couple of years by the OEMs. In addition,
kernel code changes and any previous symbiosis with the firmware can fall
apart with a later kernel release.

On one PC of mine, with the same MoBo/CPU and the same version firmware, I
have over the years experienced a whole repertoire of random problems resuming
from suspend. At this point in time I avoid placing this PC in sleep, because
it always crashes with a Firefox related segfault, some time after waking up.

Check if the situation with /dev/sdb1 improves when you leave your /boot
unmounted. This may make more process time available for the system to finish
I/O operations, which may then allow /dev/sdb1 to suspend cleanly.

Michael,

On Monday, 2024-04-15 12:48:34 +0100, you wrote:

> ...
> Why have you set your /boot to be mounted at boot?

Well, I think, I then just followed the Gentoo Handbook. But I see your
point of saving time which could be better used to successfully unmount
the "/home/" partition. I'll change my "/etc/fstab" file as well as a
few of my scripts. Thanks for pointing that out :-)

> ...
> MoBo firmware can be notoriously buggy and is
> typically frozen/abandoned within a couple of years by the OEMs. In addition,
> kernel code changes and any previous symbiosis with the firmware can fall
> apart with a later kernel release.

Hm, this sounds a bit like "never change your running kernel", doesn't
it? But this brings up two related questions:

1. Why does Gentoo not somehow mark LTS kernels either in the version
number or in the slot name? This would make it easier to prevent the
installation of too modern kernels.

2. I'm building new kernels with "make olddefconfig" rather than "make
oldconfig" because I thought providing default values to new configu-
ration variables is a good idea. But what precisely does "make old-
config" do with new configuration variables instead? Just leaving
them out? But what's the difference between not defining a configu-
ration variable and setting it to a default value? Or is "make old-
config" really the way to generate more conservative kernels which do
not as quickly overburden aging motherboards?

Sincerely,
Rainer

On Tuesday, 16 April 2024 10:04:43 BST Dr Rainer Woitok wrote:
> Michael,
>
> On Monday, 2024-04-15 12:48:34 +0100, you wrote:
> > ...
> > Why have you set your /boot to be mounted at boot?
>
> Well, I think, I then just followed the Gentoo Handbook. But I see your
> point of saving time which could be better used to successfully unmount
> the "/home/" partition. I'll change my "/etc/fstab" file as well as a
> few of my scripts. Thanks for pointing that out :-)
>
> > ...
> >
> > MoBo firmware can be notoriously buggy and is
> >
> > typically frozen/abandoned within a couple of years by the OEMs. In
> > addition, kernel code changes and any previous symbiosis with the
> > firmware can fall apart with a later kernel release.
>
> Hm, this sounds a bit like "never change your running kernel", doesn't
> it?

Not really, because a newer kernel has any security patches, plus it can
include bug fixes. You won't know if a later release fixes or breaks
something on your system until you tried it.


> But this brings up two related questions:
>
> 1. Why does Gentoo not somehow mark LTS kernels either in the version
> number or in the slot name? This would make it easier to prevent the
> installation of too modern kernels.

My understanding is the gentoo-sources kernels are aligned with the LTS
upstream releases.


> 2. I'm building new kernels with "make olddefconfig" rather than "make
> oldconfig" because I thought providing default values to new configu-
> ration variables is a good idea.

It is a good idea if the new config items are something you need/want on your
system and in addition if the default setting suits your needs.


> But what precisely does "make old-
> config" do with new configuration variables instead? Just leaving
> them out? But what's the difference between not defining a configu-
> ration variable and setting it to a default value? Or is "make old-
> config" really the way to generate more conservative kernels which do
> not as quickly overburden aging motherboards?

The make oldconfig script will identify new config items not present in your
old kernel config, show which is the default option and ask you to
interactively select which one you prefer; e.g.

SPECULATION_MITIGATIONS [Y/n/m/?] (NEW)

The default option above has been identified as Y, if the devs have determined
this is a safe default for the arch. You can hit Enter to select Y, or type
'n' for no, 'm' for module, or '?' to read the extended description and help
for this option before you make up your mind.

With make olddefconfig the option 'Y' will be automatically selected without
asking your input.

Dr Rainer Woitok wrote:
> Michael,
>
> On Monday, 2024-04-15 12:48:34 +0100, you wrote:
>
>> ...
>> Why have you set your /boot to be mounted at boot?
> Well, I think, I then just followed the Gentoo Handbook. But I see your
> point of saving time which could be better used to successfully unmount
> the "/home/" partition. I'll change my "/etc/fstab" file as well as a
> few of my scripts. Thanks for pointing that out :-)
>
>> ...
>> MoBo firmware can be notoriously buggy and is
>> typically frozen/abandoned within a couple of years by the OEMs. In addition,
>> kernel code changes and any previous symbiosis with the firmware can fall
>> apart with a later kernel release.
> Hm, this sounds a bit like "never change your running kernel", doesn't
> it? But this brings up two related questions:
>
> 1. Why does Gentoo not somehow mark LTS kernels either in the version
> number or in the slot name? This would make it easier to prevent the
> installation of too modern kernels.
>
> 2. I'm building new kernels with "make olddefconfig" rather than "make
> oldconfig" because I thought providing default values to new configu-
> ration variables is a good idea. But what precisely does "make old-
> config" do with new configuration variables instead? Just leaving
> them out? But what's the difference between not defining a configu-
> ration variable and setting it to a default value? Or is "make old-
> config" really the way to generate more conservative kernels which do
> not as quickly overburden aging motherboards?
>
> Sincerely,
> Rainer


I rarely update my kernel given I don't reboot much.  I am working on
that tho.  I've updated my kernel three times recently but never
rebooted to use any of them.  If power fails and I have to reboot, they
are there at least.  All of us should update when we can. 

I been using Gentoo since around 2003.  I started out making my kernel
from scratch and updating the manual way.  I also install the manual way
with my own naming scheme, just close enough for dracut and grub to
recognize them.  I've always used make oldconfig and for most of the
driver questions, I answer no.  Given I start with a kernel config that
already contains everything I need, it is rare that I need anything
new.  So, I rarely need any of the new drivers.  You are likely the
same.  I think there is a option for it to default to no or yes for all
the questions automatically but not all questions are yes or no and
sometimes you may need a yes.  To me, it's best to use make oldconfig
and answer each question.  That way you can catch something you can use
but you also catch those questions that need a numbered option, 1, 2, 3,
4 or something. 

If you update often, it shouldn't take long answer the questions.  If
you do like me and don't update often, it may take longer but no more
time than it would if you updated often and added all the time
together.  As far as I know, if one manually updates their kernel, make
oldconfig is the safest and recommended method.  You are prompted for
new drivers/options and can see if they apply to you or not.  If you
don't want to update that way, I think there is a kernel that does it's
own thing.  I think it is sort of like boot media uses.  If the time
needed to answer all the questions isn't there, that may be a option to
look into.  It's called genkernel.  I've never used it but read it works. 

In short, make oldconfig is the recommended way as far as I know.  In my
opinion, it is the safest way to know what you are going to get.  Links
for more info.

https://wiki.gentoo.org/wiki/Kernel/Upgrade

https://wiki.gentoo.org/wiki/Kernel/Configuration

Someone else may have a different opinion, even a better one.  This is
how I always do it and kernel failure is rare.  Hope it helps. 

Dale

:-)  :-) 

On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:

> If you update often, it shouldn't take long answer the questions. If
> you do like me and don't update often, it may take longer but no more
> time than it would if you updated often and added all the time
> together. As far as I know, if one manually updates their kernel, make
> oldconfig is the safest and recommended method. You are prompted for
> new drivers/options and can see if they apply to you or not. If you
> don't want to update that way, I think there is a kernel that does it's
> own thing. I think it is sort of like boot media uses. If the time
> needed to answer all the questions isn't there, that may be a option to
> look into. It's called genkernel. I've never used it but read it works.

The sys-kernel/genkernel package will automatically build & install your
kernel and initramfs in /boot, but it will NOT prepare a kernel configuration
tuned to your hardware and desired options. It uses a generic default
configuration safe for most circumstances. The user can tweak the default
configuration to suit their needs and genkernel will use that.

For quick(er) and automated kernel update and installation there are the
gentoo *distribution kernels*:

https://wiki.gentoo.org/wiki/Project:Distribution_Kernel


> In short, make oldconfig is the recommended way as far as I know. In my
> opinion, it is the safest way to know what you are going to get. Links
> for more info.
>
> https://wiki.gentoo.org/wiki/Kernel/Upgrade
>
> https://wiki.gentoo.org/wiki/Kernel/Configuration
>
> Someone else may have a different opinion, even a better one. This is
> how I always do it and kernel failure is rare. Hope it helps.
>
> Dale
>
> :-) :-)

Michael wrote:
> On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:
>
>> If you update often, it shouldn't take long answer the questions. If
>> you do like me and don't update often, it may take longer but no more
>> time than it would if you updated often and added all the time
>> together. As far as I know, if one manually updates their kernel, make
>> oldconfig is the safest and recommended method. You are prompted for
>> new drivers/options and can see if they apply to you or not. If you
>> don't want to update that way, I think there is a kernel that does it's
>> own thing. I think it is sort of like boot media uses. If the time
>> needed to answer all the questions isn't there, that may be a option to
>> look into. It's called genkernel. I've never used it but read it works.
> The sys-kernel/genkernel package will automatically build & install your
> kernel and initramfs in /boot, but it will NOT prepare a kernel configuration
> tuned to your hardware and desired options. It uses a generic default
> configuration safe for most circumstances. The user can tweak the default
> configuration to suit their needs and genkernel will use that.
>
> For quick(er) and automated kernel update and installation there are the
> gentoo *distribution kernels*:
>
> https://wiki.gentoo.org/wiki/Project:Distribution_Kernel
>
>
>

I thought genkernel was the one.  Looking at your link, that would be a
option more closely to what I thought genkernel was.  So, genkernel
requires more effort than I thought and distribution kernel is the more
"automatic" way.  Now to remember that.  :/ 

I still like my old way.  It works.  It's rare that it fails.  It's been
years since I couldn't boot up due to a bad kernel.  Still good to have
options tho.  Not everyone is like me.  Thank goodness for that.  ROFL 

Dale

:-)  :-) 

Michael,

On Tuesday, 2024-04-16 11:15:07 +0100, you wrote:

> ...
> > But this brings up two related questions:
> >
> > 1. Why does Gentoo not somehow mark LTS kernels either in the version
> > number or in the slot name? This would make it easier to prevent the
> > installation of too modern kernels.
>
> My understanding is the gentoo-sources kernels are aligned with the LTS
> upstream releases.

Right, they use the same version numbers. But you can't see from just
looking at the available "gentoo-sources" which one is LTS and which one
is not. You have to consult "https://www.kernel.org/" to get this in-
formation.

> ...
> The make oldconfig script will identify new config items not present in your
> old kernel config, show which is the default option and ask you to
> interactively select which one you prefer; e.g.
>
> SPECULATION_MITIGATIONS [Y/n/m/?] (NEW)
>
> The default option above has been identified as Y, if the devs have determined
> this is a safe default for the arch. You can hit Enter to select Y, or type
> 'n' for no, 'm' for module, or '?' to read the extended description and help
> for this option before you make up your mind.

Bingo! This is exactly the information I somehow wasn't able to find in
my early Gentoo days! You made my day :-)

Sincerely,
Rainer

On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> > My understanding is the gentoo-sources kernels are aligned with the LTS
> > upstream releases.
>
> Right, they use the same version numbers. But you can't see from just
> looking at the available "gentoo-sources" which one is LTS and which one
> is not. You have to consult "https://www.kernel.org/" to get this in-
> formation.

Only LTS kernels get stabilised, so this information is readily available.

Regards,
Arve

On 4/16/24 7:15 AM, Michael wrote:
> On Tuesday, 16 April 2024 11:55:20 BST Dale wrote:
>> If you update often, it shouldn't take long answer the questions. If
>> you do like me and don't update often, it may take longer but no more
>> time than it would if you updated often and added all the time
>> together. As far as I know, if one manually updates their kernel, make
>> oldconfig is the safest and recommended method. You are prompted for
>> new drivers/options and can see if they apply to you or not. If you
>> don't want to update that way, I think there is a kernel that does it's
>> own thing. I think it is sort of like boot media uses. If the time
>> needed to answer all the questions isn't there, that may be a option to
>> look into. It's called genkernel. I've never used it but read it works.
> The sys-kernel/genkernel package will automatically build & install your
> kernel and initramfs in /boot, but it will NOT prepare a kernel configuration
> tuned to your hardware and desired options. It uses a generic default
> configuration safe for most circumstances. The user can tweak the default
> configuration to suit their needs and genkernel will use that.
I manually run make xconfig (after running make olddefconfig) and have
genkernel set to not use it's default config, sticking to the .config in
the kernel tree (/usr/src/linux.)  That's been working fine for me for
many years.

On 2024-04-16, Arve Barsnes <arve.barsnes@gmail.com> wrote:
> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>> > My understanding is the gentoo-sources kernels are aligned with the LTS
>> > upstream releases.
>>
>> Right, they use the same version numbers. But you can't see from just
>> looking at the available "gentoo-sources" which one is LTS and which one
>> is not. You have to consult "https://www.kernel.org/" to get this in-
>> formation.
>
> Only LTS kernels get stabilised, so this information is readily available.

"Stablized" as in the corresponding gentoo-sources ebuild is marked as
stable. [.Not to be confused with Linux "stable" kernels -- not all of
which end up with LTS status.]

Getnoo-sources also includes "stable" but not "LTS" Linux kernels, but
the gentoo-sources ebuild for those is always "testing".

IOW, if you install gentoo-sources, and don't keyword it to allow
"testing" ebuilds, then you won't get anything other than LTS kernel
sources.

Arve Barsnes wrote:
> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>>> My understanding is the gentoo-sources kernels are aligned with the LTS
>>> upstream releases.
>> Right, they use the same version numbers. But you can't see from just
>> looking at the available "gentoo-sources" which one is LTS and which one
>> is not. You have to consult "https://www.kernel.org/" to get this in-
>> formation.
> Only LTS kernels get stabilised, so this information is readily available.
>
> Regards,
> Arve

I've never understood what is supported long term either.  I use
gentoo-sources.  I've never figured out just how to pick a kernel that
is supposed to be stable for the larger version.  In other words, only
security and bug fixes, no new hardware.  Right now, 6.8.5 is the
highest version in the tree here but there are more versions of it to
come.  So, I tend to go back to 6.7.X and pick the highest version of
that.  The first two digits used to mean something but I think that
changed a long time ago. 

I try to avoid the absolute latest because my video drivers tend to lag
behind a little.  They won't emerge for anything very new sometimes. 
That's why I go back a little as described above.  Thing is, I have no
idea if that is the right way or if it really even matters if I pick
6.8.1 over 6.7.12 or vice versa. 

I wish they were clearly marked somehow myself.  Something in the name
that shows it is stable.  Given I rarely have problems with kernels,
maybe none of this matters.  Thing is, I plan to build a new rig soon. 
Might help then.  Maybe. 

Dale

:-)  :-) 

Grant Edwards wrote:
> On 2024-04-16, Arve Barsnes <arve.barsnes@gmail.com> wrote:
>> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
>>>> My understanding is the gentoo-sources kernels are aligned with the LTS
>>>> upstream releases.
>>> Right, they use the same version numbers. But you can't see from just
>>> looking at the available "gentoo-sources" which one is LTS and which one
>>> is not. You have to consult "https://www.kernel.org/" to get this in-
>>> formation.
>> Only LTS kernels get stabilised, so this information is readily available.
> "Stablized" as in the corresponding gentoo-sources ebuild is marked as
> stable. [.Not to be confused with Linux "stable" kernels -- not all of
> which end up with LTS status.]
>
> Getnoo-sources also includes "stable" but not "LTS" Linux kernels, but
> the gentoo-sources ebuild for those is always "testing".
>
> IOW, if you install gentoo-sources, and don't keyword it to allow
> "testing" ebuilds, then you won't get anything other than LTS kernel
> sources.


That's some helpful info.  That helps me too. 

Dale

:-)  :-) 

On 2024-04-16, Dale <rdalek1967@gmail.com> wrote:

> I've never understood what is supported long term either.  I use
> gentoo-sources.  I've never figured out just how to pick a kernel that
> is supposed to be stable for the larger version.  In other words, only
> security and bug fixes, no new hardware.  Right now, 6.8.5 is the
> highest version in the tree here but there are more versions of it to
> come.  So, I tend to go back to 6.7.X and pick the highest version of
> that.  The first two digits used to mean something but I think that
> changed a long time ago.

Any gentoo-soruces ebuild that's "stable" is an upstream LTS kernel.

The 6.8 version of gentoo-sources are all "testing". They're "stable"
on kernel.org, but theyre _not_ LTS. I think I read that 6.8 is
expected to become the next LTS, but I don't really pay attention.

> I try to avoid the absolute latest because my video drivers tend to lag
> behind a little.  They won't emerge for anything very new sometimes. 
> That's why I go back a little as described above.  Thing is, I have no
> idea if that is the right way or if it really even matters if I pick
> 6.8.1 over 6.7.12 or vice versa.

Neither are stable in Gentoo. Neither are longterm on kernel.org.
6.8 is stable on kernel.org. 6.7 is EOL on kernel.org. I would only
choose 6.7 as a last resort. I would only choose 6.8 if the latest
longterm (6.6) won't work.

> I wish they were clearly marked somehow myself.  Something in the name
> that shows it is stable.  Given I rarely have problems with kernels,
> maybe none of this matters.  Thing is, I plan to build a new rig soon. 
> Might help then.  Maybe. 

Look at

https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

The ones in green are the kernel.org "longterm" supported kernel
versions that are stable in Gentoo.

Here you can see which ones are lonterm, stable, mainline, and EOL
upstream:

https://kernel.org/

I would never run something that's not longterm unless there's a
specific reason you have to choose something else. If you have to pick
something that's not longterm, go with "stable" and not EOL if you
can.

Arve,

On Tuesday, 2024-04-16 15:53:48 +0200, you wrote:

> ...
> Only LTS kernels get stabilised, so this information is readily available.

I'm sure I don't understand this: According to "https://www.kernel.org/"
kernel 6.6.27 is "longterm", but according to "eix" the most recent
6.6.* kernels are 6.6.22 and 6.6.23 which both are non-stable (well, I
ran my last "sync" immediately before the profile upgrade, so this might
not be current). I'm still using stable kernel 6.6.13 as my backup ker-
nel, but this kernel is no longer provided by Gentoo. So, what precise-
ly does LTS or "longterm" mean?

But, to get back to the beginning of this discussion: if there is a risk
that my aging hardware possibly can less and less cope with newer and
newer kernels, should I put something like

>=sys-kernel/gentoo-sources-6.7.0

into file "package.mask" to stay with "longterm" 6.6.* kernels?

Sincerely,
Rainer

On 2024-04-16, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> Arve,
>
> On Tuesday, 2024-04-16 15:53:48 +0200, you wrote:
>
>> ...
>> Only LTS kernels get stabilised, so this information is readily available.
>
> I'm sure I don't understand this: According to "https://www.kernel.org/"
> kernel 6.6.27 is "longterm", but according to "eix" the most recent
> 6.6.* kernels are 6.6.22 and 6.6.23 which both are non-stable (well, I
> ran my last "sync" immediately before the profile upgrade, so this might
> not be current). I'm still using stable kernel 6.6.13 as my backup ker-
> nel, but this kernel is no longer provided by Gentoo. So, what precise-
> ly does LTS or "longterm" mean?

That means that all gentoo-sources stable kernels are "longterm"
kernel versions on kernel.org. It does not mean that all "longterm"
kernel versions from kernel.org are available as "stable" in
gentoo-sources.

It is a statement that "gentoo-sources stable" is a subset of
"kernel.org longterm".

It is not a statement that the two sets are identical.

In other words:

"ONLY LTS kernels get stabilized."

is a different statement from

"ALL LTS kernels get stabilized."

The former is true. The latter is not.

> But, to get back to the beginning of this discussion: if there is a
> risk that my aging hardware possibly can less and less cope with
> newer and newer kernels, should I put something like
>
> >=sys-kernel/gentoo-sources-6.7.0
>
> into file "package.mask" to stay with "longterm" 6.6.* kernels?

Yes: if you want to avoid getting upgraded to 6.8 when it gets
kernel.org "longterm" status and gentoo-sources "stable" status, then
a statement like that in in package.mask will keep you on
gentoo-sources 6.6 kernels (which are "longterm" on kernel.org).

Again: not all longterm 6.6.x kernel versions get marked as "stable"
for gentoo-sources. If you have not enabled the testing keyword for
gentoo-sources, then you'll only get the 6.6.x kernel versions that
the gentoo-sources maintainers have declared as "stable".

--
Grant

On Tuesday, 16 April 2024 20:26:25 BST Grant Edwards wrote:
> On 2024-04-16, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> > Arve,
> >
> > On Tuesday, 2024-04-16 15:53:48 +0200, you wrote:
> >> ...
> >> Only LTS kernels get stabilised, so this information is readily
> >> available.
> >
> > I'm sure I don't understand this: According to "https://www.kernel.org/"
> > kernel 6.6.27 is "longterm", but according to "eix" the most recent
> > 6.6.* kernels are 6.6.22 and 6.6.23 which both are non-stable (well, I
> > ran my last "sync" immediately before the profile upgrade, so this might
> > not be current). I'm still using stable kernel 6.6.13 as my backup ker-
> > nel, but this kernel is no longer provided by Gentoo. So, what precise-
> > ly does LTS or "longterm" mean?

LTS stands for Long Term Support and it means the kernel maintainers will
continue to backport bug fixes and security patches into the LTS kernels from
the Mainline tree, as they progress in their development of the kernel code.
When they do this backporting they bump the LTS kernel version, e.g. from
6.6.24 to 6.6.25.

They will not go into this prolonged maintenance effort with the kernel's
'Stable' tree, which has a higher churn as it acquires the Mainline kernels as
soon as the latter are signed for release.


> That means that all gentoo-sources stable kernels are "longterm"
> kernel versions on kernel.org. It does not mean that all "longterm"
> kernel versions from kernel.org are available as "stable" in
> gentoo-sources.
>
> It is a statement that "gentoo-sources stable" is a subset of
> "kernel.org longterm".
>
> It is not a statement that the two sets are identical.
>
> In other words:
>
> "ONLY LTS kernels get stabilized."
>
> is a different statement from
>
> "ALL LTS kernels get stabilized."
>
> The former is true. The latter is not.

Yes, precisely. This happens because Gentoo acquire the latest LTS kernel,
apply various Gentoo related patches, test and eventually mark as stable the
corresponding version of the gentoo-sources in portage. This process incurs
some inevitable delay compared with the LTS kernel tree releases, but
nevertheless the stable gentoo-sources follow the LTS releases.


> > But, to get back to the beginning of this discussion: if there is a
> > risk that my aging hardware possibly can less and less cope with
> > newer and newer kernels, should I put something like
> >
> > >=sys-kernel/gentoo-sources-6.7.0
> >
> > into file "package.mask" to stay with "longterm" 6.6.* kernels?
>
> Yes: if you want to avoid getting upgraded to 6.8 when it gets
> kernel.org "longterm" status and gentoo-sources "stable" status, then
> a statement like that in in package.mask will keep you on
> gentoo-sources 6.6 kernels (which are "longterm" on kernel.org).
>
> Again: not all longterm 6.6.x kernel versions get marked as "stable"
> for gentoo-sources. If you have not enabled the testing keyword for
> gentoo-sources, then you'll only get the 6.6.x kernel versions that
> the gentoo-sources maintainers have declared as "stable".
>
> --
> Grant

I am not sure the assumption "... aging hardware possibly can less and less
cope with newer and newer kernels" is correct. As already mentioned newer
kernels have both security and bug fixes. As long as you stick with stable
gentoo-sources you'll have these in your system. Later kernels also come with
additional kernel drivers for new(er) hardware. You may not need/want these
drivers if you do not run the latest hardware. Using 'make oldconfig' allows
you to exclude such new drivers, but include new security options and/or
functionality as desired.

It can happen for new code to introduce some software regression. However,
this is not limited to old hardware. If there is no workaround, or some patch
you can apply manually to your kernel from a later release, then by all means
you can mask later minor LTS releases *for a little while only* and keep an
eye open for the latest releases which could have addressed the bug you
suffered from.

PS. Regarding your earlier question about different make *config commands and
their meaning you can check the latest make help page:

$ cd /usr/src/linux
$ make help

Then take a look at the section "Configuration targets".

Grant,

On Tuesday, 2024-04-16 19:26:25 -0000, you wrote:

> ...
> That means that all gentoo-sources stable kernels are "longterm"
> kernel versions on kernel.org. It does not mean that all "longterm"
> kernel versions from kernel.org are available as "stable" in
> gentoo-sources.
>
> It is a statement that "gentoo-sources stable" is a subset of
> "kernel.org longterm".

This sort of deteriorates into a debate about words rather than meanings
without explaining HOW LONG such a series of related kernels are main-
tained and provided. After all, "longterm" or "LTS" suggest that these
lines of developement are less short-lived than others. To give an ex-
ample: the oldest "longterm" kernels listed on "kernel.org" are 4.19.*,
5.4.* and 5.10.*. Of these only 5.10.* is still available from Gentoo.

Digging through my Gentoo installation logs, I can see that 4.19.72 was
one of the first kernels I built myself. This was somewhen in the mid-
dle of 2019, that is, not yet five years back. And this kernel line has
already vanished from Gentoo. So what time span are we talking about
when we say "LTS Gentoo kernel"? Roughly four, three or two years? And
why is the support provided by Gentoo significantly shorter than that by
"kernel.org"?

Sincerely,
Rainer

On Wednesday, 17 April 2024 11:37:04 BST Dr Rainer Woitok wrote:
> Grant,
>
> On Tuesday, 2024-04-16 19:26:25 -0000, you wrote:
> > ...
> > That means that all gentoo-sources stable kernels are "longterm"
> > kernel versions on kernel.org. It does not mean that all "longterm"
> > kernel versions from kernel.org are available as "stable" in
> > gentoo-sources.
> >
> > It is a statement that "gentoo-sources stable" is a subset of
> > "kernel.org longterm".
>
> This sort of deteriorates into a debate about words rather than meanings
> without explaining HOW LONG such a series of related kernels are main-
> tained and provided. After all, "longterm" or "LTS" suggest that these
> lines of developement are less short-lived than others. To give an ex-
> ample: the oldest "longterm" kernels listed on "kernel.org" are 4.19.*,
> 5.4.* and 5.10.*. Of these only 5.10.* is still available from Gentoo.
>
> Digging through my Gentoo installation logs, I can see that 4.19.72 was
> one of the first kernels I built myself. This was somewhen in the mid-
> dle of 2019, that is, not yet five years back. And this kernel line has
> already vanished from Gentoo. So what time span are we talking about
> when we say "LTS Gentoo kernel"? Roughly four, three or two years? And
> why is the support provided by Gentoo significantly shorter than that by
> "kernel.org"?
>
> Sincerely,
> Rainer

LTS kernels were being supported for ~6 years, although the projected EOL I
see here indicates later LTS releases may not be supported for as long:

https://www.kernel.org/category/releases.html

The stable gentoo-sources are tree cleaned more frequently, so the oldest
stable release for amd64 in portage is now 5.10.212:

$ eix gentoo-sources
[I] sys-kernel/gentoo-sources
Available versions:
(5.10.208) *5.10.208^bs
(5.10.212) 5.10.212^bs
(5.10.213) ~5.10.213^bs
(5.10.214) ~5.10.214^bs
(5.10.215) ~5.10.215^bs
(5.15.147) *5.15.147^bs
(5.15.151) 5.15.151^bs
(5.15.152) ~5.15.152^bs
(5.15.153) ~5.15.153^bs
(5.15.154) ~5.15.154^bs
(5.15.155) ~5.15.155^bs
(6.1.74) *6.1.74^bs
(6.1.81) 6.1.81^bs
(6.1.83) ~6.1.83^bs
(6.1.84) ~6.1.84^bs
(6.1.85) ~6.1.85^bs
(6.1.86) ~6.1.86^bs
(6.6.13) *6.6.13^bs
(6.6.21) 6.6.21^bs
(6.6.24) ~6.6.24^bs
(6.6.25) ~6.6.25^bs
(6.6.26) ~6.6.26^bs
(6.6.26-r1) ~6.6.26-r1^bs
(6.6.27) ~6.6.27^bs
(6.8.3) ~6.8.3^bs
(6.8.4) ~6.8.4^bs
(6.8.5) ~6.8.5^bs
(6.8.5-r1) ~6.8.5-r1^bs
(6.8.6) ~6.8.6^bs
{build experimental symlink}
Installed versions: 6.6.21(6.6.21)^bs(03:21:20 24/03/24)(-build -
experimental -symlink)
Homepage: https://dev.gentoo.org/~mpagano/genpatches
Description: Full sources including the Gentoo patchset for the
6.8 kernel tree

On 2024-04-17, Michael <confabulate@kintzios.com> wrote:

>> > But, to get back to the beginning of this discussion: if there is a
>> > risk that my aging hardware possibly can less and less cope with
>> > newer and newer kernels, should I put something like
>> >
>> > >=sys-kernel/gentoo-sources-6.7.0
>> >
>> > into file "package.mask" to stay with "longterm" 6.6.* kernels?
>>
>> Yes: if you want to avoid getting upgraded to 6.8 when it gets
>> kernel.org "longterm" status and gentoo-sources "stable" status, then
>> a statement like that in in package.mask will keep you on
>> gentoo-sources 6.6 kernels (which are "longterm" on kernel.org).

> I am not sure the assumption "... aging hardware possibly can less and less
> cope with newer and newer kernels" is correct.

Good point. My "yes" was in response to a question of the form "if X
is true, should I do Y". I did not attempt to address the likelyhood
that X was actually ture, only whether Y was appropriate if X was
true.

> As already mentioned newer kernels have both security and bug fixes.
> As long as you stick with stable gentoo-sources you'll have these in
> your system. Later kernels also come with additional kernel drivers
> for new(er) hardware. You may not need/want these drivers if you do
> not run the latest hardware. Using 'make oldconfig' allows you to
> exclude such new drivers, but include new security options and/or
> functionality as desired.
>
> It can happen for new code to introduce some software regression.

The usual worries with running newer kernels on older hardware are:

1) Performance degradation when upgrading kernels on older hardware.

On one embedded project I work with we're still running a 2.6
kernel because network throughput drops by 25-30% when we upgrade
to 3.x kernels. There's nothing "wrong" with those 3.x kernels,
they're just bigger and significantly slower. [.Even when built
with a config that's as identical to the 2.6 kernels as possible.]

2) Lack of support for old hardware when running a newer kernels.

I used to run into this when running nvidia-drivers.
Gentoo-sources would mark a new kernel stable, but my video board
would not be supported by nvidia-drivers versions that were
supported for that new stable kernel. I would mask newer kernels
until and run older "longterm" kernels as long as I could. I would
evenually be forced to buy a new video card. After going through
that cycle a couple times, I swore off NVidia video cards and
life's been much eaiser since.

On 2024-04-17, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> Grant,
>
> On Tuesday, 2024-04-16 19:26:25 -0000, you wrote:
>
>> ...
>> That means that all gentoo-sources stable kernels are "longterm"
>> kernel versions on kernel.org. It does not mean that all "longterm"
>> kernel versions from kernel.org are available as "stable" in
>> gentoo-sources.
>>
>> It is a statement that "gentoo-sources stable" is a subset of
>> "kernel.org longterm".
>
> This sort of deteriorates into a debate about words rather than meanings

I'm sorry to have caused "deterioration" by trying to explain the
statement you said a) you didn't understand and b) was contridicted by
the contents of the gentoo portage tree. The statement was not
contridicted by what you pointed out.

> without explaining HOW LONG such a series of related kernels are
> main- tained and provided.

That was not the subject of the statement you claimed was wrong which
I then tried to explain. The gentoo-sources versions of upstream
"longterm" kernels are maintained and provided for as long as the
volunteers who do the work maintain and provide them.

> After all, "longterm" or "LTS" suggest that these lines of
> developement are less short-lived than others.

They are. Upstream longterm kernel versions get updates for several
years longer than versions that are not longterm.

> To give an ex- ample: the oldest "longterm" kernels listed on
> "kernel.org" are 4.19.*, 5.4.* and 5.10.*. Of these only 5.10.* is
> still available from Gentoo.

You should certainly demand that all of the money you paid for
gentoo-sources be refunded. It takes work to maintain gentoo-sources
ebuilds. I'm sure if you volunteered to maintain ebuilds for the
older longterm kernels, the help would be happily accepted.

Free clue: It's _hard_work_ to support old verions of things
(especially kernels). They usually won't build with recent tools and
won't run on recent hardware or with recent versions of other
software. You often have to keep around entire virtual machines that
have old tools and utilities.

If what you want is access to all upstream longeterm kernel versions,
then you should be using sys-kernel/vanilla-sources.

> So what time span are we talking about when we say "LTS Gentoo
> kernel"?

We don't say that. "LTS" and "longterm" are not Gentoo designations,
they are kernel.org designations. Gentoo has "stable" and "testing".
Only upstream "longterm" kernel versions get marked as "stable" in
gentoo-sources. They are then supported for as long as somebody
supports them.

> Roughly four, three or two years? And why is the support provided
> by Gentoo significantly shorter than that by "kernel.org"?

Because you're not helping with the support?

--
Grant

Michael,

On Wednesday, 2024-04-17 10:10:56 +0100, you wrote:

> On Tuesday, 16 April 2024 20:26:25 BST Grant Edwards wrote:
> > On 2024-04-16, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> > ...
> > > But, to get back to the beginning of this discussion: if there is a
> > > risk that my aging hardware possibly can less and less cope with
> > > newer and newer kernels, should I put something like
> > >
> > > >=sys-kernel/gentoo-sources-6.7.0
> > >
> > > into file "package.mask" to stay with "longterm" 6.6.* kernels?
> > ...
>
> I am not sure the assumption "... aging hardware possibly can less and less
> cope with newer and newer kernels" is correct. As already mentioned newer
> kernels have both security and bug fixes. As long as you stick with stable
> gentoo-sources you'll have these in your system.

But since the 6.6.* kernel is LTS, security and bug fixes will be back-
ported into it and all is well. And if this can't be done for some rea-
son or other, I can still cautiously advance my entry in file "package.
mask" to the next LTS kernel.

> ...
> PS. Regarding your earlier question about different make *config commands and
> their meaning you can check the latest make help page:
>
> $ cd /usr/src/linux
> $ make help

Done. Again learned something. Thanks a lot :-)

Sincerely,
Rainer

Grant,

On Wednesday, 2024-04-17 14:11:21 -0000, you wrote:

> ...
> If what you want is access to all upstream longeterm kernel versions,
> then you should be using sys-kernel/vanilla-sources.

I was not aware of this package. Excatly what could come in handy, if
everything else fails. Thank you for that pointer :-)

Sincerely,
Rainer

On 17/04/2024 10:10, Michael wrote:
> I am not sure the assumption "... aging hardware possibly can less and less
> cope with newer and newer kernels" is correct. As already mentioned newer
> kernels have both security and bug fixes. As long as you stick with stable
> gentoo-sources you'll have these in your system. Later kernels also come with
> additional kernel drivers for new(er) hardware. You may not need/want these
> drivers if you do not run the latest hardware. Using 'make oldconfig' allows
> you to exclude such new drivers, but include new security options and/or
> functionality as desired.

Given that I remember the announcement that the linux kernel's memory
requirements had increased to 6MB - in the days when Fedora et al
demanded gigabytes simply to be able to run - I think almost any ancient
hardware you can actually buy will be able to run the linux kernel no probs.

You might have difficulty compiling it, though, now 386 support has been
pretty much dropped from the toolchain. Have they dropped i686 as well?

Cheers,
Wol