Using Linux LTS on Arch Linux

fatih.erol@haslerrail.com · 2020-11-24 16:24:29

If we base our system on a specific release of Arch Linux, such as 01.08.2020, and do not perform further updates, will all the software function if we start using an LTS release (5.4.78) of the kernel, which is older than current Linux version (5.7.11) in the release?

Or, more specifically, is the gcc toolchain (and C library) on that release prepared against the latest version of Linux on that release, or is it built against an older version for compatibility? Are all the packages re-built with this toolchain for a release?

When we switch to a Linux LTS release, will some software fail, since they are built against a C library which was prepared for a newer kernel version?

Scimmia · 2020-11-24 16:28:08

There are no releases of Arch, your entire premise is bad.

If you don't want to update the system, Arch is the wrong distro to choose. The longer you go, the more difficult updates get.

fatih.erol@haslerrail.com · 2020-11-24 16:40:18

let's say 'snapshots' then, as listed in this link with title 'Arch Linux - Releases': https://www.archlinux.org/releng/releases/

Trilby · 2020-11-24 16:40:39

For a vast majority of software, the kernel version is irrelevant. The current glibc does not depend on any specific version of the kernel (presumably, if you go back far enough to an ancient kernel there'd be issues, but any LTS or recent release would be fine).

There are a few exceptions of packages that are built for a specific kernel, but these will have a dependency listed for the 'linux' kernel package and will almost always have a -lts and -dkms variants available. If you need any of these packages, and have some reason to use an older and not lts kernel, you'd need the dkms variant of these packages. Nvidia is a good example of such a package.

But in any "snapshot" all the software in the repos at that time will work with linux or linux-lts (notwithstanding the above excpetions). There is absolutely nothing about it being an older snapshot that makes it different from a currently updated system, except that the old packages will no longer be in the repos / mirrors (but only in the ALA).

Of course, this sounds very much like an X-Y question. Why have you not updated in nearly a year? If you do not intend to update, don't use arch.

Last edited by Trilby (2020-11-24 17:29:12)

fatih.erol@haslerrail.com · 2020-11-24 16:43:08

well, it is an embedded linux prepared on a frozen snapshot of arch linux.

Trilby · 2020-11-24 16:45:35

What does that word salad actually mean? If it is a frozen snapshot of one of the monthly isos, your question is not relevant as the kernel included in the iso is the kernel included in the iso. If you can install new / other packages (like an LTS) then you can upgrade.

Last edited by Trilby (2020-11-24 16:47:15)

Scimmia · 2020-11-24 16:45:38

the releases or snapshots listed on that page are just the ISO. There are no packages on the ISO, it always downloads the latest from the Internet during installation.

fatih.erol@haslerrail.com · 2020-11-24 16:46:10

i believe, glibc does depend on kernel headers.

Trilby · 2020-11-24 16:48:53

fatih.erol@haslerrail.com wrote:

i believe, glibc does depend on kernel headers.

You "beleive"? You know you can easily check. And it doesn't. It does have a versioned dependency on linux-api-headers but the minimum version requirement is far lower than anything relevant to this discussion.

Stop making stuff up and tell us what you are actually trying to do.

fatih.erol@haslerrail.com · 2020-11-24 16:51:17

well, i downloaded an iso release to prepare a baseline image, and i point pacman mirrorlist to https://archive.archlinux.org/repos/2020/08/01/... so it downloads the versions of packages available on that date.
now, i want to build a linux-rt-lts from AUR, and use it instead. will this break some software?

fatih.erol@haslerrail.com · 2020-11-24 16:53:07

* pacman -Qi glibc
Name : glibc
Version : 2.31-5
Description : GNU C Library
Architecture : x86_64
URL : https://www.gnu.org/software/libc
Licenses : GPL LGPL
Groups : None
Provides : None
Depends On : linux-api-headers>=4.10 tzdata filesystem

* https://www.archlinux.org/packages/core/x86_64/glibc/

Dependencies:
linux-api-headers>=4.10
...

* https://github.com/archlinux/svntogit-p … k/PKGBUILD:

# toolchain build order: linux-api-headers->glibc->binutils->gcc->binutils->glibc

Last edited by fatih.erol@haslerrail.com (2020-11-24 16:54:57)

Trilby · 2020-11-24 16:55:27

Thank you - at least this is now a real question. But ...

fatih.erol@haslerrail.com wrote:

i point pacman mirrorlist to https://archive.archlinux.org/repos/2020/08/01/... so it downloads the versions of packages available on that date.

WHY? Don't do that.

faith.erol@haslerrail.com wrote:

now, i want to build a linux-rt-lts from AUR, and use it instead. will this break some software?

No. The only exception being those already noted that explicitly depend on the 'linux' package, and those should have dkms variants that you can switch to.

EDIT:
As for your last post, we know what pacman output looks like. What's your point? That only shows the linux-api-headers that I noted. And the minimum version required is sufficiently old to not even be in the ALA archives anymore.

Last edited by Trilby (2020-11-24 16:58:09)

fatih.erol@haslerrail.com · 2020-11-24 17:09:19

thank you, i am glad i am sounding clearer now

so, shall i assume that there is no daily build for all the available packages while a repo archive is being generated: https://archive.archlinux.org/repos?
similarly, when the iso releases are being prepared, there is no re-generation of gcc toolchain with the latest kernel headers, and there is no re-generation of packages using a re-generated toolchain, or is there?
can one make a statement about the toolchain on the system on which a package is generated before uploading to the repository?

fatih.erol@haslerrail.com · 2020-11-24 17:11:28

Trilby wrote:

EDIT:
As for your last post, we know what pacman output looks like. What's your point? That only shows the linux-api-headers that I noted. And the minimum version required is sufficiently old to not even be in the ALA archives anymore.

yes, the whole post was about glibc - linux-headers dependency.

my point is that it is the 'MINIMUM' version, which might mean the toolchain may be prepared with linux 5.6 headers. in this case, it can be a problem to use an existing binary while running on linux 5.4 kernel.

Last edited by fatih.erol@haslerrail.com (2020-11-24 17:27:03)

Trilby · 2020-11-24 17:22:43

fatih.erol@haslerrail.com wrote:

shall i assume that there is no daily build for all the available packages while a repo archive is being generated: https://archive.archlinux.org/repos?

I'm getting the impression that you shall assume what you wish regardless of the fact. But no, there is no daily rebuild of all packages. Again this is easily verified: pacman shows the build date of packages!

faith.erol@haslerrail.com wrote:

similarly, when the iso releases are being prepared, there is no re-generation of gcc toolchain with the latest kernel headers, and there is no re-generation of packages using a re-generated toolchain, or is there?

There is not.

faith.erol@haslerrail.com wrote:

can one make a statement about the toolchain on the system on which a package is generated before uploading to the repository?

Packages are / should be built in a clean chroot with nothing more than a base install and the depdenencies listed in the PKGBUILD.

fatih.erol@haslerrail.com wrote:

yes, the whole post was about glibc - linux-headers dependency.

AGAIN, glibc does not depdend on linux-headers.

fatih.erol@haslerrail.com · 2020-11-24 17:46:19

possibly, we are somehow using 'depend' in different meanings (https://wiki.gentoo.org/wiki/Linux-headers): Packages like sys-libs/glibc depend on the kernel headers.

the point is that a binary will have a problem, if it requires symbols from glibc, that requires a newer version of the kernel than the running instance.

anyways. thanks to all for your time and answers.

Trilby · 2020-11-24 17:49:31

fatih.erol@haslerrail.com wrote:

possibly, we are somehow using 'depend' in different meanings

Apparently we are. I'm talking about arch linux - you're posting links about gentoo.

If you want help with gentoo, ask on their forums.

Last edited by Trilby (2020-11-24 17:49:47)

fatih.erol@haslerrail.com · 2020-11-24 18:05:44

well, the link is just from a search to confirm what i posted above:
# toolchain build order: linux-api-headers->glibc->binutils->gcc->binutils->glibc

it should be clear from all this conversation that i am not asking gentoo related help.

Trilby · 2020-11-24 18:08:11

Nothing is clear from this conversation. The goalposts keep moving, and you seem to be providing random links and command output to try to be contrarian rather than wanting to accept the facts.

But hey, do whatever you like. Use the arch archive as your mirror to maintain an outdated and insecure system, and do not use an LTS kernel because you think glibc will break, and do not listen to any of the factual information you are provided with here.

But if you aren't going to accept answers, don't ask the questions.

zpg443 · 2020-11-25 00:00:12

Debian awaits if you desire infrequent updates and value stability above new features.

eschwartz · 2020-11-25 03:39:46

fatih.erol@haslerrail.com wrote:

possibly, we are somehow using 'depend' in different meanings (https://wiki.gentoo.org/wiki/Linux-headers): Packages like sys-libs/glibc depend on the kernel headers.
the point is that a binary will have a problem, if it requires symbols from glibc, that requires a newer version of the kernel than the running instance.
anyways. thanks to all for your time and answers.

No, no, no, and no.

Don't use gentoo links. Gentoo's "linux-headers" package is not the same as Arch's "linux-headers".

The GNU libc requires, to function as a libc for compiling software with, a set of headers taken from the Linux kernel software project, and sanitized for userspace. They are installed to /usr/include. On Arch, this package is called "linux-api-headers".

The kernel build infrastructure requires, to build out of tree kernel modules such as broadcom-wl, nvidia, etc. a set of headers tied to the kernel being built for. They are installed to /usr/lib/modules/5.9.10-arch1-1/build/include/ and only the rare people building kernel modules need it. On Arch, this package is called "linux-headers" for the "linux" kernel, but "linux-lts-headers" for the linux-lts kenel.

linux-api-headers is NOT the headers for a kernel named "linux-api".

No one cares if Gentoo has a "linux-headers" package that does the same as Arch's "linux-api-headers" package.

eschwartz · 2020-11-25 03:48:25

All of your questions about the toolchain build order can be answered very simply:

If you're installing from the https://archive.archlinux.org/ repos, your system is consistent and nothing else matters. Your system might be DEPRESSINGLY OLD, but it is CONSISTENT.

End of story. Stop asking questions.

Do not pass go. Do not compile your own gcc or glibc.

...

Feel free to compile your own kernel. linux-rt-lts will compile and run just fine *regardless* of your glibc, gcc, or linux-api-headers version, as long as your kernel is at least 3.2

Arch Linux

#1 2020-11-24 16:24:29

Using Linux LTS on Arch Linux

#2 2020-11-24 16:28:08

Re: Using Linux LTS on Arch Linux

#3 2020-11-24 16:40:18

Re: Using Linux LTS on Arch Linux

#4 2020-11-24 16:40:39

Re: Using Linux LTS on Arch Linux

#5 2020-11-24 16:43:08

Re: Using Linux LTS on Arch Linux

#6 2020-11-24 16:45:35

Re: Using Linux LTS on Arch Linux

#7 2020-11-24 16:45:38

Re: Using Linux LTS on Arch Linux

#8 2020-11-24 16:46:10

Re: Using Linux LTS on Arch Linux

#9 2020-11-24 16:48:53

Re: Using Linux LTS on Arch Linux

#10 2020-11-24 16:51:17

Re: Using Linux LTS on Arch Linux

#11 2020-11-24 16:53:07

Re: Using Linux LTS on Arch Linux

#12 2020-11-24 16:55:27

Re: Using Linux LTS on Arch Linux

#13 2020-11-24 17:09:19

Re: Using Linux LTS on Arch Linux

#14 2020-11-24 17:11:28

Re: Using Linux LTS on Arch Linux

#15 2020-11-24 17:22:43

Re: Using Linux LTS on Arch Linux

#16 2020-11-24 17:46:19

Re: Using Linux LTS on Arch Linux

#17 2020-11-24 17:49:31

Re: Using Linux LTS on Arch Linux

#18 2020-11-24 18:05:44

Re: Using Linux LTS on Arch Linux

#19 2020-11-24 18:08:11

Re: Using Linux LTS on Arch Linux

#20 2020-11-25 00:00:12

Re: Using Linux LTS on Arch Linux

#21 2020-11-25 03:39:46

Re: Using Linux LTS on Arch Linux

#22 2020-11-25 03:48:25

Re: Using Linux LTS on Arch Linux

Board footer