The Latest Kernel Release.

Didier Spaier · 01-04-2023, 02:27 PM

Quote:

Originally Posted by Jan K.

The usual handful of btrfs fixes, of course, but... there's a million ext4 fixes!

I will will skip 6.1.3 and ship 6.1.4. I am also eager to try 6.2-rcx which should bring huge enhancements for both btrfs and zstd, but this is not urgent. I have no issue with 6.1.2 so far on several systems. WRT btrfs I must say that the devs are very helpful on the matrix channel, including answering newbie questions.

kjhambrick · 01-04-2023, 06:00 PM

all --

Generic Kernel Version 6.1.3.kjh is running fine on my Slackware64 15.0 + Multilib LapTop.

No CVE References were found for 6.1.3, 6.0.17 or 5.10.162, but as always, do check the ChangeLogs for other security-related fixes.

-- kjh

Code:

uname -msrpn: Linux kjhlt7.kjh.home 6.1.3.kjh x86_64 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz
firmware ...: kernel-firmware-20230104_4ee2014-noarch-1              # upgraded
NVidia Blob : NVIDIA-Linux-x86_64-525.60.11.run
VMWare Blob : VMware-Workstation-Full-17.0.0-20800274.x86_64.bundle  # upgraded

cwizardone · 01-05-2023, 06:44 AM

Quote:

Originally Posted by 3rensho

Kernel-6.1.3 built sans problems and is running fine with Nvidia-525.60.11. Logs look good.

Quote:

Originally Posted by bathory

Same here with the legacy Nvidia-470.161.03 drivers.

Ditto with the 6.1.3 kernel from -current/testing and the Nvidia-470.161.03 driver.

cwizardone · 01-05-2023, 09:56 AM

An update for the 4.9.y series has been scheduled for release on Saturday, 7 January 2023, at approximately 12:00, GMT.
The details,
4.9.337-rc1 with 251 patches, https://lkml.iu.edu/hypermail/linux/...1.0/04189.html

Quote:

From: Greg Kroah-Hartman
Date: Thu Jan 05 2023 - 07:58:57 EST
-------------------------------------------
NOTE:
This is going to be the LAST 4.9.y release to be made by the stable/LTS
kernel maintainers. After this release, it will be end-of-life and you
should not use it at all. You should have moved to a newer kernel
branch by now (as seen on the https://kernel.org/category/releases.html
page), but if NOT, and this is going to be a real hardship, please
contact me directly.

jkh2cpu · 01-05-2023, 01:30 PM

Using the kernel in testing (6.0.3) and the latest nvidia driver, I see this in /var/log/Xorg.0.log:

[ 515.774] (EE) nv: module ABI major version (24) doesn't match the server's version (25)
[ 515.774] (EE) Failed to load module "nv" (module requirement mismatch, 0)

Anyway, if I'm in a KDE session and I CTL-ALT-F2, I get a black window that never resolves to a terminal login, and I cannot F1 back into the running KDE sesssion.

If I log out of KDE, it takes quite a while before I'm back in a terminal window.

If I try to set up for startkwayland by running this: 'modprobe -r nvidia_drm ; modprobe nvidia_drm modeset=1' the terminal screen goes to hell and gives my a barely functioning window of which maybe rows 12-16 respond to keyboard entry. From that I can reboot.

I'm guessing the kernel is OK, but nvidia really seems to need an update. If I back up to kernel-6.0.17, startx and startkwayland are stable, with startx being the smart choice (right now.)

volkerdi · 01-05-2023, 01:56 PM

Quote:

Originally Posted by jkh2cpu

Using the kernel in testing (6.0.3) and the latest nvidia driver, I see this in /var/log/Xorg.0.log:

[ 515.774] (EE) nv: module ABI major version (24) doesn't match the server's version (25)
[ 515.774] (EE) Failed to load module "nv" (module requirement mismatch, 0)

The xf86-video-nv package was removed from -current back in August. Several others were removed at the same time. A few of them have since come back, but nv is not one of them.

cwizardone · 01-06-2023, 01:54 AM

Just found this exchange concerning the next LTS kernel.

Quote:

Re: [PATCH 6.1 000/207] 6.1.4-rc1 review
From: Greg Kroah-Hartman
Date: Fri Jan 06 2023 - 01:59:00 EST
On Thu, Jan 05, 2023 at 08:34:08PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 6.1.4 release.
> > There are 207 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
>
> Thank you.
>
> Is it known at this point if 6.1 will became next longterm release? It
> is not listed as such on https://www.kernel.org/category/releases.html
> . We might want to do some extra testing if it is.

A kernel can not become "long term" until it would have normally dropped
off of support. Right now there are known-regressions in 6.1 still that
are not resolved.

And "extra" testing is always good no matter what kernel branch it is
happening for, why not always do it?

thanks,
greg k-h

https://lkml.iu.edu/hypermail/linux/...1.0/05237.html

kjhambrick · 01-06-2023, 06:22 AM

Quote:

Originally Posted by cwizardone

LQ Post #5074: https://www.linuxquestions.org/quest...ml#post6398474

From: https://lkml.iu.edu/hypermail/linux/...2.2/01070.html

Quote:

Re: Reg the next LTS kernel (6.1?)
From: Greg KH
Date: Sat Dec 17 2022 - 08:18:52 EST
You tell me please. How has your testing gone for 6.1 so far? Does it
work properly for you? Are you and/or your company willing to test out
the -rc releases and provide feedback if it works or not for your
systems? Do you have problems with 6.1.y vs. older kernels? Is there
anything missing in it that you feel needs to be addressed with a newer
kernel instead? ...

Quote:

Originally Posted by cwizardone

Just found this exchange concerning the next LTS kernel.

LQ Post #5167: https://www.linuxquestions.org/quest...ml#post6402524

From: https://lkml.iu.edu/hypermail/linux/...1.0/05237.html

Quote:

Re: [PATCH 6.1 000/207] 6.1.4-rc1 review
From: Greg Kroah-Hartman
Date: Fri Jan 06 2023 - 01:59:00 EST

A kernel can not become "long term" until it would have normally dropped off
of support. Right now there are known-regressions in 6.1 still that are not resolved...

Greg K-H's most recent comment shines a little light on his previous exchange

IOW, 6.1 wouldn't be marked LTS until 6.2 replaces it and more importantly, in Greg K-H's opinion, 6.1.y is not ready yet ...

Fingers X'd while running 6.1.y on my Work Laptop

-- kjh

marav · 01-06-2023, 06:31 AM

From what I understand, if people are not involved in testing and reviewing kernels, even 6.2, they won't be labeled as LTS.

LuckyCyborg · 01-06-2023, 06:51 AM

Quote:

Originally Posted by marav

From what I understand, if people are not involved in testing and reviewing kernels, even 6.2, they won't be labeled as LTS.

From what I understand, if companies are not involved in using a particular kernel series, even 6.2, they won't be labeled as LTS.

The LTS kernels are for Industry, not for people.

marav · 01-06-2023, 08:17 AM

Quote:

Originally Posted by LuckyCyborg

From what I understand, if companies are not involved in using a particular kernel series, even 6.2, they won't be labeled as LTS.

The LTS kernels are for Industry, not for people.

In fact, it's both
QUESTION:

Code:

Hi,
Any update on 6.1 being set as the next LTS release?

ANSWER:

Code:

You tell me please. How has your testing gone for 6.1 so far? Does it
work properly for you? Are you and/or your company willing to test out
the -rc releases and provide feedback if it works or not for your
systems? Do you have problems with 6.1.y vs. older kernels? Is there
anything missing in it that you feel needs to be addressed with a newer
kernel instead?

Code:

Sorry, but you didn't answer any of my questions, which makes it
impossible for me to answer yours as my answer depends on your answer.

Greg KH
https://lkml.iu.edu/hypermail/linux/...2.2/index.html

And this:

Quote:

Originally Posted by LuckyCyborg

The LTS kernels are for Industry, not for people.

is a POV, nothing more

kjhambrick · 01-06-2023, 08:34 AM

I for one, like to find a longterm Kernel that will be around until I retire my current System ( 4 -or- 5 Years or so )

That way I can simply rebuild Kernels via `make oldconfig`.

OTOH, as of now, 5.15 will go EoL in October and I am still trying to get my 'Discrete Thunderbolt 4' Chip to work as Thunderbolt 4 and not USB 3.2

So I jumped to 6.1 anticipating that it will be longterm.

If it is announced as longterm, GREAT !

If not, I am a little worried about the inclusion of rustc in 6.2 as well as the 'unified kernel images' Project which sounds like Leonart and his minions want to own my PeeCee

Anyhow ...

-- kjh

teoberi · 01-06-2023, 09:06 AM

What the hell is going on with open-source software?
There are some cases where things go wrong (you can see if you follow their development), now the Linux kernel is added!

kjhambrick · 01-06-2023, 09:45 AM

I dunno toeberi

I generated a 'free link' from within my LWN Account about the latest UKI Proposal.

LWN Article: Supporting unified kernel images for Fedora

It concerns me -- who will own my PeeCee when UKI is complete ?

-- kjh

LuckyCyborg · 01-06-2023, 10:17 AM

Quote:

Originally Posted by kjhambrick

I dunno toeberi

I generated a 'free link' from within my LWN Account about the latest UKI Proposal.

LWN Article: Supporting unified kernel images for Fedora

It concerns me -- who will own my PeeCee when UKI is complete ?

-- kjh

The support for embedding an initrd in the kernel binary exists since 2015, it's nothing new.

So, who owned your PeeCee since 2015? You? Then, same will be in the foreseeable future.

In fact, the challenge which Fedora have to solve is not how to embed an initrd in the kernel binary, but how to build an "universal initrd" capable to cope with all user cases. About how to build those "universal initrds" talks Mr. Poettering, the rest are collateral details.

Anyway, an "universal initrd" for Fedora will be obviously very different of an "universal initrd" for Slackware.

I for one, I believe that an "universal initrd" embedded in the kernel binary will be also for Slackware a very nice solution which will simplify a lot the kernels management from the users side.

Imagine a generic kernel (but as file even bigger than the huge kernel), which will do anything you do today with using an initrd along with the generic kernel. No need to take care of generating initrds manually or automatically, no need to add an additional line in lilo.conf - deemed by some people here as a huge complication, nothing.

BUT, again, the question is how you can make an "universal initrd" capable to deal with all user cases, with no need to be customized by user. I.e. for Slackware. This is a very dificult task and very specific to the host Linux distribution.