Confusion about linux-lts being updated from 5.4.99 to 5.10.16

jasong · 2021-02-19 01:29:19

Hello, this is my first post so please direct me to any rules I might be breaking.

(I have searched for duplicate posts, and haven't found any on this topic)
(I have also read the bug reporting page and am aware that the upstream URL for linux-lts is not associated with arch, but kernel.org directly)

(I am probably completely misunderstanding the purpose for this forum, so this post might be misplaced/misdirected)

I am using the LTS kernel (via linux-lts package), and within the last few days it was updated from 5.4.99 all the way to 5.10.17.
This breaks another package I use that requires kernel 5.7 or earlier, and I don't understand why this change was made.

 yay -Ss linux | grep core/linux

...
core/linux-lts 5.10.17-1 (74.3 MiB 79.1 MiB) (Installed)
...
core/linux 5.10.16.arch1-1 (73.9 MiB 78.6 MiB)

I assume this change was intentional, but I don't understand why.
kernel.org still lists LTS as 5.4.99

Surely this has been breaking other LTS packages all over the place?
Is the linux-lts package completely pointless now?
Could this be a result of some change to the way LTS is being managed from the kernel developers?

I assume that I will have to install the previous version with the correct kernel from my package cache, but this still seems silly that the purpose of the linux-lts package (To provide the LTS kernel from kernel.org) has been ignored.
(Please correct my assumption here, but I believe this is how others would react to this change as well.)

Sorry for venting, just a bit annoyed at the moment.

Thank you for reading.

jonathon · 2021-02-19 01:41:30

jasong wrote:

5.10.17. This breaks another package I use that requires kernel 5.7 or earlier

That sounds like a bug in the other package, but if its unavoidable the older LTS kernels are available in the AUR.

jasong wrote:

and I don't understand why this change was made.

The latest LTS kernel is now 5.10, so Arch has updated the `linux-lts` package to kernel 5.10.

jasong wrote:

Surely this has been breaking other LTS packages all over the place?

It doesn't break anything in the Arch repositories - all packages related to the LTS kernel have been updated.

jasong wrote:

Is the linux-lts package completely pointless now?

No; the standard `linux` package will be updated to the latest kernel release (5.11) soon. The current situation is a bit odd as both `linux` and `linux-lts` packages are the same kernel version, but it won't stay that way for long.

loqs · 2021-02-19 01:53:42

What is the other package? Why can it not be made compatible with newer kernels?

jasong · 2021-02-19 02:49:14

jonathon wrote:

jasong wrote:
5.10.17. This breaks another package I use that requires kernel 5.7 or earlier
That sounds like a bug in the other package, but if its unavoidable the older LTS kernels are available in the AUR.
jasong wrote:
and I don't understand why this change was made.
The latest LTS kernel is now 5.10, so Arch has updated the `linux-lts` package to kernel 5.10.
jasong wrote:
Surely this has been breaking other LTS packages all over the place?
It doesn't break anything in the Arch repositories - all packages related to the LTS kernel have been updated.
jasong wrote:
Is the linux-lts package completely pointless now?
No; the standard `linux` package will be updated to the latest kernel release (5.11) soon. The current situation is a bit odd as both `linux` and `linux-lts` packages are the same kernel version, but it won't stay that way for long.

Thanks for the detailed response.

I assumed that on https://www.kernel.org/, the "Longterm" branch was mirrored in linux-lts, and not the "Stable" branch as you have explained.

I think I've earnt my place in the Newbie Corner lol.

I'll stick to my cached 5.4.98-1 kernel instead of the AUR alternatives.

jasong · 2021-02-19 03:01:15

loqs wrote:

What is the other package? Why can it not be made compatible with newer kernels?

The broken package was the veeamsnap module from the AUR, required for veeam.

Veeam responded here saying that 5.8 removed a key feature they needed, so I just used the LTS kernel for simplicity.

I haven't explored many other backup options, so of course I'm open to suggestions.

fukawi2 · 2021-02-19 03:06:29

The -lts kernel is tracking the upstream LTS. It's not like a RHEL/CentOS kernel that is fixed for the life of a release. Arch has to update it eventually because we're rolling release. It will get less updates than the regular kernel though - it's a relative -lts.

If you need a consistent major kernel version, you can add it to IgnorePkg in pacman (which is just "kicking the can down the road"), or use something other than Arch.

jasong · 2021-02-19 03:31:50

fukawi2 wrote:

The -lts kernel is tracking the upstream LTS. It's not like a RHEL/CentOS kernel that is fixed for the life of a release. Arch has to update it eventually because we're rolling release. It will get less updates than the regular kernel though - it's a relative -lts.
If you need a consistent major kernel version, you can add it to IgnorePkg in pacman (which is just "kicking the can down the road"), or use something other than Arch.

Thanks, I just blacklisted the LTS kernel + headers and set up the veeamsnap module to load at boot.
All back up and running now.

Is there a major risk in blacklisting the kernel from updates?

fukawi2 · 2021-02-19 03:44:48

Well as I said, you're just kicking the can down the road... Evenually the -lts kernel is going to move on, and all the other packages on your system that depend on it will either break, or you'll have to hold them back too... So your system will diverge further and further from the current package set, and updating it will become a bigger and bigger task that may eventually become impossible.

headkase · 2021-02-19 03:53:00

jasong wrote:

Is there a major risk in blacklisting the kernel from updates?

Eventually some other package will assume the kernel is at least a certain version and it isn't. So your system, at some unknown future time, will break.

You may want to consider a Linux distribution that isnt' a rolling-release. Something that can be assumed to stay pretty much the same for a long time.

Since Arch is a rolling-release and is constantly upgraded: if you ignore any package then your system is in a partial-upgrade state and is therefore unsupported officially.

The reason there is no support for partial-upgrades is that what they do is unknown. You can spend hours tracking something down and all you really needed to do was make sure you were synchronized.

Another option is to install everything you will need and then never upgrade. As long as nothing changes and it all works yay. Of course those updates bring in security fixes so such a machine should not be connected to the internet.

With the last option, your chances of updating it later just become simpler to reinstall with time.

The best thing to do is as said look into an older AUR release of the lts kernel. At least in those things that can be fixed are fixed.

jasong · 2021-02-19 04:00:50

I'm 100% confident that I will continue using Arch, it is by far my favourite distro in terms of freedom, not to mention the flexibility & convenience of AUR packages.

My sole issue is with the veeamsnap package, which itself is not supported by Veeam, so I will continue looking for alternatives.

I'm aware of the responsibilities of rolling-release distros and have been using Arch for a while, but I also treat it as a learning exercise when it breaks.
I should also note that I am not relying on this machine for work/study, and if I were then I would take this situation much more seriously.

I'll try out some reputable AUR kernels, maybe even compile it myself (Though my 2GHz Celeron won't be happy)

Please note that I am not considering the blacklist a permanent solution, it's really just a stop-gap until I found a better solution for my backups.

Thanks for all your help and advice.

Last edited by jasong (2021-02-19 04:07:12)

loqs · 2021-02-19 04:53:42

diff for PKGBUILD for linux-lts 5.10.17 add two patches needed for veeamsnap

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index bb5c1f2..946ae01 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -19,6 +19,8 @@ source=(
   0001-ZEN-Add-sysctl-and-CONFIG-to-disallow-unprivileged-C.patch
 #  0002-virt-vbox-Add-support-for-the-new-VBG_IOCTL_ACQUIRE_.patch
 #  sphinx-workaround.patch
+  https://raw.githubusercontent.com/veeam/veeamsnap/experimental/blk_interposer/patch_for_v5.10/0001-blk_interposer-Block-Layer-Interposer.patch
+  https://raw.githubusercontent.com/veeam/veeamsnap/experimental/blk_interposer/patch_for_v5.10/0003-block-blk_interposer-change-attach-detach-logic.patch
 )
 validpgpkeys=(
   'ABAF11C65A2970B130ABE3C479BE3E4300411886'  # Linus Torvalds
@@ -28,7 +30,9 @@ validpgpkeys=(
 sha256sums=('e84e623ce8bb2446ec026b62eafa3b18480aa6fb6ae9c86cd8f18651324d4814'
             'SKIP'
             '14d52a4f598bdbf752546c4bab4dd096173db1f958df7dde97d17bb347b7073f'
-            '757e6de2a76284cd86f443d8a9830e775291ba01d9d339cff9b9b3e4b205b7b3')
+            '757e6de2a76284cd86f443d8a9830e775291ba01d9d339cff9b9b3e4b205b7b3'
+            '58b70e98f62cc65073709df37c6b3f12008b2c3a97c59c71e68e6c742fbef414'
+            'bea80ed3661f9215491fff1744cc39fe31def1de701b197bbc107e5258c6a356')
 
 export KBUILD_BUILD_HOST=archlinux
 export KBUILD_BUILD_USER=$pkgbase

diff for veeamsnap PKGBUILD changed to use experimental git branch supporting 5.10

diff --git a/PKGBUILD b/PKGBUILD
index ec38f8f..219512d 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,29 +1,24 @@
 # Maintainer: dekart811
 
 _pkgbase=veeamsnap
-pkgname=veeamsnap
+pkgname=veeamsnap-git
 pkgver=4.0.1.2365
 pkgrel=1
 pkgdesc="Veeam Agent for Linux kernel modules (DKMS)"
 arch=('i686' 'x86_64')
 url="http://repository.veeam.com/backup/linux/agent"
-license=('GPLv2')
-depends=('dkms' 'rpmextract')
+license=('GPL2')
 conflicts=("${_pkgbase}")
-install=${pkgname}.install
-source=("${url}/rpm/el/7/x86_64/veeamsnap-${pkgver}-1.noarch.rpm"
+depends=('dkms')
+makedepends=('git')
+source=("git+https://github.com/veeam/veeamsnap.git#branch=experimental"
         'dkms.conf')
-sha256sums=('439fa156a9166125b43d4a4395ae720571a43d95ea6987dc96f8b70f618ad1c5'
+sha256sums=('SKIP'
             '7d2a83f28b7c41797fadf06f29ab124ae63d662f2dba4e81e1eb4d1ef15bee7c')
 
-build() {
-  msg "build..."
-  rpmextract.sh veeamsnap-${pkgver}-1.noarch.rpm
-}
 
 package() {
   # Install
-  msg2 "pkgdir: "${pkgdir}
   # Copy dkms.conf
   install -Dm644 dkms.conf "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
 
@@ -33,5 +28,5 @@ package() {
       -i "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
 
   # Copy sources (including Makefile)
-  cp -r ${srcdir}/usr/src/${_pkgbase}-${pkgver}/* "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/
+  cp -r ${_pkgbase}/source/* "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/
 }

Using the above produced veeamsnap.ko.xz no further testing carried out.

Last edited by loqs (2021-02-19 04:54:13)

speedyx · 2021-02-19 04:59:05

I am doing the same, ignoring in pacman.conf both linux, linux-lts and their headers, so to control the version of the kernel I install. That procedure only ignore those packages from a pacman -Syu.

I have chosen to do that because some drivers hadn't worked well with the early point releases of the 5.10 kernel.

Monitoring constantly the kernel changelog, I decide if it is a safe upgrade for the things that interest me.

So I install explicitly the kernel and the headers when I have the time to verify that all is working, and sometimes downgrade if I need it.

It is not a recommended procedure or a permanent choice, only my safe way to upgrade. I'm doing the same with the gnome group, waiting for the next big upgrade.

Last edited by speedyx (2021-02-19 05:10:14)

Arch Linux

#1 2021-02-19 01:29:19

Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#2 2021-02-19 01:41:30

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#3 2021-02-19 01:53:42

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#4 2021-02-19 02:49:14

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#5 2021-02-19 03:01:15

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#6 2021-02-19 03:06:29

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#7 2021-02-19 03:31:50

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#8 2021-02-19 03:44:48

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#9 2021-02-19 03:53:00

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#10 2021-02-19 04:00:50

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#11 2021-02-19 04:53:42

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

#12 2021-02-19 04:59:05

Re: Confusion about linux-lts being updated from 5.4.99 to 5.10.16

Board footer