[gentoo-user] Upgrading from 5.14 to 6.0 version

[Dale]

Howdy,

I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.  I upgraded like I always
do, copy .config over and run make oldconfig.  Once I get everything in
/boot, init thingy and all, I update grub.  When I get around to
rebooting, the new kernels always fail part way through booting.  I
can't recall the error since I last tried a newer kernel several months
ago. 

I'm about to try to jump to version 6.0.5 which is latest in the tree. 
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?  Do I need to configure a new kernel from
scratch in other words?  While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing
updating from older versions.  I just don't know which it is. Me or it. 

Thoughts?

Thanks.

Dale

:-)  :-) 

P. S.  Bought yet another 14TB hard drive.  Working on filling it up
now.  While my Cooler Master HAF-932 case is large, I need more drive
bays.  Dang cases are pricey right now.  :/

[Arve Barsnes]

I can't remember any difficulty going from the 5 series to 6.0.0 either, even
though it was a .0 version, which we all know is generally to be suspected.

Not when it comes to the linux kernel though, where major version
changes are arbitrary and comes around the x.19/20/21 switch no matter
which new features are in it.

Regards,
Arve

[Wols Lists]

Post by Arve Barsnes

I can't remember any difficulty going from the 5 series to 6.0.0 either, even
though it was a .0 version, which we all know is generally to be suspected.

Not when it comes to the linux kernel though, where major version
changes are arbitrary and comes around the x.19/20/21 switch no matter
which new features are in it.

It's the "fingers and toes reset" :-)

Cheers,
Wol

[Peter Humphrey]

Post by Dale
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in
/boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months
ago.
I'm about to try to jump to version 6.0.5 which is latest in the tree.
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break? Do I need to configure a new kernel from
scratch in other words? While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing
updating from older versions. I just don't know which it is. Me or it.

The evidence seems to point in one direction. :)

One box here runs ~amd64, whose kernel has just now been upgraded to 6.0.8.
I'll boot it in a few minutes, but I'm not expecting problems: it's been
through the whole 6 series so far with no difficulty - even for me!

I can't remember any difficulty going from the 5 series to 6.0.0 either, even
though it was a .0 version, which we all know is generally to be suspected.

[hitachi303]

Post by Dale
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.  I upgraded like I always
do, copy .config over and run make oldconfig.  Once I get everything in
/boot, init thingy and all, I update grub.  When I get around to
rebooting, the new kernels always fail part way through booting.  I
can't recall the error since I last tried a newer kernel several months
ago.

Do you follow the guide on gentoo wiki?

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

I don't know why but building and installing is not in this article. For
that I do follow this one (there is a link from kernel upgrade to this
on, but it is kind of hidden)

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

[Dale]

Post by hitachi303

Post by Dale
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.  I upgraded like I always
do, copy .config over and run make oldconfig.  Once I get everything in
/boot, init thingy and all, I update grub.  When I get around to
rebooting, the new kernels always fail part way through booting.  I
can't recall the error since I last tried a newer kernel several months
ago.

Do you follow the guide on gentoo wiki?
https://wiki.gentoo.org/wiki/Kernel/Upgrade
I don't know why but building and installing is not in this article.
For that I do follow this one (there is a link from kernel upgrade to
this on, but it is kind of hidden)
https://wiki.gentoo.org/wiki/Kernel/Configuration#Build
.

I haven't had to follow a guide in ages.  I been building my own kernels
for almost 20 years now.  My problem is that the two updated kernels
doesn't work.  If it was just one version, it could just be a bad build
or something.  Thing is, I tried updating from a working config to two
different versions and both failed.  I suspect that something major
changed and going from a old config file may not work.  Thing is, I
don't know if that is the case or not.  It could be, hence the question,
but it could be something else or just that I missed something and
someone else knows what that something is because they ran into it
earlier. 

I wish when they did major changes, they would also change the number
scheme to reflect that.  As I read in another post, sometimes even a
number change in the third place can give a very different kernel,
something major removed or added.  Unless one reads all the posts on the
kernel mailing list, one wouldn't know that change happened. 

I did build a new kernel from the old config and running make
oldconfig.  When I get around to rebooting, I'll see if it works or
not.  If not, I'll note the error and see if that gives any clues. 

Thanks.

Dale

:-)  :-) 

[Dr Rainer Woitok]

Dale,

Post by Dale
...
I did build a new kernel from the old config and running make
oldconfig.

Perhaps you should rather use

make olddefconfig

It tries not to just ignore any newly introduced configuration variables
but rather to provide meaningful defaults for them.

Sincerely
Rainer

[Rich Freeman]

Post by Dale
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?

So, I just upgraded to 5.15 recently and tend to stick to LTS kernels,
precisely to minimize this sort of thing.

My guess is that you missed something in make oldconfig, but obviously
without exact errors that could be completely wrong.

I can't speak to 6.0 specifically, but one thing that I've found is a
gotcha is when they consolidate config items under higher level ones.
So they'll take what used to be 50 questions, and turn it into 1
question with 50 questions underneath it. The 1 question shows up as
a new config item, and if you don't appreciate what it does and answer
no to it, then you'll disable every item underneath it.

Basically, don't assume that any new question is a new feature, and if
you say no you'll still have all the pre-existing features. It could
be a virtual question and answering no turns off a whole bunch of
things that you had previously said yes to. You need to review
oldconfig questions pretty carefully. You could try defaulting the
answers but even then the defaults aren't always reasonable. They
don't just turn on things you don't need. For example, by default
linux turns off CGROUP support, and almost everything uses that today.
That was just the first thing I checked, and I bet there are a million
other gotchas like that.

--
Rich

[Dale]

Post by Rich Freeman

Post by Dale
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?

So, I just upgraded to 5.15 recently and tend to stick to LTS kernels,
precisely to minimize this sort of thing.
My guess is that you missed something in make oldconfig, but obviously
without exact errors that could be completely wrong.
I can't speak to 6.0 specifically, but one thing that I've found is a
gotcha is when they consolidate config items under higher level ones.
So they'll take what used to be 50 questions, and turn it into 1
question with 50 questions underneath it. The 1 question shows up as
a new config item, and if you don't appreciate what it does and answer
no to it, then you'll disable every item underneath it.
Basically, don't assume that any new question is a new feature, and if
you say no you'll still have all the pre-existing features. It could
be a virtual question and answering no turns off a whole bunch of
things that you had previously said yes to. You need to review
oldconfig questions pretty carefully. You could try defaulting the
answers but even then the defaults aren't always reasonable. They
don't just turn on things you don't need. For example, by default
linux turns off CGROUP support, and almost everything uses that today.
That was just the first thing I checked, and I bet there are a million
other gotchas like that.
--
Rich

I don't blindly answer those questions even tho it can be time consuming
at times. I tend to look at a new feature as something I don't need,
since I'm not adding hardware.  I still look to see if it is something
new that could be useful.  The new features are usually marked as new so
they're easy to see.  What gets me, it asks for something that I've
already done before and it has the option I chose before already
selected but asks me anyway.  That's kinda weird. 

When I was going through oldconfig, I noticed that when I answered yes
to a new thing, files system option that I could possibly need one day,
that a whole bunch of related new stuff followed behind it.  It makes
logical sense but it does open a can of worms for sure. 

I wish there was a better way to update kernels but thing is, I can't
figure out a better way to do it either.  I suspect if there was a
better way, someone would have figured it out by now anyway.  ;-)

Now to reboot this thing, eventually.  lol

Dale

:-)  :-) 

[ralfconn]

Post by Dale
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.  I upgraded like I always
do, copy .config over and run make oldconfig.  Once I get everything in
/boot, init thingy and all, I update grub.  When I get around to
rebooting, the new kernels always fail part way through booting.  I
can't recall the error since I last tried a newer kernel several months
ago.
I'm about to try to jump to version 6.0.5 which is latest in the tree.
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?  Do I need to configure a new kernel from
scratch in other words?  While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing
updating from older versions.  I just don't know which it is. Me or it.

I've had a similar experience recently. I was using LTS (5.15) due to
old, no longer supported Nvidia video card, when I switched to nouveau I
tried 6.0.x but no go, either USB3 or USB2 where working, but not both.
After much fiddling with .config I ended up booting the PC from USB with
a recent, working binary distribution - Ubuntu 22.04 - and compared its
.config with mine, and found out the problem was in one of the kernel
boot parameters, not in the .config!

If you find the binary distribution kernel works, lsmod will tell you
which modules are actually used on your machine so you can pick just
those in your config. For the .config comparison, meld works just fine.

raffaele

[Nikos Chantziaras]

Post by Dale
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.

If you've been using 5.14 until now, it would appear to me you're the
target audience of the LTS kernels. 5.15 is the latest LTS kernel. Those
kernels are maintained with bugfixes and backports for at least 2 years.

The next LTS will probably be 6.1, so if you update to that, stick to it
for the next 2 years and then update to whatever is the latest LTS then.

[Dale]

Post by Nikos Chantziaras

Post by Dale
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.

If you've been using 5.14 until now, it would appear to me you're the
target audience of the LTS kernels. 5.15 is the latest LTS kernel.
Those kernels are maintained with bugfixes and backports for at least
2 years.
The next LTS will probably be 6.1, so if you update to that, stick to
it for the next 2 years and then update to whatever is the latest LTS
then.

I don't target LTS, I just rarely reboot.  My system runs 24/7.  I watch
TV from it plus do all the other things, check emails, look for info,
buy things etc etc.  Usually, I reboot when I lose power for more than a
couple minutes.  Where I live, if the power fails for more than 30
seconds or so, it's gonna be out longer than my UPS will last.  My UPS
mostly is to protect from those short blinks etc.  Anyway.  Recently, I
been shutting down when I move hard drives physically.  I put in a new
drive, get it set up, transfer data and such.  Once that is done, I
shutdown and physically move the drive to its permanent location. 
Lately, I'm having to use 5 1/4" spots and a adapter.  I'm out of 3.5"
spots. 

Where does one go for a list of the LTS kernels?  Since I reboot so
rarely, what not use one of them??  Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.  ;-)

Dale

:-)  :-) 

[Mark Knecht]

Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway. ;-)
Dale
:-) :-)

https://www.kernel.org/

[Wol]

Post by Dale
Where does one go for a list of the LTS kernels?  Since I reboot so
rarely, what not use one of them??  Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.

Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.

The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
to old kernels? Especially when it's not unknown for a bot to try to
backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.

The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.

Cheers,
Wol

[Mark Knecht]

Post by Wol

Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.

Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
to old kernels? Especially when it's not unknown for a bot to try to
backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
Cheers,
Wol

Wol,
While I don't completely disagree with your technical points I
really don't think your assessment of the purpose of a LTS kernel
is wide ranging enough.

I do agree that from what I know of Dale's usage he probably
doesn't NEED a long term support kernel, but he may be better
off with one.

If you are user of apps you pay for - in my case Mixbus - an paid
version of Ardour - and PixInsight then you are not going to get
much support if you're off in the weeds running Gentoo and/or
leading edge kernels. I run Kubuntu now, but not because I think
it's a better distro, but because I get support. Harrison does all
the dirty work on the audio stack and Pleiades Astro basically
says you're on your own running unless you are on just a couple of
distros. They were no help when I ran Gentoo. They are great
under Kubuntu.

An additional point is that if Dale limits himself to an LTS
kernel then he doesn't have to worry about changes to his
tool chain. I'm just waiting for the day that Rust becomes
a driving conversation point on this list. I don't think Dale
wants or needs to be involved in that.

Anyway, just my point of view.

Best wishes,
Mark

[Dale]

Post by Dale

Post by Wol

Where does one go for a list of the LTS kernels?  Since I reboot so
rarely, what not use one of them??  Of course, the kernel I have

in use

Post by Wol

now has long uptimes so it is sort of LTS for this rig anyway.

Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
  to old kernels? Especially when it's not unknown for a bot to try to
backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
Cheers,
Wol

Wol,
   While I don't completely disagree with your technical points I
really don't think your assessment of the purpose of a LTS kernel
is wide ranging enough. 
   I do agree that from what I know of Dale's usage he probably 
doesn't NEED a long term support kernel, but he may be better 
off with one.
   If you are user of apps you pay for - in my case Mixbus - an paid
version of Ardour - and PixInsight then you are not going to get 
much support if you're off in the weeds running Gentoo and/or
leading edge kernels. I run Kubuntu now, but not because I think
it's a better distro, but because I get support. Harrison does all
the dirty work on the audio stack and Pleiades Astro basically
says you're on your own running unless you are on just a couple of
distros. They were no help when I ran Gentoo. They are great 
under Kubuntu.
   An additional point is that if Dale limits himself to an LTS 
kernel then he doesn't have to worry about changes to his
tool chain. I'm just waiting for the day that Rust becomes
a driving conversation point on this list. I don't think Dale 
wants or needs to be involved in that.
   Anyway, just my point of view.
Best wishes,
Mark

Usually, I try to update about once a year.  I don't change hardware
much.  I do plan to get a PCI SATA card with more ports later on but
still, I don't change hardware a whole lot.  Maybe a LTS isn't for me. 
I was just curious if I would benefit from using one since I don't
upgrade much and the kernels I run, run for months without problems.  So
to me, they are rock stable.  This is from uprecords, just the first
seven entries. 

1   303 days, 11:46:23 | Linux 4.5.2-gentoo        Sat Jul 29 23:20:27 2017
2   227 days, 22:10:30 | Linux 5.6.7-gentoo        Wed Oct 28 13:59:36 2020
3   200 days, 06:51:46 | Linux 4.18.12-gentoo      Sat Jan 12 03:42:55 2019
4   193 days, 09:28:37 | Linux 3.5.3-gentoo        Sat Sep 22 07:50:38 2012
5   184 days, 15:47:57 | Linux 3.18.7-gentoo       Tue Dec 15 21:53:59 2015
6   166 days, 20:47:12 | Linux 5.6.7-gentoo        Thu May 14 00:47:09 2020
7   147 days, 10:32:02 | Linux 5.14.15-gentoo      Sun Feb 13 01:09:41 2022

My current kernel is on the bottom.  With hard drive changes, I been
rebooting more often than usual.  Still, 147 days is pretty stable.  :-D

It was just a thought.  Maybe not even a good one.  ;-)

Dale

:-)  :-) 

[Nikos Chantziaras]

Usually, I try to update about once a year.  I don't change hardware
much.

The main reason I suggested LTS is because that, *when* you decide to do
a @world update, you will get the latest LTS of the same main version
you're already using. For example you'll go from 5.15.20 to 5.15.78. And
that means you won't have to bother with an array of endless "make
oldconfig" questions. There'll be like one or two at most, which is
trivial to deal with.

I've been using LTS kernels for years now, and I never looked back.
"make oldconfig" usually doesn't say anything, making it a ridiculously
fast and no-brainer update, and yet I get the latest bugfixes and
security fixes.

It just works :-)

[Dale]

Post by Nikos Chantziaras

Usually, I try to update about once a year.  I don't change hardware
much.

The main reason I suggested LTS is because that, *when* you decide to
version you're already using. For example you'll go from 5.15.20 to
5.15.78. And that means you won't have to bother with an array of
endless "make oldconfig" questions. There'll be like one or two at
most, which is trivial to deal with.
I've been using LTS kernels for years now, and I never looked back.
"make oldconfig" usually doesn't say anything, making it a
ridiculously fast and no-brainer update, and yet I get the latest
bugfixes and security fixes.
It just works :-)

Thing is, I may go a year, sometimes more, without updating the kernel. 
If I rebooted often, I could see using a LTS kernel.  If a kernel can
run for months with no problems, it's stable enough for me.  Plus my
hardware works.

I have even built a kernel but never actually booted it.  By the time I
get around to rebooting, I've had to build another kernel.  I generally
always work from a known stable config tho.  The only reason I wouldn't
is if I build a new system and have to start from scratch.  I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running.  That doesn't happen to
often but I recall running into that at least once. 

Either way, biggest question was if there was some known breakage
between my old version and a newer version.  Maybe the one I tried just
had some weird problem that only affected me or I just missed something
during the oldconfig.  I wish I could recall the error.  Who knows on
that. 

Thanks.

Dale

:-)  :-) 

[Mark Knecht]

Post by Dale

Post by Nikos Chantziaras

Usually, I try to update about once a year. I don't change hardware
much.

The main reason I suggested LTS is because that, *when* you decide to
version you're already using. For example you'll go from 5.15.20 to
5.15.78. And that means you won't have to bother with an array of
endless "make oldconfig" questions. There'll be like one or two at
most, which is trivial to deal with.
I've been using LTS kernels for years now, and I never looked back.
"make oldconfig" usually doesn't say anything, making it a
ridiculously fast and no-brainer update, and yet I get the latest
bugfixes and security fixes.
It just works :-)

Thing is, I may go a year, sometimes more, without updating the kernel.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.
I have even built a kernel but never actually booted it. By the time I
get around to rebooting, I've had to build another kernel. I generally
always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.
Either way, biggest question was if there was some known breakage
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something
during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)

Dale,
While I completely understand your 'reboot once a year' POV, I think
you might *possibly* be missing the point Nikos and others are making.

If you are on 5.14.XX you aren't currently using a LTS kernel. The
LTS kernels would be the 5.10 and 5.15 series, according to kernel.org.

If you don't CARE what kernel you are running then why not build
5.15.78 which is currently the most recent LTS kernel. If there are
updates to that series for bug & security fixes then once you have
built 5.15.78 (WHETHER YOU RUN IT OR NOT) then further
updates to that series won't be a big deal and probably don't even
require much of a config change or a tool chain change. It WILL
be easy.

You would move forward going from 5.14.15 to 5.15.78. If
you don't NEED something in 6.0.5 or 6.0.8 then why bother?

Once you have 5.15.78 built and installed it's there if you
reboot. If you don't reboot then you'll go on building 5.15
kernels until some newer LTS kernel is named.

It is truly an easy way to manage the kernel part of
running Linux.

Good luck,
Mark

[Michael]

Post by Dale
Thing is, I may go a year, sometimes more, without updating the kernel.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.

Keeping the same kernel running for long periods can leave you exposed to
security vulnerabilities. Either stable or LTS kernels will be similarly
exposed, if their latest backported versions are not booted with. I
appreciate you're not running a public server so your profile is not as much
at risk, but bad code in some application which hasn't been patched up could
still leave you exposed.

Post by Dale
I have even built a kernel but never actually booted it. By the time I
get around to rebooting, I've had to build another kernel. I generally
always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.

Shutting down your desktop applications and rebooting with a new kernel takes
no longer than a couple of minutes. I mean even busy bank customer web
portals have planned downtime.

Post by Dale
Either way, biggest question was if there was some known breakage
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something
during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)

Did you diff your current good kernel .config and the new failed to boot
kernel .config, to find out what options/modules have changed. Besides any
booting errors, this could point you to something which was missed in the new
kernel, or perhaps shouldn't have been configured. That's how I go about
finding the cause of a non-booting kernel in the rare occasions I end up with
a lemon.

[Wol]

Post by Michael
Shutting down your desktop applications and rebooting with a new kernel takes
no longer than a couple of minutes. I mean even busy bank customer web
portals have planned downtime.

There's a lot more to it than that ...

The reason I don't run new kernels all the time, is that finding the
time to actually copy the old config, make, make modules, make install,
fix grub, sort out problems, reboot, is actually quite hard.

It's not just a few minutes ...

Cheers,
Wol

[Dale]

Post by Michael

Post by Dale
Thing is, I may go a year, sometimes more, without updating the kernel.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.

Keeping the same kernel running for long periods can leave you exposed to
security vulnerabilities. Either stable or LTS kernels will be similarly
exposed, if their latest backported versions are not booted with. I
appreciate you're not running a public server so your profile is not as much
at risk, but bad code in some application which hasn't been patched up could
still leave you exposed.

Post by Dale
I have even built a kernel but never actually booted it. By the time I
get around to rebooting, I've had to build another kernel. I generally
always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.

Shutting down your desktop applications and rebooting with a new kernel takes
no longer than a couple of minutes. I mean even busy bank customer web
portals have planned downtime.

That may be true.  I used to not mind rebooting as much but since I
started having to use the init thingy, I only do it when really
necessary.  Those init thingys have left a long term bad taste in my
mouth.  If I could, I'd likely never reboot.  Thing is, sometimes I have
a power outage and just have too. 

The other thing, my computer is my entertainment system as well.  My TV
runs close to 24/7.  I may pause a video if I'm outside or something but
other than that, it is playing something about all the time.  I do go to
town each Thursday morning to get my shots and pick up groceries. 
Because of my lengthy time between trips anywhere, I put a trickle
charger on my car.  Sitting for a week wasn't doing the battery any good. 

Another reason my system runs even if I'm not home, downloading of
files.  I'm almost always downloading something.  It's how I entertain
myself after all.  ;-)  Basically, this system is busy doing things,
multiple things, almost all the time. 

Post by Michael

Post by Dale
Either way, biggest question was if there was some known breakage
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something
during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)

Did you diff your current good kernel .config and the new failed to boot
kernel .config, to find out what options/modules have changed. Besides any
booting errors, this could point you to something which was missed in the new
kernel, or perhaps shouldn't have been configured. That's how I go about
finding the cause of a non-booting kernel in the rare occasions I end up with
a lemon.

I tried to boot with new kernel, saw the error, rebooted into a older
kernel and carried on.  That was several months ago so no clue what the
error was. 

Dale

:-)  :-) 

[Grant Edwards]

Post by Michael
Shutting down your desktop applications and rebooting with a new
kernel takes no longer than a couple of minutes.

On my systems it typically takes about 15-20 seconds.

I try to reboot at least once a month when I have some spare time --
just to make sure I can.

What I don't want to happen is that some mishandled upgrade has broken
my system so that it won't boot properly, but I don't know about until
months later when I'm in the middle of something urgent and the power
glitches. Then I spend several hours I don't have trying to figure out
what's wrong. [Been there, done that, it's _not_ fun.]

If you wait years between reboots, and it doesn't go well when you do
have to reboot, there are usually a lot of possible causes.

The same applies to X11: I like to restart it every week or so just to
make sure nothing's been broken by recent upgrades.

It's a _lot_ easier to find/fix a problem when the upgrade that caused
it is recent (and there's only the one problem).

If you wait long enough, you end up with multiple problems that
sometimes aggravate each other.

--
Grant

[Nikos Chantziaras]

Post by Wol

Post by Dale
Where does one go for a list of the LTS kernels?  Since I reboot so
rarely, what not use one of them??  Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.

Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
 to old kernels? Especially when it's not unknown for a bot to try to
backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.

wat

[Rich Freeman]

Post by Wol
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.

Two things: first, LTS kernels aren't the same as stable kernels.
Dale has been running stable kernels, and gentoo-sources kernels are
all stable kernels.

Second, I've been running LTS kernels for years without issue. I got
into them due to running zfs/btrfs/nvidia. ZFS and nvidia are out of
tree modules, and they tend to lag in support for the latest stable
branches, so it is a constant battle if you want to run stable. If
you run LTS they just work. When I was running btrfs I wanted to
stick to LTS mainly because btrfs was constantly breaking things in
new releases, which like every other subsystem are introduced in new
branches. That was a while ago and maybe btrfs is more stable today.
If you run anything out of tree though LTS is a much easier target.

Aside from that, new kernel options are almost never added within LTS
branch releases, so I just run make oldconfig and I'm done. You do
get the rare change, and it is very easy to manage those.

The downside is if you want some new kernel feature you won't get it,
and you might need to update for support for new chipsets/CPUs if
you're upgrading. That isn't a big deal to manage as I don't do it
often.

I can't remember the last time an LTS kernel blew up on me, but I
never rush out to update a kernel the day it is released.
Occassionally I do see a regression fixed and it tends to happen
fairly quickly.

All that said, it would be nice if the kernel had more of a QA
process. I think the kernel has basically deferred all of that to
distros, which means by running an upstream kernel I get none of it.
The upstream kernel config defaults are also less than ideal, which is
something distros also manage.

[Dale]

Post by Dale
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while.  I tried upgrading
to I think 5.16 and then more recently 5.18.  I upgraded like I always
do, copy .config over and run make oldconfig.  Once I get everything in
/boot, init thingy and all, I update grub.  When I get around to
rebooting, the new kernels always fail part way through booting.  I
can't recall the error since I last tried a newer kernel several months
ago. 
I'm about to try to jump to version 6.0.5 which is latest in the tree. 
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?  Do I need to configure a new kernel from
scratch in other words?  While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing
updating from older versions.  I just don't know which it is. Me or it. 
Thoughts?
Thanks.
Dale
:-)  :-) 

Little update.  This nvidia driver problem, see other thread, was
getting on my nerve.  After my weekly sync and package updates were
done, I rebooted.  The new kernel booted just fine.  I guess the other
two kernels just went bad, most likely my fault but who knows.  So,
upgrading from a older 5.14 kernel to a 6.0 kernel is doable. 
Everything booted just fine. 

I'm back to my old kernel tho since my nvidia-drivers won't work with a
kernel that high.  I run into this on rare occasions.  Most of the time
it works but on rare occasions, it fails.  Maybe with the next nvidia
update it will work.  According to the info it puked on my keyboard,
5.19 or so is the latest nvidia supports. 

I did re-emerge the nvidia drivers for the old kernel.  So far, my
second screen appears to be working.  When I rebooted, both screens
worked without me having to reconfigure several times.  I have not
turned off my two TVs to be 100% sure tho.  My reboot was short enough
the TVs stayed powered up.  I'm not sure if them powering off triggers
it or not but powered off is usually where I start. 

If I get bored, and it warms up a little, I may build a 5.19 kernel. 
Thing is, by the time I get around to rebooting, nvidia may have updated
and the new one I already got will work.  :/

Thanks to all.

Dale

:-)  :-) 

[Rich Freeman]

Post by Dale
I'm back to my old kernel tho since my nvidia-drivers won't work with a
kernel that high. I run into this on rare occasions.

They are only rare because you aren't updating regularly.

If you want to run external kernel modules like nvidia-drivers or zfs,
stick to a longterm kernel. The ABI changes all the time, and so
there will frequently be stable kernel version changes that break
nvidia-drivers. Then there will be a lag before nvidia-drivers
supports the new stable kernel. In the meantime you can't run the
latest version, and that can mean security issues.

The longterm kernels rarely break nvidia-drivers and get all the
security and other fixes. They just don't get new features.

[Dale]

Post by Rich Freeman

Post by Dale
I'm back to my old kernel tho since my nvidia-drivers won't work with a
kernel that high. I run into this on rare occasions.

They are only rare because you aren't updating regularly.
If you want to run external kernel modules like nvidia-drivers or zfs,
stick to a longterm kernel. The ABI changes all the time, and so
there will frequently be stable kernel version changes that break
nvidia-drivers. Then there will be a lag before nvidia-drivers
supports the new stable kernel. In the meantime you can't run the
latest version, and that can mean security issues.
The longterm kernels rarely break nvidia-drivers and get all the
security and other fixes. They just don't get new features.

Well, I was calling how often this has happened since around 2003 or so
when I started using Linux.  I think this has happened maybe two or
three times.  While they always say they don't support above a certain
version, usually it just works.  This time, not so much. 

I did build a 5.19 version tho.  I haven't rebooted yet tho.  May be a
while.  o_O

Dale

:-)  :-) 

[Grant Edwards]

I did re-emerge the nvidia drivers for the old kernel. [...]
If I get bored, and it warms up a little, I may build a 5.19 kernel. 
Thing is, by the time I get around to rebooting, nvidia may have updated
and the new one I already got will work.  :/

About 15 years ago, after a bad experience with ATI dropping Linux
driver support for a card that was only a year old (and no luck
getting the open source driver to work reliably), I switched to NVidia
(mostly Qaudro cards -- fanless until that ceased to be an
option). They always worked great using the NVidia blob drivers, but
using NVidia drivers was a constant source of minor pain. Often kernel
updates had to be postponed until NVidia driver support caught up, and
they too dropped support and forced me to replace a board that was
still working perfectly.

Eventually, I just gave up and started using built-in Intel
graphics. Life was much easier. A high-end gamer probably wouldn't be
happy, but my mid-range mainboard happily drove three decent-sized
displays (two DVI and one DP) at their native resolutions. I find the
same to be true on my newer AMD system with built-in Radeon Vega
graphics. It too "just works" with the in-kernel-tree support and
open-source Xorg drivers.

I did have to give up the option of having multiple X11 screens. The
proprietary NVidia driver supported multiple screens, but the drivers
for built-in Intel and Radeon drivers don't seem to.

--
Grant

[Michael]

Post by Grant Edwards

I did re-emerge the nvidia drivers for the old kernel. [...]
If I get bored, and it warms up a little, I may build a 5.19 kernel.
Thing is, by the time I get around to rebooting, nvidia may have updated
and the new one I already got will work. :/

About 15 years ago, after a bad experience with ATI dropping Linux
driver support for a card that was only a year old (and no luck
getting the open source driver to work reliably),

I had a similar experience about the same time, ATI proprietary drivers
stopped working and the kernel driver was performing poorly - tearing when
playing videos, etc. Within a few months the kernel driver improved
significantly and saved me the cost of buying another graphics card.

Post by Grant Edwards
I switched to NVidia
(mostly Qaudro cards -- fanless until that ceased to be an
option). They always worked great using the NVidia blob drivers, but
using NVidia drivers was a constant source of minor pain. Often kernel
updates had to be postponed until NVidia driver support caught up, and
they too dropped support and forced me to replace a board that was
still working perfectly.
Eventually, I just gave up and started using built-in Intel
graphics. Life was much easier. A high-end gamer probably wouldn't be
happy, but my mid-range mainboard happily drove three decent-sized
displays (two DVI and one DP) at their native resolutions. I find the
same to be true on my newer AMD system with built-in Radeon Vega
graphics. It too "just works" with the in-kernel-tree support and
open-source Xorg drivers.

By accident rather than design I ended up using mostly Radeon cards over the
years. I also had a laptop with Intel graphics. Both intel and radeon have
been working without problems with kernel drivers, but I am not a gamer to
stress them to their limit.

Post by Grant Edwards
I did have to give up the option of having multiple X11 screens. The
proprietary NVidia driver supported multiple screens, but the drivers
for built-in Intel and Radeon drivers don't seem to.
--
Grant

AMD APUs with embedded radeon graphics work fine here with two monitors (DVI +
HDMI ports).

[Grant Edwards]

Post by Michael

Post by Grant Edwards
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.

AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).

Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.

It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.

https://wiki.archlinux.org/title/multihead#Separate_screens

[Michael]

Post by Grant Edwards

Post by Michael

Post by Grant Edwards
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.

AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).

Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens

You're right, I thought you meant two different monitors in Xinerama style. I
didn't know anyone who still uses separate displays (screens) these days.

[Grant Edwards]

Post by Michael

Post by Grant Edwards

Post by Michael

Post by Grant Edwards
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.

AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).

Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens

You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.

I found it very helpful when I dealing with interruptions (which is
about 50% of a typical day). I could flip one of the screens to a new
virtual desktop (while leaving my email and web browser as-is on the
other screen), deal with the interruption, then flip that screen back
to the desktop containing whatever I was origininally working on.

My office setup had three screens, each with four virtual desktops.

When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).

There are two main drawbacks to the multiple-screen setup:

* You can't drag a window from one screen to the other. With the
monitor sizes that are common now, that's not as big an annoyance
as it used to be.

* There are a few brain-dead (but vital) applications (e.g. Chrome)
that refuse to allow a user to run either multiple instances of the
application or allow windows on multiple screens (or X
servers). I'm a bit baffled by that restriction, but I'm sure it
allowed the developers to take some shortcut that saved 12 bytes of
data and 10 or 15 lines of code (out of many hundreds of megabytes
of occupied RAM and millions lines of code).

That said, you're right: using mulitple screens is no longer common.
It's not even supported by many desktops these days. I switched from
XFCE to openbox when XFCE dropped support for multiple screens.

--
Grant

[Michael]

Post by Grant Edwards

Post by Michael

Post by Grant Edwards

Post by Michael

Post by Grant Edwards
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.

AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).

Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens

You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.

I found it very helpful when I dealing with interruptions (which is
about 50% of a typical day). I could flip one of the screens to a new
virtual desktop (while leaving my email and web browser as-is on the
other screen), deal with the interruption, then flip that screen back
to the desktop containing whatever I was origininally working on.
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).

I found Enlightenment to be most versatile in this respect. Unlike say
Plasma, which has two monitors locked on the same virtual desktop and when you
switch to another virtual desktop *both* monitors flip over, in Enlightenment
each monitor can switch to a different virtual desktop independently. Like
you, I keep always-on stuff on the left monitor, while switching between
different virtual desktops on the right monitor.

Post by Grant Edwards
* You can't drag a window from one screen to the other. With the
monitor sizes that are common now, that's not as big an annoyance
as it used to be.

With Enlightenment you can move windows across monitors, irrespective of the
virtual desktop each monitor displays.

Post by Grant Edwards
* There are a few brain-dead (but vital) applications (e.g. Chrome)
that refuse to allow a user to run either multiple instances of the
application or allow windows on multiple screens (or X
servers). I'm a bit baffled by that restriction, but I'm sure it
allowed the developers to take some shortcut that saved 12 bytes of
data and 10 or 15 lines of code (out of many hundreds of megabytes
of occupied RAM and millions lines of code).
That said, you're right: using mulitple screens is no longer common.
It's not even supported by many desktops these days. I switched from
XFCE to openbox when XFCE dropped support for multiple screens.
--
Grant

[Grant Edwards]

Post by Michael

Post by Grant Edwards

Post by Michael
You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.

I found it very helpful when I dealing with interruptions (which is
about 50% of a typical day). I could flip one of the screens to a new
virtual desktop (while leaving my email and web browser as-is on the
other screen), deal with the interruption, then flip that screen back
to the desktop containing whatever I was origininally working on.
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).

I found Enlightenment to be most versatile in this respect. Unlike
say Plasma, which has two monitors locked on the same virtual
desktop and when you switch to another virtual desktop *both*
monitors flip over,

That's how all of virtual-desktop window managers I've tried over the
decades work.

Post by Michael
in Enlightenment each monitor can switch to a different virtual
desktop independently. Like you, I keep always-on stuff on the left
monitor, while switching between different virtual desktops on the
right monitor.

Post by Grant Edwards
* You can't drag a window from one screen to the other. With the
monitor sizes that are common now, that's not as big an annoyance
as it used to be.

With Enlightenment you can move windows across monitors,
irrespective of the virtual desktop each monitor displays.

That's Cool. I might have to give Enlightenment a try one of these
days.

How well does focus-follows-mouse work? With openbox there are a
couple scenarios where you can get the mouse in a window without that
window having focus until you move the mouse out of the window and
then back in again. I trip over that once or twice a day: I start
typing without noticing that the window where the mouse is does not
have focus. Then I've got stop, find the window that does have focus,
and figure out what damage that typing did.

--
Grant

[Frank Steinmetzger]

Post by Grant Edwards

Post by Michael

Post by Grant Edwards
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).

I found Enlightenment to be most versatile in this respect. Unlike
say Plasma, which has two monitors locked on the same virtual
desktop and when you switch to another virtual desktop *both*
monitors flip over,

That's how all of virtual-desktop window managers I've tried over the
decades work.

As a workaround within Plasma: set the window on your static monitor to show
on all virtual desktops. It won’t even animate when you change the desktop.
I use this feature mostly with video players, and even set a window rule to
be applied automatically upon launching a player.

Post by Grant Edwards

Post by Michael
in Enlightenment each monitor can switch to a different virtual
desktop independently.

Awesome WM also does this independently on separate screens. Just tested it.

[Wol]

Separate displays is useful for multi-headed systems. I know a couple people who buy one, high-power desktop for the whole family and then attach multiple screens and input devices.
If you want to do that, but your GPU can't handle multiple X displays, you can still set it up by using one master X server, and then running multiple, nested X servers, each given a specific region (which may or may not correspond precisely to one or more screens, but that's usually what you'd want). Attach the IO devices to the nested ones obviously.

I'm trying to do that. I understood that video cards didn't support it,
so I have two video cards, but I haven't managed to get both of them
working together, so far ... (couldn't even get the computer to boot
properly last I tried ...)

Cheers,
Wol

[Mark Knecht]

Post by Grant Edwards
They always worked great using the NVidia blob drivers, but
using NVidia drivers was a constant source of minor pain. Often kernel
updates had to be postponed until NVidia driver support caught up, and
they too dropped support and forced me to replace a board that was
still working perfectly.

The "waiting to catch up issue" is the reason I switched to the LTS
kernels. If the kernel got a minor bump the NVidia drivers still worked.

When a new LTS kernel came out NVidia would have a new driver
almost immediately and through the life of that LTS kernel I got
easy kernel updates and easy NVidia driver updates.

I don't personally remember NVidia ever dropping a card totally
but I did get confused for awhile when they started segmenting their
drivers by different families and it was up to me to figure out which
driver package handled my card.

- Mark

[Grant Edwards]

Post by Mark Knecht
I don't personally remember NVidia ever dropping a card totally
but I did get confused for awhile when they started segmenting their
drivers by different families and it was up to me to figure out which
driver package handled my card.

IIRC, towards the end, that card was still supported by the "legacy"
driver, but that required a kernel so old that other things I used
everyday wouldn't work.

[Mark Knecht]

Post by Grant Edwards

Post by Mark Knecht
I don't personally remember NVidia ever dropping a card totally
but I did get confused for awhile when they started segmenting their
drivers by different families and it was up to me to figure out which
driver package handled my card.

IIRC, towards the end, that card was still supported by the "legacy"
driver, but that required a kernel so old that other things I used
everyday wouldn't work.

Ah, bummer. I guess I probably bought new cards once in a while
and never ran into that problem.

I think there's a bunch of 32-bit users in the same boat... ;-)

Thanks for the clarification.