Arch Linux User Repository

These packages allow you to have multiple versions of the Arch LTS kernel installed simultaneously. The intended use is to install the linux-lts-versioned-bin (and linux-lts-versioned-headers-bin if you use out-of-tree drivers) metapackage, using an AUR helper or otherwise in a way that automatically processes dependencies. This metapackage depends on the latest LTS versioned kernel package, but older kernel packages will remain on your system as orphaned packages to be removed later. You can find and remove them with the remove-orphaned-kernels script, which will uninstall orphaned kernel packages except those corresponding to the kernel that is currently running. If you use GRUB, you will also need to ensure its config is updated after kernels are added or removed. Installing the grub-hook package will ensure this is done automatically.

To switch from the regular Arch kernel package to these versioned packages, you can do the following (using the AUR helper yay for example):

# Remove linux, linux-headers if installed, and any out-of-tree drivers for the regular kernel:
$ pacman -Rs linux-lts [linux-lts-headers] [nvidia-lts] [...]
# Install dkms versions of any out-of-tree drivers you need:
$ pacman -S [nvidia-dkms] [...]
# If using GRUB, install grub-hook before installing kernels:
$ yay -S grub-hook
# Install the kernel metapackage, and headers metapackage if you use out-of-tree drivers:
$ yay -S linux-lts-versioned-bin [linux-lts-versioned-headers-bin]

This is also discussed here.

See also:

• linux-versioned-bin

• linux-zen-versioned-bin

• linux-hardened-versioned-bin

look good chris, thanks!

@tessaracht thanks for the report. This should be fixed, you'll likely need to clean-build as I have not bumped the pkgrel (which so far I've kept in sync with the underlying package - may or may not be the best approach).

Looks like they decided to include licenses in the package. So far it seems to only be the lts package that includes licenses, but I'm guessing the same will be true of the other kernel packages soon enough, so I'll adjust their PKGBUILDs when that happens.

seems like there's some breakage in the latest packages, caused by the base packages installing files to paths that don't include the version, which means they attempt to overwrite each other. seems to be an issue just with the last two LTS releases:

linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/BSD-2-Clause exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/BSD-3-Clause exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/BSD-3-Clause-Clear exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/GCC-exception-2.0 exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/ISC exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/Linux-OpenIB exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/Linux-syscall-note exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/MIT exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/X11 exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-headers-bin: /usr/share/licenses/linux-lts-headers/Zlib exists in filesystem (owned by linux6.6.18-1-lts-headers-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/BSD-2-Clause exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/BSD-3-Clause exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/BSD-3-Clause-Clear exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/GCC-exception-2.0 exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/GPL-1.0 exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/ISC exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/Linux-OpenIB exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/Linux-syscall-note exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/MIT exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/X11 exists in filesystem (owned by linux6.6.18-1-lts-bin)
linux6.6.21-1-lts-bin: /usr/share/licenses/linux-lts/Zlib exists in filesystem (owned by linux6.6.18-1-lts-bin)
Errors occurred, no packages were upgraded.

@tessaracht good to hear, and thanks for the kind words! I'm glad the packages are useful.

and like, thanks so much for these packages. they're such a huge improvement over the way arch does kernels by default. who thought just breaking the running kernel on upgrade was a good idea?? XD

@chris: ahhh yeah! it was a change on my system that affected the makepkg config, I've sorted it out. no issue with the package at all, totally a local system change.

@tessaracht that is strange. I have .81 installed, so it did build for me. Have you tried ensuring it's doing a cleanbuild? Does running makepkg in a fresh git clone of this AUR repo work? If makepkg fails, it might be interesting as a post-mortem to see what files are in the pkg directory after failure - that's what zstd ought to be compressing. The fact that it is trying to compress a file called 0 is mysterious, but doesn't to me hint at what might be going wrong.

seeing some weird issues installing the latest packages with yay:

==> Checking for packaging issues...
==> Creating package "linux-lts-versioned-bin"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...

zstd: can't stat 0 : No such file or directory -- ignored 
==> ERROR: Failed to create package file.
 -> error making: linux-lts-versioned-bin (linux5.10.81-1-lts-bin linux-lts-versioned-bin linux5.10.81-1-lts-headers-bin linux-lts-versioned-headers-bin)

not really sure what this indicates, but yeah, can't upgrade to .81.

@G3ro, I've reverted the change, apologies for that. It indeed defeats the whole purpose.

For what it's worth, here are two unusual things about this PKGBUILD that pamac might choke on:

1. I don't bump the pkgrel when I make changes (which is rare - this latest change was the first in a long time) - the version does not increase until the next upstream kernel is released, this is in order to make this package match arch linux-lts kernel package versions exactly.

2. The sources array is dynamically determined based on whether the kernel packages are available from your own mirror, falling back to the arch linux archive if not.

The newest version: 5.10.79-1 wants to remove former installed kernel packages: 5.10.78 & 5.10.77 in my case.

I assume it is related to the latest commit: https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-lts-versioned-bin&id=ca5808cc839bd043e6f0d95b75f10f34480ed586

Update: I just reverted that commit and it works again as expected.

Note: I tried to install it via pamac and pacman, both show the described behavior.

Also: It seems that I can't install & upgrade the packages through pamac GUI anymore. It shows: "Could not generate information for package linux-lts-versioned-bin". I assume the error is on pamacs side, so I filed a bug report there as well.