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
Pinning kernel
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?
- cds60601
- df -h | participant
- Posts: 724
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 133 times
- Been thanked: 64 times
Re: Pinning kernel
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
- sunrat
- Administrator
- Posts: 6476
- Joined: 2006-08-29 09:12
- Location: Melbourne, Australia
- Has thanked: 118 times
- Been thanked: 474 times
Re: Pinning kernel
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!
Those who have lost data
...and those who have not lost data YET ” Remember to BACKUP!
Re: Pinning kernel
How will you deal with security updates in the kernel. Will you keep building custom kernels every time?
- donald
- Debian Developer, Site Admin
- Posts: 1073
- Joined: 2021-03-30 20:08
- Has thanked: 188 times
- Been thanked: 243 times
Re: Pinning kernel
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.
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.
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
"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
- sunrat
- Administrator
- Posts: 6476
- Joined: 2006-08-29 09:12
- Location: Melbourne, Australia
- Has thanked: 118 times
- Been thanked: 474 times
Re: Pinning kernel
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!
Those who have lost data
...and those who have not lost data YET ” Remember to BACKUP!
- donald
- Debian Developer, Site Admin
- Posts: 1073
- Joined: 2021-03-30 20:08
- Has thanked: 188 times
- Been thanked: 243 times
Re: Pinning kernel
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:sunrat wrote: ↑2021-08-01 12:23To 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.
•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
"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
-
- Global Moderator
- Posts: 2681
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 196 times
Re: Pinning kernel
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!
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!