Use kernel base+patch file

[thomas]

The kernel sources are provided either as a full tarball (which we are using currently) or as a base tarball plus a patch file. That is for example as base linux-6.16.tar.xz and the patch file patch-6.16.1.xz.

Since kernel updates occur pretty frequent (weekly?), using the patch file variant would reduce the download size as it will not be required to retrieve over 150MB over and over again. The patch size of 6.16.1 is actually 200KB (of course increasing from version to version).

In addition to saving some bytes on disk its a variant we do not have on any other package. I think it may be interesting to see how frequent updates can be handled without constantly retrieving the whole package file.

Editing impact on the book is marginal - i've implemented that variant in the MLFS book as a POC.

---

There are also patch files from x.y.z to x.y.(z+1). They are pretty small but using them would require to really use all of them, you cannot skip one. It does only make sence if you have a kernel source dir constantly unpacked and you want to follow every single release. Not partical for LFS, imho.

[Bruce Dubbs]

I do not like this proposal. How long does it take to download the full package? A first time builder would need to download the base file and the patch file and apply the patch. This makes things more complicated.

Additionally, how often to users need to update the kernel? My workstation is still on 6.12.7 without any issues.

In addition, the full minor version is updated every couple of months and the full version would have to be downloaded then anyway.

[thomas]

Replying to Bruce Dubbs:

I do not like this proposal. How long does it take to download the full package? A first time builder would need to download the base file and the patch file and apply the patch. This makes things more complicated.

Applying a patch is what we do on other packages, too. There is nothing new. It is only one additional identical command in two pages. I don't see what is complicated with that.

Additionally, how often to users need to update the kernel? My workstation is still on 6.12.7 without any issues.

Its your personal decision to not upgrade the workstation. The LFS book is updated every two weeks or so and most of the time, a kernel update happens with this updates. If a package update in LFS happens, at least we as editors should work on this current versions. That implies that we have to follow the new kernel version, too.
Even the note in chapter 4 says that the most recent kernel instead of the one in the book might be used which implies that we ask the user for upgrading his kernel when available.
In another discussion about why not using the longterm line of the kernel, it has been argued that there might be new hardware support and security fixes so we should always use the newest stuff in the book.

In addition, the full minor version is updated every couple of months and the full version would have to be downloaded then anyway.

Yes, one time. Subsequently, to keep track with the most recent kernel, it is relatively small patch files.

Thanks for telling your opinion! Maybe others will speak up, too.

[zeckma]

For Steam, a noticeable behavior is that sometimes it will fail to open a window for any given game launching unless the kernel gets updated. Sometimes, even on the same minor, the latest patch must be installed. To me, the whole patch usecase to me seems like a decent approach for situations like that. But Steam is outside LFS+BLFS.

Thus, I think what would suffice is mentioning that users can instead download the base kernel tarball + a patch, although the book will still do the full source tarball approach. In most cases, that is what most users would want to go with. Though I'd personally use the base version + patch approach to make things easier. Thus, such a note would go a long way.

[Xi Ruoyao]

To me if you really need to upgrade the kernel so frequently, the easiest approach would be using git to manage a clone of ​https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git.

[thomas]

Replying to Xi Ruoyao:

To me if you really need to upgrade the kernel so frequently, the easiest approach would be using git to manage a clone of ​https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git.

Thanks for the link, but its not about me updating my machines. Its about the book which follows the releases of the upstream packages and the kernel is one of them. It emits new releases quite quickly, one a week or so. Whenever a new release is emited, dev-book is updated, at least in the arbitrary 2-week cycle. I assume that the ones how do update the book, have built the updated packages. If they do, they must have been downloading the package.

Despide the waste of bandwidth and storage (right, both are no longer expensive nowadays and the kernel is by far not the heaviest pkg we have. If disk is full, older versions can be simply deleted ;-) ), its just a way to show how things can be done in this case. Thats what LFS was made for.

[Bruce Dubbs]

What I propose is to add a section to the kernel page that describes this method and let the user choose. However we should leave the default as it is.

I do have a question about the patches though. When I look at upstream, I see:

linux-6.16.tar.xz                                  28-Jul-2025 04:09    146M
patch-6.16.1.xz                                    15-Aug-2025 14:52    196K
patch-6.16.2.xz                                    20-Aug-2025 17:07    389K
patch-6.16.3.xz                                    23-Aug-2025 14:54    395K
patch-6.16.4.xz                                    28-Aug-2025 14:58    529K
patch-6.16.xz                                      28-Jul-2025 04:09      7M

Do those patches (1-4) need to be applied individually or is that patch-6.16.xz a cumulative patch? This would need to be explained.

I will note that if a user wants to use a LTS kernel, the number of patches gets to be quite large. For instance there is:

patch-6.6.103.xz 28-Aug-2025 14:50 5M

For that matter:

linux-5.4.297.tar.xz 28-Aug-2025 14:28 108M

:)

[Xi Ruoyao]

Just use one, i.e. patch-6.16.4.xz. There are also "incremental" patches those should be applied one by one at ​https://cdn.kernel.org/pub/linux/kernel/v6.x/incr/.

[thomas]

no, you don't need all of them, just one as Xi already mentioned. When starting with version 6.16 then you'll download linux-6.16.tar.xz. Whenever a new kernel version appears, you do not need the full tarball of lets say linux-6.16.4.tar.xz but just the patch-6.16.4.xz.

What you will do is

tar -xf linux-6.16.tar.xz
cd linux 6.16
xzcat ../patch-6.16.4.xz | patch -Np1
...

So, this variant is going from the base version (6.16) to the actual version (6.16.4) in one step and this is what i'm talking about.

If you want to have a proper source tree laying around, then you might use the incremental patches which goes just one step ahead, lets say from 6.16.3 to 6.16.4. Assuming you have a source tree of 6.16.3 (either by using linux-6.16.3.tar.xz or by linux-6.16.tar.xz+patch-6.16.3.xz), you can simply do a

cd linux-6.16
xzcat ../patch-6.16.3-4.xz | patch -Np1
...

in the existing dir. It will then be on 6.16.4. With this, you can only move one patch level further. When u need to go from 6.16.4 to 6.16.6, you'll need the two incremential patches 4-5 and the 5-6. But that is not what we do in the book, we're doing a "unpack-build-delete", we do not keep any source dir.

[Bruce Dubbs]

Fixed at commit bea355bc6a.