Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Pinning kernel

If none of the specific sub-forums seem right for your thread, ask here.
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
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 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
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 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.
Supercalifragilisticexpialidocious

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 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: 2696
Joined: 2009-06-28 06:09
Been thanked: 85 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: 1046
Joined: 2021-03-30 20:08
Has thanked: 186 times
Been thanked: 240 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.
Typo perfectionish.


"The advice given above is all good, and just because a new message has appeared it does not mean that a problem has arisen, just that a new gremlin hiding in the hardware has been exposed." - FreewheelinFrank

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 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: 1046
Joined: 2021-03-30 20:08
Has thanked: 186 times
Been thanked: 240 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.
Typo perfectionish.


"The advice given above is all good, and just because a new message has appeared it does not mean that a problem has arisen, just that a new gremlin hiding in the hardware has been exposed." - FreewheelinFrank

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 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