Siduction Forum

Siduction Forum => Software - Support => Software Support (EN) => Topic started by: cliff6056 on 2021/03/26, 01:10:36

Title: Kernel and autoremove
Post 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
Code: [Select]
apt update && apt full-upgrade && apt autoremove && rebootIn one of my backups I find the behavior I believe I used to have.  This under
Code: [Select]
apt kernel postinst.d apt-auto-removal
and is

Code: [Select]
#!/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


Title: Re: Kernel and autoremove
Post by: sunrat on 2021/03/26, 12:12:37
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
Title: Re: Kernel and autoremove
Post by: devil on 2021/03/26, 13:11:42
The recommended way to deal with kernels was always to run kernel-remover.
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/03/26, 13:36:33
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
Title: Re: Kernel and autoremove
Post by: cliff6056 on 2021/03/26, 15:19:31
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
Code: [Select]
#!/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. 


Title: Re: Kernel and autoremove
Post by: sedonix on 2021/03/26, 21:19:05
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.
Title: Re: Kernel and autoremove
Post by: sedonix on 2021/03/27, 00:03:56
I knew I could find it! /etc/apt/conf.d. (01autoremove)

Code: [Select]
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.

Code: [Select]
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::LastInstalledKernel "5.12.0-rc4-siduction-amd64";
Title: Re: Kernel and autoremove
Post by: harley-peter on 2021/04/01, 10:09:54
Same scripts here but autoremove delete the old kernels here.

What must I change to prevent that apt-autoremove delete the kernels?
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/01, 18:28:13
Happens here also with these scripts.
Same question.
Thanks and sorry for the bother ::)
gnasch
Title: Re: Kernel and autoremove
Post by: towo on 2021/04/01, 18:41:53
If siduction-scripts is installed, kernels should be prevented from removal.
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/01, 18:48:39
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.
Title: Re: Kernel and autoremove
Post by: towo on 2021/04/01, 19:00:12
Sorry, it's apt-conf-siduction.
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/01, 19:04:41
yet still:

Code: [Select]
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.
Title: Re: Kernel and autoremove
Post by: hendrikL on 2021/04/01, 23:11:57
Mh, maybe mark them as manual installed

Code: [Select]
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

Code: [Select]
---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.
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/02, 18:51:52
Yes - this works  ;D
Problem seems to be inconsistent naming conventions.
thanks @hendrikL
Title: Re: Kernel and autoremove
Post by: hendrikL on 2021/04/03, 07:32:10
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
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/03, 13:33:03
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
Title: Re: Kernel and autoremove
Post by: hendrikL on 2021/04/03, 15:15:09
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.
Title: Re: Kernel and autoremove
Post by: gnasch on 2021/04/03, 15:24:49
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
Title: Re: Kernel and autoremove
Post by: Mister00X on 2021/04/12, 19:20:40
I tested a bit and added that line above to /etc/apt/apt.sonf.d/01autoremove

Code: [Select]
---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
Code: [Select]
linux-image-5.11.13-2-siduction-amd64
I imagine a string like
Code: [Select]
"^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.