Products > Embedded Computing

For how long can be held back a Linux kernel, yet upgrade to a new distro?

(1/3) > >>

RoGeorge:
The kernel must stay at v5.x, anything v6 does not match some specific driver I need.  For now, the distro is Debian 11 Bullseye, and that is a little older.  For example, the latest Python from Bullseye repo is 3.9, and some scripts require 3.10, etc. 

To avoid manually installing from sources each time, would be nice to just migrate to a newer distro that has new enough packages, for example by adding the new Debian 12 Bookworm into /etc/apt/sources.list.  For now, the must have kernel v5 and its corresponding linux-libc-dev are manually marked to hold back, from apt.  This is for an offline machine, so no security concerns by freezing the kernel version.

The question is, how good is the separation between the rest of a Linux distro and the kernel version?  For how long an old kernel can remain unchanged, without runtime conflicts with the rest of a distro?

RoGeorge:
Oh well, did the mistake to try to build Python 12.3 from sources (on a Raspberri Pi 1B from 10 years ago, ARMv6 32-bit, single core 700MHz, 256MB RAM, Debian11 and SD card).

Already lost the count of how many hours have past since the build was started.  Proc is always 100%, and once in a while the screen scrolls up some text.  ;D

ejeffrey:

--- Quote from: RoGeorge on April 15, 2024, 07:52:47 am ---The kernel must stay at v5.x, anything v6 does not match some specific driver I need.  For now, the distro is Debian 11 Bullseye, and that is a little older.  For example, the latest Python from Bullseye repo is 3.9, and some scripts require 3.10, etc. 

--- End quote ---

In theory, start with a distribution version that ships with a 5.x kernel and pin the version of the kernel.  Ideally, anything that requires 6.X kernels will be prevented from updating and you should be fine.

For python, if you are requiring specific python versions, I consider moving away from using the distribution release to installing your own and using virtual environments.



--- Quote ---The question is, how good is the separation between the rest of a Linux distro and the kernel version?  For how long an old kernel can remain unchanged, without runtime conflicts with the rest of a distro?

--- End quote ---

It's actually pretty well separated.  The linux kernel implements very strong backwards compatibility for userspace, and the utilities that directly manipulate the kernel data (like iptables) generally have pretty good kernel version support.  If you don't actually need features of the newer kernel it should work fine, but it just gets hard to manage dependencies.  What you can do if you want is to run a stripped down OS of an older version, then run a newer OS in a container (docker, podman, etc) and use that for everything.  Then if you run into a specific tool where the newer container version is incompatible with the old kernel you can run it in the host OS.

magic:
I can boot a recent Arch installation with Linux v5.10-LTS.

That's with sys****d, which is IMO the part which would be most likely to depend on some new kernel API.

RoGeorge:
That's good news, because compiling is unusable slow.  The Python install from sources that I've started this morning, took 10+ hours to compile but it works.  Except, now I have no Raspberry Pi specific Python modules, e.g. 'gpiozero', and would need to compile those, too.  ;D

I'll just migrate the old Debian 11 Bullseye to the current Debian 12 Bookworm, then sudo apt full-upgrade with the kernel pinned down to the older v5.x.  Even if the migration breaks something, would still be faster to reinstall all the OS than to compile yet another package like Python.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod