Siduction Forum
Siduction Forum => Software - Support => Topic started by: cliff6056 on 2021/03/26, 01:10:36
-
At some point in the New Year following a full-upgrade, my system ceased to autoremove the oldest kernel. It now wants to remove the running kernel, which I deny. Following a reboot into the newly installed kernel, nothing is to be removed.
My update procedure previous was apt update && apt full-upgrade && apt autoremove && rebootIn one of my backups I find the behavior I believe I used to have. This under apt kernel postinst.d apt-auto-removal
and is
#!/bin/sh
set -e
# Mark as not-for-autoremoval those kernel packages that are:
# - the currently booted version
# - the kernel version we've been called for
# - the latest kernel version (as determined by debian version number)
# - the second-latest kernel version
#
# In the common case this results in two kernels saved (booted into the
# second-latest kernel, we install the latest kernel in an upgrade), but
# can save up to four. Kernel refers here to a distinct release, which can
# potentially be installed in multiple flavours counting as one kernel.I do not find this in my current running system. Has the procedure changed? I did come across a thread under Upgrade Warnings that I thought was directly related to this, but the addition of the apt-config-siduction file which spawned the "80siduction" did not change things for me.
So if this is the expected behavior, I will remove the kernels manually.
Thoughts appreciated.
Cliff
-
Boot into the new kernel before running apt autoremove. Here it offers to keep the current latest kernel and the second latest, as expected.
That script you mentioned should be at /etc/kernel/postinst.d/apt-auto-removal
-
The recommended way to deal with kernels was always to run kernel-remover.
-
Is it possible to make autoremove leave the kernels alone?
I would like to keep my older versions like 5.8, 5.9, etc.
It does not help me when I find out on 5.11.6 that something does not
work since 5.10.
By now you have certainly remarked how attentive I am :-\.
Thanks!
gnasch
-
Thanks for replies.
sunrat - Thanks, however, when I upgrade and boot into the new kernel. and then run autoremove, it finds nothing to remove. And the script I mentioned was indeed found in etc/kernel/postinst.d/apt-auto-removal, however that is from a backup of last December. The current contents of that file is now #!/bin/sh
set -e
eval $(apt-config shell APT_CONF_D Dir::Etc::parts/d)
test -n "${APT_CONF_D}" || APT_CONF_D="/etc/apt/apt.conf.d"
config_file="${APT_CONF_D}/01autoremove-kernels"
generateconfig() {
cat <<EOF
// DO NOT EDIT! File autogenerated by $0
APT::LastInstalledKernel "$1";
EOF
}
generateconfig "$@" > "${config_file}.dpkg-new"
mv -f "${config_file}.dpkg-new" "$config_file"
chmod 444 "$config_file"Is this different from yours?
devil - thanks for help now and in the past, guess kernel-remover is my new friend and that's how I will be doing it.
-
Is it possible to make autoremove leave the kernels alone?
I would like to keep my older versions like 5.8, 5.9, etc.
It does not help me when I find out on 5.11.6 that something does not
work since 5.10.
By now you have certainly remarked how attentive I am :-\ .
Thanks!
gnasch
I don't know where it came from but autoremoving kernels is disabled here. You can have as many kernels of any versions as you like with a minimum of two. I would question why you are having problems with any particular kernel. I use only the siduction experimental kernels, now at 5.12.0-rc4, with almost no problems over the years. Yes, you should always use the kernel-remover.
-
I knew I could find it! /etc/apt/conf.d. (01autoremove)
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
};
VersionedKernelPackages
{
# kernels
"linux-.*";
"kfreebsd-.*";
"gnumach-.*";
# (out-of-tree) modules
".*-modules";
".*-kernel";
};
Never-MarkAuto-Sections
{
"metapackages";
"contrib/metapackages";
"non-free/metapackages";
"restricted/metapackages";
"universe/metapackages";
"multiverse/metapackages";
};
Move-Autobit-Sections
{
"oldlibs";
"contrib/oldlibs";
"non-free/oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
};
And next to it: (01autoremove-kernels)
Keep this one.
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::LastInstalledKernel "5.12.0-rc4-siduction-amd64";
-
Same scripts here but autoremove delete the old kernels here.
What must I change to prevent that apt-autoremove delete the kernels?
-
Happens here also with these scripts.
Same question.
Thanks and sorry for the bother ::)
gnasch
-
If siduction-scripts is installed, kernels should be prevented from removal.
-
It would still like to delete kernels:
root@Nh364Mz:~# apt install --reinstall siduction-scripts
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
libaom2 linux-headers-5.10.15-towo.1-siduction-amd64 linux-headers-5.10.20-towo.1-siduction-amd64
linux-image-5.10.15-towo.1-siduction-amd64 linux-image-5.10.20-towo.1-siduction-amd64
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 51 not upgraded.
Need to get 30.6 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://packages.siduction.org/extra unstable/main amd64 siduction-scripts all 2018.1.2 [30.6 kB]
Fetched 30.6 kB in 1s (27.8 kB/s)
(Reading database ... 341433 files and directories currently installed.)
Preparing to unpack .../siduction-scripts_2018.1.2_all.deb ...
Unpacking siduction-scripts (2018.1.2) over (2018.1.2) ...
Setting up siduction-scripts (2018.1.2) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for siduction-dynamic-dms (2016.01.31) ...
Scanning processes...
Scanning candidates...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
root@Nh364Mz:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
libaom2 linux-headers-5.10.15-towo.1-siduction-amd64 linux-headers-5.10.20-towo.1-siduction-amd64
linux-image-5.10.15-towo.1-siduction-amd64 linux-image-5.10.20-towo.1-siduction-amd64
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
linux-headers-5.11.11-1-siduction-amd64 linux-image-5.11.11-1-siduction-amd64
The following packages have been kept back:
firefox firefox-esr firefox-esr-l10n-de firefox-l10n-de firefox-l10n-en-gb firefox-l10n-fr firefox-l10n-pt-br
The following packages will be upgraded:
dnsmasq-base firmware-amd-graphics firmware-atheros firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax
firmware-iwlwifi firmware-libertas firmware-linux firmware-linux-nonfree firmware-misc-nonfree firmware-myricom
firmware-netxen firmware-qlogic firmware-realtek firmware-ti-connectivity libcpupower1 libcrypt-dev libcrypt1
libgnutls-openssl27 libgnutls30 libixml11 libkf5globalaccel-bin libkf5globalaccel-data libkf5globalaccel5
libkf5globalaccelprivate5 libldb2 libmediainfo0v5 libssh2-1 libssl-dev libssl1.1 libupnp17 libzen0v5 linux-cpupower
linux-headers-siduction-amd64 linux-image-siduction-amd64 linux-libc-dev netbase openssl python3-ldb python3-soupsieve teams
whois
44 upgraded, 2 newly installed, 0 to remove and 7 not upgraded.
Need to get 219 MB of archives.
After this operation, 294 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
-
Sorry, it's apt-conf-siduction.
-
yet still:
root@Nh364Mz:~# apt policy apt-conf-siduction
apt-conf-siduction:
Installed: 0.5.1+nmu1
Candidate: 0.5.1+nmu1
Version table:
*** 0.5.1+nmu1 500
500 http://packages.siduction.org/extra unstable/main amd64 Packages
100 /var/lib/dpkg/status
0.5.0 500
500 http://packages.siduction.org/fixes unstable/main amd64 Packages
root@Nh364Mz:~# apt install --reinstall apt-conf-siduction
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
libaom2 linux-headers-5.10.15-towo.1-siduction-amd64 linux-headers-5.10.20-towo.1-siduction-amd64
linux-image-5.10.15-towo.1-siduction-amd64 linux-image-5.10.20-towo.1-siduction-amd64
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 51 not upgraded.
Need to get 2’264 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://packages.siduction.org/extra unstable/main amd64 apt-conf-siduction all 0.5.1+nmu1 [2’264 B]
Fetched 2’264 B in 0s (29.4 kB/s)
(Reading database ... 341433 files and directories currently installed.)
Preparing to unpack .../apt-conf-siduction_0.5.1+nmu1_all.deb ...
Unpacking apt-conf-siduction (0.5.1+nmu1) over (0.5.1+nmu1) ...
Setting up apt-conf-siduction (0.5.1+nmu1) ...
Processing triggers for siduction-dynamic-dms (2016.01.31) ...
Scanning processes...
Scanning candidates...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
root@Nh364Mz:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
libaom2 linux-headers-5.10.15-towo.1-siduction-amd64 linux-headers-5.10.20-towo.1-siduction-amd64
linux-image-5.10.15-towo.1-siduction-amd64 linux-image-5.10.20-towo.1-siduction-amd64
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
linux-headers-5.11.11-1-siduction-amd64 linux-image-5.11.11-1-siduction-amd64
The following packages have been kept back:
firefox firefox-esr firefox-esr-l10n-de firefox-l10n-de firefox-l10n-en-gb firefox-l10n-fr firefox-l10n-pt-br
The following packages will be upgraded:
dnsmasq-base firmware-amd-graphics firmware-atheros firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax
firmware-iwlwifi firmware-libertas firmware-linux firmware-linux-nonfree firmware-misc-nonfree firmware-myricom
firmware-netxen firmware-qlogic firmware-realtek firmware-ti-connectivity libcpupower1 libcrypt-dev libcrypt1
libgnutls-openssl27 libgnutls30 libixml11 libkf5globalaccel-bin libkf5globalaccel-data libkf5globalaccel5
libkf5globalaccelprivate5 libldb2 libmediainfo0v5 libssh2-1 libssl-dev libssl1.1 libupnp17 libzen0v5 linux-cpupower
linux-headers-siduction-amd64 linux-image-siduction-amd64 linux-libc-dev netbase openssl python3-ldb python3-soupsieve teams
whois
44 upgraded, 2 newly installed, 0 to remove and 7 not upgraded.
Need to get 219 MB of archives.
After this operation, 294 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
-
Mh, maybe mark them as manual installed
sudo apt-mark manual '^linux-[h-i]'
But then you have to mark every new kernel as manual installed
And if this is the right way to do, i don't know!?
EDIT
I tested a bit and added that line above to /etc/apt/apt.sonf.d/01autoremove
---snip--
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
"^linux-[h-i]";
};
VersionedKernelPackages
---snap---
so it works for me™, i don't have to mark new kernel as installed manual.
-
Yes - this works ;D
Problem seems to be inconsistent naming conventions.
thanks @hendrikL
-
What i don't understand is, why is there a need to have more than 3 kernels installed.
The better way is to mark the kernel you want not to be removed as manual installed and the problem should be solved.
My 2c
-
The answer is that on a lenovo s540 I had to use an old kernel for several month,
because the next higher x in 5.x.zz version would not work. Had I left the updates
do what they wanted, my daughter could not have finished the work for the final year
of school.
Really practical reasons only.
Thanks!
gnasch
-
That is okay, but if you mark that specific kernel as manual installed "apt-mark manual <foo>" .
Then you can use autopurge/autoremove without that that specific kernel <foo> gets removed but all other that are not needed, and you have a clean system.
-
Yeah - but the point is:
By the time I find out that something is wrong,
the automaton has already removed the old kernel.
I like to be in charge of my things, so when it breaks, I
know the culprit! I can almost cope with my own stupidity,
don't care about the stupidity of automatons.
That's why I am not using Win$ by the way. I have to
care about the mess that M$ is making out of printing
at my customers atm. Blerg.
Best,
ch
-
I tested a bit and added that line above to /etc/apt/apt.sonf.d/01autoremove
---snip--
APT
{
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
"^linux-[h-i]";
};
VersionedKernelPackages
---snap---
so it works for me™, i don't have to mark new kernel as installed manual.
I am by no means an expert when it comes to regex but I believe that the reason for the original config not matching the kernels is that those strings do not match the dots "." in the kernel package names and maybe some of the "-" too.
So looking at a current kernel
linux-image-5.11.13-2-siduction-amd64
I imagine a string like
"^linux-image-[a-z0-9\.]*-[a-z0-9\-]*$"
to actually match this.
That said I am not entirely sure if apt accepts this kind of escaping special characters.