Bug 440222 - linux kernels are forever
Summary: linux kernels are forever
Status: ASSIGNED
Alias: None
Product: neon
Classification: KDE Neon
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR major
Target Milestone: ---
Assignee: Neon Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-24 12:08 UTC by Aleix Pol
Modified: 2024-07-09 19:10 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
journalctl output for boot where kernel packages were upgraded (175.11 KB, text/plain)
2022-08-05 19:37 UTC, Paul Worrall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aleix Pol 2021-07-24 12:08:19 UTC
My father brought me his laptop because it wasn't booting, it was because he had his / filesystem full (40 GiB).

I've managed to clean up 10 GiB of these because he had a bunch (>30) of linux kernel 5.4.0 images still on disk.

I've no idea what would be the right way, but getting rid of these would be ideal.

apt autoremove also doesn't catch these for some reason.
Comment 1 Harald Sitter 2021-08-04 14:50:44 UTC
Not sure we'll be able to figure out what's wrong considering you've cleaned them up. I think apt will keep at least 3 legacy kernels as backup. Once there are more the excess is marked auto and can be autoremoved (additionally autoremove isn't auto-run with packagekit until we go to ubuntu 22.04 :()
Comment 2 Nate Graham 2021-08-04 23:27:26 UTC
This happened to my wife too. It was one of those, "Hmm, maybe we should just install another distro..." moments. :/ autoremove not getting run automatically is the problem, in her case.
Comment 3 Harald Sitter 2021-08-16 14:51:17 UTC
https://github.com/PackageKit/PackageKit/issues/450

I'm leaving this bug open because we can actually work around this as far as kernels are concerned by explictly marking them auto. There's little opportunity for that to go wrong, but it'd allow kernels to be covered by autoremove.
Comment 5 Harald Sitter 2021-08-31 08:40:29 UTC
Git commit abda90d8fac48cf30161a27859d212c5f70e231e by Harald Sitter.
Committed on 18/08/2021 at 11:23.
Pushed by sitter into branch 'Neon/unstable'.

mark versioned kernels auto

there is a bug in packagekit that makes packages installed during
updates manual. this is extra horrible for kernels because they litter
up the system and even though we don't autoremove anyway, the user also
can't autoremove them because of this snafu

the new tool filters all (I hope) versioned package names from
showmanual and marks them auto again. this should enable autoremove to
clean them up properly

apt has guards in place to not remove too many kernels, so we can, for
the most part, mark them liberally auto. the only concern here would be
to mark meta packages incorrectly as well. I've also made a trivial test
case so we can add more samples in case we fall into the meta package
trap and need to test against it

this currently only targets Neon/unstable for testing

A  +21   -0    lib/systemd/system/neon-apt-mark-kernels-auto.service
A  +4400 -0    test/data/kernel_auto.apt-mark
A  +71   -0    test/kernel_auto_test.rb
A  +62   -0    usr/lib/neon_update/kernel_auto.rb

https://invent.kde.org/neon/neon/settings/commit/abda90d8fac48cf30161a27859d212c5f70e231e
Comment 6 Harald Sitter 2021-09-09 09:07:19 UTC
Git commit 1c31ad946d11718e75067abc988a9b0e68029cd3 by Harald Sitter.
Committed on 09/09/2021 at 08:26.
Pushed by sitter into branch 'Neon/release'.

mark versioned kernels auto

there is a bug in packagekit that makes packages installed during
updates manual. this is extra horrible for kernels because they litter
up the system and even though we don't autoremove anyway, the user also
can't autoremove them because of this snafu

the new tool filters all (I hope) versioned package names from
showmanual and marks them auto again. this should enable autoremove to
clean them up properly

apt has guards in place to not remove too many kernels, so we can, for
the most part, mark them liberally auto. the only concern here would be
to mark meta packages incorrectly as well. I've also made a trivial test
case so we can add more samples in case we fall into the meta package
trap and need to test against it

this currently only targets Neon/unstable for testing

A  +21   -0    lib/systemd/system/neon-apt-mark-kernels-auto.service
A  +4400 -0    test/data/kernel_auto.apt-mark
A  +71   -0    test/kernel_auto_test.rb
A  +62   -0    usr/lib/neon_update/kernel_auto.rb

https://invent.kde.org/neon/neon/settings/commit/1c31ad946d11718e75067abc988a9b0e68029cd3
Comment 7 Paul Worrall 2022-08-02 06:39:01 UTC
This workaround does not seem to be invoked.  Versioned kernel packages are still marked as manually installed.  Tested on Neon User and Unstable, using offline updates that include kernel packages,  via Discover.

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.15.0-41-generic (64-bit)
Graphics Platform: X11
Processors: 2 × AMD A6-6400K APU with Radeon(tm) HD Graphics
Memory: 7.7 GiB of RAM
Graphics Processor: AMD CEDAR
Manufacturer: NOVATECH LTD
Product Name: BB-64004H
System Version: V1.0
Comment 8 Paul Worrall 2022-08-05 19:37:58 UTC
Created attachment 151134 [details]
journalctl output for boot where kernel packages were upgraded

I have neon-settings-2 installed.

paul@desktop:~$ systemctl status neon-apt-mark-kernels-auto.service 
● neon-apt-mark-kernels-auto.service - Apt mark versioned kernel packages auto
     Loaded: loaded (/lib/systemd/system/neon-apt-mark-kernels-auto.service; static; vendor preset: enabled)
     Active: inactive (dead)

... but in the journal for the reboot where the upgrade occurred I can see no sign of neon-apt-mark-kernels-auto.service (see attached)

After the update:
paul@desktop:~$ apt-mark showmanual|grep linux
linux-generic
linux-headers-5.15.0-43-generic
linux-hwe-5.15-headers-5.15.0-43
linux-image-5.15.0-43-generic
linux-modules-5.15.0-43-generic
linux-modules-extra-5.15.0-43-generic
Comment 9 Harald Sitter 2022-08-05 22:27:09 UTC
If you have the release repo enabled you can try a fix that is up now. Alternatively if you do not have the release repo enabled you can simply switch /user for /release in your neon.list and try to upgrade. I think a newer version of neon-settings-2 should fix it, currently I'm having a hard time getting it into the user repository though.