Discussion:
[gentoo-user] Slightly corrupted file systems when resuming from hibernation
(too old to reply)
Dr Rainer Woitok
2024-01-05 17:50:01 UTC
Permalink
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
Dr Rainer Woitok
2024-04-14 18:50:01 UTC
Permalink
Greetings,
Post by Dr Rainer Woitok
...
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
Michael
2024-04-15 11:50:01 UTC
Permalink
Post by Dr Rainer Woitok
Greetings,
Post by Dr Rainer Woitok
...
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-
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.
Post by Dr Rainer Woitok
/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.
Dr Rainer Woitok
2024-04-16 09:10:01 UTC
Permalink
Michael,
Post by Michael
...
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 :-)
Post by Michael
...
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
Michael
2024-04-16 10:20:01 UTC
Permalink
Post by Dr Rainer Woitok
Michael,
Post by Michael
...
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 :-)
Post by Michael
...
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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
2024-04-16 13:30:01 UTC
Permalink
Michael,
Post by Michael
...
Post by Dr Rainer Woitok
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.
Post by Michael
...
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
Arve Barsnes
2024-04-16 14:00:02 UTC
Permalink
Post by Dr Rainer Woitok
Post by Michael
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
Grant Edwards
2024-04-16 15:00:01 UTC
Permalink
Post by Arve Barsnes
Post by Dr Rainer Woitok
Post by Michael
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.
Dale
2024-04-16 15:10:01 UTC
Permalink
Post by Grant Edwards
Post by Arve Barsnes
Post by Dr Rainer Woitok
Post by Michael
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

:-)  :-) 
Dale
2024-04-16 15:10:01 UTC
Permalink
Post by Arve Barsnes
Post by Dr Rainer Woitok
Post by Michael
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
2024-04-16 15:20:02 UTC
Permalink
Post by Dale
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.
Post by Dale
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.
Post by Dale
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.
Dr Rainer Woitok
2024-04-16 16:50:01 UTC
Permalink
Arve,
Post by Arve Barsnes
...
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
Post by Arve Barsnes
=sys-kernel/gentoo-sources-6.7.0
into file "package.mask" to stay with "longterm" 6.6.* kernels?

Sincerely,
Rainer
Grant Edwards
2024-04-16 19:30:01 UTC
Permalink
Post by Dr Rainer Woitok
Arve,
Post by Arve Barsnes
...
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.
Post by Dr Rainer Woitok
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
Post by Arve Barsnes
=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
Michael
2024-04-17 09:20:01 UTC
Permalink
Post by Grant Edwards
Post by Dr Rainer Woitok
Arve,
Post by Arve Barsnes
...
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.
Post by Grant Edwards
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.
"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.
Post by Grant Edwards
Post by Dr Rainer Woitok
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
Post by Arve Barsnes
=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 Edwards
2024-04-17 14:00:02 UTC
Permalink
Post by Michael
Post by Grant Edwards
Post by Dr Rainer Woitok
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
Post by Arve Barsnes
=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.
Post by Michael
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.
Dale
2024-04-17 20:10:01 UTC
Permalink
Post by Grant Edwards
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

:-)  :-) 
Grant Edwards
2024-04-17 20:40:01 UTC
Permalink
Post by Dale
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.
Post by Dale
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.
Post by Dale
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
Dale
2024-04-17 22:20:01 UTC
Permalink
Post by Grant Edwards
Post by Dale
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?
* 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.
Post by Dale
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.
Post by Dale
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

:-)  :-) 

Dr Rainer Woitok
2024-04-17 16:00:01 UTC
Permalink
Michael,
Post by Michael
...
Post by Dr Rainer Woitok
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
Post by Arve Barsnes
=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.
Post by Michael
...
PS. Regarding your earlier question about different make *config commands and
$ cd /usr/src/linux
$ make help
Done. Again learned something. Thanks a lot :-)

Sincerely,
Rainer
Wols Lists
2024-04-17 18:00:01 UTC
Permalink
Post by Michael
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
Dr Rainer Woitok
2024-04-17 10:40:01 UTC
Permalink
Grant,
Post by Grant Edwards
...
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
Michael
2024-04-17 11:00:01 UTC
Permalink
Post by Dr Rainer Woitok
Grant,
Post by Grant Edwards
...
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
Grant Edwards
2024-04-17 14:20:01 UTC
Permalink
Post by Dr Rainer Woitok
Grant,
Post by Grant Edwards
...
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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.
Post by Dr Rainer Woitok
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
Dr Rainer Woitok
2024-04-17 16:20:02 UTC
Permalink
Grant,
Post by Grant Edwards
...
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
Grant Edwards
2024-04-17 18:00:01 UTC
Permalink
Post by Dr Rainer Woitok
Grant,
Post by Grant Edwards
...
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
Dale
2024-04-16 11:00:02 UTC
Permalink
Post by Dr Rainer Woitok
Michael,
Post by Michael
...
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 :-)
Post by Michael
...
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
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

:-)  :-) 
Michael
2024-04-16 11:20:01 UTC
Permalink
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
:-) :-)
Dale
2024-04-16 12:50:01 UTC
Permalink
Post by Michael
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
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

:-)  :-) 
Jack
2024-04-16 14:40:01 UTC
Permalink
Post by Michael
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.
Loading...