Stable kernel 5.15.5

Posted Nov 27, 2021 20:49 UTC (Sat) by birdie (guest, #114905)
In reply to: Stable kernel 5.15.5 by tuna
Parent article: Stable kernel 5.15.5

Writing or mentioning "must update" or "should upgrade". This is *wrong*, *bad* and *dishonest*. You're relaying an opinion of someone who doesn't give a flying .... whether this or that update has been properly tested and whether it's regression-free as seen by a constant stream of "Revert(ing)" in "stable" kernel logs. Yes, most of such reverts are for previous "stable" patches.

If you're an LWN editor who prepares these articles, I'd really like you to change how you present the changelog.

Currently it's

Author 1
subsys1: patch 1
subsys1: patch 2
subsys2: patch 1

Author 2
subsys3: patch 1
subsys3: patch 2
subsys4: patch 1

Instead it would be a TON easier to read it this way:

Subsys1
patch 1 (author 1)
patch 2 (author 1)
patch 3 (author 2)

Subsys2
patch 1 (author 3)
patch 2 (author 4)
patch 3 (author 5)

Of course no one will do it and no one will actually read these changelog because the way the info is presented is quite unpleasant and inconvenient to read.

Stable kernel reporting

Posted Nov 27, 2021 20:53 UTC (Sat) by corbet (editor, #1) [Link]

I'm sorry if you don't like how we report on stable updates. But, with regard to the updates themselves, please bear in mind that you are attacking the work of somebody who puts in vast amounts of time to make these updates available to you, for free. I don't doubt he would appreciate some help if you know how to do it better.

With regard to the changelogs, those come with the updates and are generated directly from Git. Per-subsystem would be a lot harder to do. I classify patches by subsystem for the weekly edition patch listing; it takes a fair amount of time and it's often not obvious where a given patch should go. If somebody were to offer to provide this classification service for you, for free naturally, I don't doubt you would take issue with how many patches are sorted. Just can't win, I guess.

Stable kernel 5.15.5

Posted Nov 28, 2021 12:19 UTC (Sun) by alspnost (guest, #2763) [Link] (9 responses)

Jon and the LWN team are providing the changelogs as generated, as Jon has now explained below. As for the wording, Greg himself says "must upgrade", which does seem pointlessly strong, and Jon moderates it to "should upgrade". I wonder how many people actually do, though? How many are running a self-compiled 5.15 kernel, and re-compile for every patch release? Probably very few.

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 14:51 UTC (Sun) by amacater (subscriber, #790) [Link] (7 responses)

There's an element of: almost nobody does this, but it would be _really_ helpful if more did. Every successive kernel release supports a bunch more hardware - and fixes more security and other bugs that have been found. Chasing kernel bugs is a thankless task and asymptotic: you have to hope that each release fixes a few more bugs than it introduces. Greg and the other maintainers do this for everyone on minimal feedback, maximal complaints and almost no thanks.

It would be useful if more people followed the stable releases, filed installation reports and bug reports. The distributions tend to pick a kernel release at a point in time and support that from then forward as their stable version. Every distribution has some trade off in this.

To the person stating that the only good kernels are those from Red Hat - yes, they have lots of kernel maintainers on staff but the versions released with Red Hat are invariably older to start with and have to be maintained for a very long time for a subset of hardware - that makes them very much a custom build.

/me wonders how hard it would be to follow stable releases to check how well/badly this works for a while ...

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 16:38 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

> /me wonders how hard it would be to follow stable releases to check how well/badly this works for a while ...

Not that hard ...

Dunno what distro you're on, but if you've got a spare old computer (or even just an old hard drive), intall gentoo. Follow the handbook instructions to install it, especially building the kernel. This is just a learning experience, once you think you know what you're doing, we'll abandon it and do it for real on your regular distro.

Find the git tree for the kernel you want to run, and install it on your main system into /usr/src/linux. Download the source for your disto kernel, and copy their .config into /usr/src/linux.

Use the skills you learnt installing gentoo to compile and install the kernel, build an initramfs, and configure it into grub or UEFI, or whatever your boot setup is.

People are scared of building kernels nowadays. But the old hands did it all the time ...

Cheers,
Wol

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 16:51 UTC (Sun) by sashal (✭ supporter ✭, #81842) [Link]

Most distros have "upstream" options already: Ubuntu for example has https://kernel.ubuntu.com/~kernel-ppa/mainline/ which builds a kernel for each released -stable kernel. Supposedly it has users too :)

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 22:25 UTC (Sun) by tuna (guest, #44480) [Link]

If you use Fedora it is pretty simple to build (and patch) Linux from the rpm sources. Then you get it in the bootloader and it is easy to uninstall as well.

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 23:21 UTC (Sun) by dskoll (subscriber, #1630) [Link]

On Debian, it's pretty easy. The kernel Makefile has a bindeb-pkg target that builds .debs for you. I have a hacky shell script that downloads and builds me debs from the latest upstream kernel. It's specific to my system, but the guts of it are these commands (edited to remove error-checking, etc) that assume the source is in linux-$VERSION:

CONFIG=`ls -1rt /boot/config* | tail -n 1`
cp $CONFIG linux-$VERSION/.config
make -C linux-$VERSION oldconfig
make -C linux-$VERSION -j`nproc` bindeb-pkg

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 28, 2021 23:24 UTC (Sun) by dskoll (subscriber, #1630) [Link] (2 responses)

/me wonders how hard it would be to follow stable releases to check how well/badly this works for a while ...

I did this for a while, but sadly had to revert back to Debian's stable kernel. I have a new computer, and the igb Ethernet driver seems to misbehave on the latest kernels. I reported the bug, but it's a tough one to reproduce and the driver's author doesn't officially support Debian, so this is a difficult issue. :(

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 29, 2021 17:40 UTC (Mon) by andresfreund (subscriber, #69562) [Link] (1 responses)

Random idea re that bug: You can't run RHEL to repro as requested, because it's your daily driver machine (been there). Perhaps you could "survive" passing the card through to a VM running RHEL though? Of course that's only comfortable if you have another way of accessing network, but that's often easy enough.

Stable kernel 5.15.5 - maybe help test, file bugs and say thank you?

Posted Nov 30, 2021 22:37 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Hmm, interesting idea. I have a USB Wifi dongle I can use to access the network if the Ethernet interface is down, so I suppose I could try that. Thanks for the suggestion.

Stable kernel 5.15.5

Posted Nov 30, 2021 14:27 UTC (Tue) by birdie (guest, #114905) [Link]

I run vanilla stable kernels, and I know tons of people who do the same.

The reasons:

1. Distro kernels enable almost everything which 1) not only makes them use a ton of extra space 2) decreases security as odd modules are a frequent source of vulnerabilities 3) makes the kernel slower 4) makes the kernel boot slower as vmlinuz is a lot bigger. My kernel 5.15 weighs in at just 4.3MB, while Fedora's is over 10MB.

2. Faster bug fixes

3. Being up to date with new kernel features (make oldconfig).