[gentoo-user] Slightly corrupted file systems when resuming from hibernation

[gentoo-user] Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

Greetings,

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.
At least up to now this never happened when resuming from suspension.

Is my laptop just aging  or did I miss some new "mount" option or kernel
configuration parameter?  Any comments welcome ... :-)

Sincerely,
  Rainer

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Arve Barsnes]

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

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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.

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[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

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

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

:-)  :-) 

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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.

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4326 bytes --]

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".

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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.
    
    

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Grant Edwards wrote:
>
>  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.
>     


I still use Nvidia and use nvidia drivers.  I to run into problems on
occasion with drivers and kernels.  When you switched from Nvidia, what
did you switch too?  Do you still use drivers you install or kernel
drivers?  How well does the video system work?  In other words, plenty
fast enough for what you do. 

I don't do any sort of heavy gaming.  Since I have a nice game on my
cell phone now, I play it almost all the time.  I can't recall playing a
game of solitaire on my computer in a long while.  My biggest thing, two
video ports, one for monitor and one for TV.  Most TV videos aren't very
high def but some are 1080P.  That's all my TV can handle. 

Just exploring options. 

Dale

:-)  :-) 

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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

> I still use Nvidia and use nvidia drivers.  I to run into problems
> on occasion with drivers and kernels.  When you switched from
> Nvidia, what did you switch too?  Do you still use drivers you
> install or kernel drivers?

All in-tree kernel drivers for integrated GPUs:

 * Intel UHD Graphics 620
 * Intel HD Graphics 4000
 * Intel Xeon E3-1200
 * AMD Picasso Radeon Vega

After I had to recycle my second perfectly functional NVidia card
simply because NVidia stopped driver support, I got fed up.  I tried
the open-source nvidia drivers for those cards, but could never get
multiple screens to work.

> How well does the video system work?  In other words, plenty fast
> enough for what you do. 

They're all fast enough for what I do (no heavy gaming, but I do play
with an RC flight simulator).  All will drive at least two digital
monitors.  The last machine that had an NVidia card removed is also
the oldest of the machines (Gigabyte Z77X-UD5H Intel i5-3570K w/ HD
4000 graphics), and it's happily driving three monitors (1 HDMI, 1
DVI, 1 DP).

When running the flight-sim, the newest of them (the AMD/Radeon) is
noticeably smoother and runs at higher frame rates than the older Intel
GPUs.  I didn't really have any complaints about the older ones, but I
don't expect a real gamer would have been satisfied with the Intel
ones.

> I don't do any sort of heavy gaming.  Since I have a nice game on my
> cell phone now, I play it almost all the time.  I can't recall
> playing a game of solitaire on my computer in a long while.  My
> biggest thing, two video ports, one for monitor and one for TV. 
> Most TV videos aren't very high def but some are 1080P.  That's all
> my TV can handle. 

They all seem to handle HD video playback just fine.

How many and what type of monitors can be driven is very much
dependent on the motherboard.

--
Grant

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

Grant Edwards wrote:
> On 2024-04-17, Dale <rdalek1967@gmail.com> wrote:
>
>> I still use Nvidia and use nvidia drivers.  I to run into problems
>> on occasion with drivers and kernels.  When you switched from
>> Nvidia, what did you switch too?  Do you still use drivers you
>> install or kernel drivers?
> All in-tree kernel drivers for integrated GPUs:
>
>  * Intel UHD Graphics 620
>  * Intel HD Graphics 4000
>  * Intel Xeon E3-1200
>  * AMD Picasso Radeon Vega
>
> After I had to recycle my second perfectly functional NVidia card
> simply because NVidia stopped driver support, I got fed up.  I tried
> the open-source nvidia drivers for those cards, but could never get
> multiple screens to work.
>
>> How well does the video system work?  In other words, plenty fast
>> enough for what you do. 
> They're all fast enough for what I do (no heavy gaming, but I do play
> with an RC flight simulator).  All will drive at least two digital
> monitors.  The last machine that had an NVidia card removed is also
> the oldest of the machines (Gigabyte Z77X-UD5H Intel i5-3570K w/ HD
> 4000 graphics), and it's happily driving three monitors (1 HDMI, 1
> DVI, 1 DP).
>
> When running the flight-sim, the newest of them (the AMD/Radeon) is
> noticeably smoother and runs at higher frame rates than the older Intel
> GPUs.  I didn't really have any complaints about the older ones, but I
> don't expect a real gamer would have been satisfied with the Intel
> ones.
>
>> I don't do any sort of heavy gaming.  Since I have a nice game on my
>> cell phone now, I play it almost all the time.  I can't recall
>> playing a game of solitaire on my computer in a long while.  My
>> biggest thing, two video ports, one for monitor and one for TV. 
>> Most TV videos aren't very high def but some are 1080P.  That's all
>> my TV can handle. 
> They all seem to handle HD video playback just fine.
>
> How many and what type of monitors can be driven is very much
> dependent on the motherboard.
>
> --
> Grant
>
>
>


I've often thought of trying ATI or something but just never did.  My
video cards tend to age out too because of driver issues.  From a cost
perspective, I kinda get it.  Still, I hate pitching a otherwise working
card. 

Thanks for the info. More stuff to think on. 

Dale

:-)  :-) 

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Wols Lists]

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

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

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

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dr Rainer Woitok]

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

[gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Grant Edwards]

On 2024-04-17, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> 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 :-)

Just be aware that gentoo-sources contains an "extra" set of
gentoo-specific patches.  So version x.y.z of gentoo-sources isn't
identical to version x.y.z of vanilla-sources.

    https://dev.gentoo.org/~mpagano/genpatches/

--
Grant

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Dale]

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

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

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
> 
> :-)  :-) 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[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

:-)  :-) 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Jack]

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.