Pinning kernel

If none of the more specific forums is the right place to ask
Post Reply
Message
Author
somePlebe
Posts: 4
Joined: 2021-07-25 20:49

Pinning kernel

#1 Post by somePlebe »

I have built and installed a custom kernel. I would like to prevent Debian from installing a new one whenever i update. If I pin the installed custom kernel will that work? Or should I pin the both the custom kernel and the Debian installed current kernel also?

CwF
Posts: 1187
Joined: 2018-06-20 15:16
Has thanked: 2 times
Been thanked: 6 times

Re: Pinning kernel

#2 Post by CwF »

Simply uninstall Linux-image (meta-package)

somePlebe
Posts: 4
Joined: 2021-07-25 20:49

Re: Pinning kernel

#3 Post by somePlebe »

CwF wrote: 2021-07-31 03:18 Simply uninstall Linux-image (meta-package)
Thank you.

User avatar
cds60601
Global Moderator
Global Moderator
Posts: 263
Joined: 2017-11-25 05:58
Location: Tampa, Florida
Has thanked: 22 times
Been thanked: 3 times

Re: Pinning kernel

#4 Post by cds60601 »

Also have a look at man apt-hold. From the man-page (man apt-hold)...
PREVENT CHANGES FOR A PACKAGE
hold
hold is used to mark a package as held back, which will prevent the package from being automatically installed, upgraded or removed.
Server: Debian Stable, Workstation: Debian Sid (dwm)
Laptop: Debian Sid (dwm), Pi-4: Stable (dwm)
----------------------------------------------------------------------------------
Don't Break Debian: https://wiki.debian.org/DontBreakDebian

User avatar
sunrat
Global Moderator
Global Moderator
Posts: 3750
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 3 times
Been thanked: 11 times

Re: Pinning kernel

#5 Post by sunrat »

cds60601 wrote: 2021-07-31 15:57 Also have a look at man apt-hold. From the man-page (man apt-hold)...
PREVENT CHANGES FOR A PACKAGE
hold
hold is used to mark a package as held back, which will prevent the package from being automatically installed, upgraded or removed.
That might work if one holds the metapackage linux-image-amd64 (or its equivalent for other arch). If only the actual kernel package is held, the metapackage will still cause a newer kernel to be installed when available. I would remove the metapackage as CwF suggested.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

User avatar
4D696B65
Site admin
Site admin
Posts: 2679
Joined: 2009-06-28 06:09
Been thanked: 17 times

Re: Pinning kernel

#6 Post by 4D696B65 »

How will you deal with security updates in the kernel. Will you keep building custom kernels every time?

User avatar
donald
Debian Developer, Site Admin
Debian Developer, Site Admin
Posts: 164
Joined: 2021-03-30 20:08
Has thanked: 21 times
Been thanked: 28 times

Re: Pinning kernel

#7 Post by donald »

4D696B65 wrote: 2021-08-01 00:25 How will you deal with security updates in the kernel. Will you keep building custom kernels every time?
I generally run a kernel ahead or jump to the most current:

uname -a
Linux localhoster 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux

This gives me, for my needs more control over my system, however it is not for everyone and one has to be mindful of security updates overall. So just pay attention to Debian Security: https://lists.debian.org/debian-security-announce/ (mail-list) but also any PPAs that you are using. It's a lot more work, but a good reward if you have the time or are working dev stuff.

somePlebe wrote: 2021-07-31 03:01 I have built and installed a custom kernel. I would like to prevent Debian from installing a new one whenever i update. If I pin the installed custom kernel will that work? Or should I pin the both the custom kernel and the Debian installed current kernel also?


Another method is to use /etc/apt/preferences or /etc/apt/preferences/anyname

I believe the syntax would be:

Package: linux-image-$whatever
Pin: release *
Pin-Priority: 1001 (Edited)


The manpage on pinning: https://manpages.debian.org/buster/apt/ ... .5.en.html

A working explanation with examples: https://www.pcsuggest.com/apt-pinning-i ... lectively/

I personally don't pin but use hold instead, IIRC I had/may still have a package on a server that is marked that will not allow the server to kernel update. This was an accident but I do remember it somewhat, maybe find a package that is tied to a particular kernel? My memory on this is foggy to be honest.

Linode used to advise holds on packages related to their in-house kernels which are newer but without all the new jazz: https://www.linode.com/community/questi ... ded-kernel
Last edited by donald on 2021-08-01 12:44, edited 1 time in total.
Reason: See sunrat's post immediately after this post for the correction.

User avatar
sunrat
Global Moderator
Global Moderator
Posts: 3750
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 3 times
Been thanked: 11 times

Re: Pinning kernel

#8 Post by sunrat »

donald wrote: 2021-08-01 11:51Another method is to use /etc/apt/preferences or /etc/apt/preferences/anyname

I believe the syntax would be:

Package: linux-image-$whatever
Pin: release *
Pin-Priority: -1
To pin a specific version of a package, should not the priority be the highest possible ie. 1001?
I run a Liquorix kernel and just removed the liquorix metapackage to prevent automatic updates. Occasionally a major version upgrade will break nvidia driver module build. Of course I check regularly to keep abreast of upgrades and usually install any newer minor versions.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

User avatar
donald
Debian Developer, Site Admin
Debian Developer, Site Admin
Posts: 164
Joined: 2021-03-30 20:08
Has thanked: 21 times
Been thanked: 28 times

Re: Pinning kernel

#9 Post by donald »

sunrat wrote: 2021-08-01 12:23
donald wrote: 2021-08-01 11:51Another method is to use /etc/apt/preferences or /etc/apt/preferences/anyname

I believe the syntax would be:

Package: linux-image-$whatever
Pin: release *
Pin-Priority: -1
To pin a specific version of a package, should not the priority be the highest possible ie. 1001?
I run a Liquorix kernel and just removed the liquorix metapackage to prevent automatic updates. Occasionally a major version upgrade will break nvidia driver module build. Of course I check regularly to keep abreast of upgrades and usually install any newer minor versions.
You are correct it would be pinned to the highest possible number rather than the lowest which would have the opposite effect, from the manpage:

•The specific form assigns a priority (a "Pin-Priority") to one or more specified packages with a specified version or version range. For example, the following record assigns a high priority to all versions of the perl package whose version number begins with "5.20". Multiple packages can be separated by spaces.

Package: perl
Pin: version 5.20*
Pin-Priority: 1001

I'll edit my post.

CwF
Posts: 1187
Joined: 2018-06-20 15:16
Has thanked: 2 times
Been thanked: 6 times

Re: Pinning kernel

#10 Post by CwF »

Another thread about firmware chicken/egg situations reminded me of this thread..
Without second guessing the motivation here, I gave the simplest solution. This thread will be noteworthy for pinning, but...
There are legit reasons for freezing a custom kernel, if not a whole system, if not a whole network. If the purpose is to reach forward or backward in hardware support then YOU are the maintainer now! If so, there are benefits in slimming down the support on things not needed (20-30MB kernel). The reality of security updates may not be relevant, they don't affect every use case. If this is an air gaped machine, they are entirely irrelevant outside of physical access possibilities.

Better than pinning, and more laborious is to simply control the repository instead of controlling the response to it. I did this for some years building the initial images in a vm, and doing the updates to that vm, then collect debs from the apt cache, and creating the index file using dpkg-dev, and physically carrying that on a device to the location - where that machine sees a simple upgrade with nothing held, no pinning, etc.

If this practice were more common maybe we wouldn't have to worry about pipelines and power grids being susceptible to ransomware...but then again they're using windows servers with iphone access probably, ya know secure stuff!

Post Reply