Re: disk usage for /usr/lib on bullseye

[Tixy]

On Mon, 2023-05-01 at 13:51 +0000, Bonno Bloksma wrote:
[...]
> On my Bullseye machines the /usr/lib folder is 2+GB on the machines that have been operating for a while and 1+G on a machine that has been operating for a shorter while.
>
> The cause seems to be the folder /usr/lib/modules#
> linams:/usr/lib/modules# du * -sh
> 4.7M    5.10.0-10-amd64
> 4.7M    5.10.0-11-amd64
> 4.7M    5.10.0-12-amd64
> 4.7M    5.10.0-13-amd64
> 4.7M    5.10.0-15-amd64
> 4.7M    5.10.0-16-amd64
> 309M    5.10.0-18-amd64
> 309M    5.10.0-19-amd64
> 309M    5.10.0-20-amd64
> 309M    5.10.0-21-amd64
> 309M    5.10.0-22-amd64
> 4.7M    5.10.0-7-amd64
> 4.7M    5.10.0-8-amd64
> 4.7M    5.10.0-9-amd64

I think I see the same issue. I just looked at /usr/lib/modules and see
one extra directory for kernel that isn't installed (5.10.0-18-amd64).
Because this issue seemed familiar I looked at my bash command history
and that has me cd'ing into that directory and doing a du command there
and then deleting stuff. So I guess I've also resorted to manually
cleaning it up in the past.

--
Tixy

[David Wright]

On Mon 01 May 2023 at 13:51:06 (+0000), Bonno Bloksma wrote:

Hmm, that took a long time to get posted.

> On my "new" Bullseye machines the root volume starts to fill up. The cause seems to be the /usr/lib folder.
> On my older Buster (10.13) machine the total /usr directory is 701M, the /usr/lib folder is 260M
> In my /usr/lib folder on Buster is NO /usr/lib/modules folder

>
> On my Bullseye machines the /usr/lib folder is 2+GB on the machines that have been operating for a while and 1+G on a machine that has been operating for a shorter while.

I wonder whether you have a problem with usrmerge.
What does this show:

$ ls -ld /lib*
lrwxrwxrwx 1 root root 7 Apr 16 2022 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 Apr 16 2022 /lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Apr 16 2022 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Apr 16 2022 /libx32 -> usr/libx32
$

$ namei -l /usr/lib/modules/5.10.0-22-amd64/
f: /usr/lib/modules/5.10.0-22-amd64/
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root lib
drwxr-xr-x root root modules
drwxr-xr-x root root 5.10.0-22-amd64
$

Cheers,
David.

[Charles Curley]

On Mon, 1 May 2023 13:51:06 +0000
Bonno Bloksma <b.bl...@tio.nl> wrote:

> Guessing on what I see these are libraries for older kernel versions.
> I usually clean up older kernel versions by using # apt autoremove"
> All 3 servers have 1 older kernel version installed according to apt
> autoremove.

Autoremove removes packages, it does not purge. The difference is that
remove leaves configuration files in place. So you have a tedious bit
of "apt purge linux-image-… [linux-image-…]" etc. ahead. Just be sure
to not purge the two most recent kernel packages, and especially not
the kernel you are currently running on.


>
>
> Why is this stuff there? Can I delete it?
> If I can delete it, is there a proper way to clean it up or do I just
> rm /usr/lib/modules/5.10.0-.... for the older kernels?

See above.

I conjecture that the reason updating the kernel removes rather than
purges old kernels is in case the user has a custom kernel and wishes
to preserve those customizations.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[David Christensen]

On 5/1/23 06:51, Bonno Bloksma wrote:
> Hi,

>
> On my "new" Bullseye machines the root volume starts to fill up. The cause seems to be the /usr/lib folder.
> On my older Buster (10.13) machine the total /usr directory is 701M, the /usr/lib folder is 260M
> In my /usr/lib folder on Buster is NO /usr/lib/modules folder
>
> On my Bullseye machines the /usr/lib folder is 2+GB on the machines that have been operating for a while and 1+G on a machine that has been operating for a shorter while.
>

> The cause seems to be the folder /usr/lib/modules#
> linams:/usr/lib/modules# du * -sh
> 4.7M 5.10.0-10-amd64
> 4.7M 5.10.0-11-amd64
> 4.7M 5.10.0-12-amd64
> 4.7M 5.10.0-13-amd64
> 4.7M 5.10.0-15-amd64
> 4.7M 5.10.0-16-amd64
> 309M 5.10.0-18-amd64
> 309M 5.10.0-19-amd64
> 309M 5.10.0-20-amd64
> 309M 5.10.0-21-amd64
> 309M 5.10.0-22-amd64
> 4.7M 5.10.0-7-amd64
> 4.7M 5.10.0-8-amd64
> 4.7M 5.10.0-9-amd64
>

> And
> linutr:/usr/lib/modules# du * -sh
> 4.7M 5.10.0-16-amd64
> 4.7M 5.10.0-17-amd64

> 309M 5.10.0-18-amd64
> 309M 5.10.0-19-amd64
> 309M 5.10.0-20-amd64
> 309M 5.10.0-21-amd64
>

> And
> lola:/usr/lib/modules# du * -sh
> 4.7M 5.10.0-13-amd64
> 4.7M 5.10.0-19-amd64

> 309M 5.10.0-20-amd64
> 309M 5.10.0-21-amd64
> 309M 5.10.0-22-amd64
>

> Guessing on what I see these are libraries for older kernel versions. I usually clean up older kernel versions by using
> # apt autoremove"
> All 3 servers have 1 older kernel version installed according to apt autoremove.
>
>

> Why is this stuff there? Can I delete it?
> If I can delete it, is there a proper way to clean it up or do I just rm /usr/lib/modules/5.10.0-.... for the older kernels?
>

> Is this a BUG in Bullseye?
>
>
> p.s. Looking at this I just noticed I need to do an update on lunutr, I will dis that right after sending this mail ;-)
>
>
> Met vriendelijke groet,
> Bonno Bloksma
> Senior Systeembeheerder
>
>
> St. Jacobsstraat 400 | 3511 BT | Utrecht
> 030 - 3036 877 | direct 040-7 999 832
> b.bl...@tio.nl | www.tio.nl
>
> Volg ons op Facebook | LinkedIn | Instagram | YouTube
>


I use apt-get(8) 'update', 'upgrade', and 'dist-upgrade' on my Debian
instances and let it deal with /usr/lib/modules. Here is my daily
driver, installed on March 16, 2023, and updated/ dist-upgraded on April
29, 2023:

2023-05-01 10:55:22 root@taz ~
# cat /etc/debian_version ; uname -a
11.7
Linux taz 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64
GNU/Linux

2023-05-01 11:00:53 root@taz ~
# l -1 /boot/vmlinuz*
/boot/vmlinuz-5.10.0-21-amd64
/boot/vmlinuz-5.10.0-22-amd64

2023-05-01 11:01:36 root@taz ~
# du -mx -d 2 /usr/lib | sort -rh | head
2886 /usr/lib
950 /usr/lib/x86_64-linux-gnu
634 /usr/lib/modules
315 /usr/lib/modules/5.10.0-22-amd64
315 /usr/lib/modules/5.10.0-21-amd64
286 /usr/lib/libreoffice
215 /usr/lib/firefox-esr
211 /usr/lib/libreoffice/program
175 /usr/lib/jvm/java-11-openjdk-amd64
175 /usr/lib/jvm


Please run the above commands on one of your Debian 11 instances and
reply with the console session.


David

[Charles Curley]

On Mon, 1 May 2023 18:52:09 +0100
Brad Rogers <br...@fineby.me.uk> wrote:

> If memory serves, should one try to do that, warnings are issued.
>
> Not quite HAL in "2001, A Space Odyssey", but near enough. :-)

Ah. I don't recall that I've ever tried that. Maybe one should
experiment on a throw-away VM. :-)

Daisy, Daisy! I'm half crazy!
etc.

[Stefan Monnier]

>>to not purge the two most recent kernel packages, and especially not
>>the kernel you are currently running on.

> If memory serves, should one try to do that, warnings are issued.
> Not quite HAL in "2001, A Space Odyssey", but near enough. :-)

Also, purging the current kernel is not nearly as dangerous as
it sounds: in many (most) cases, the system will keep working just as
well as before (IIUC even hibernation will keep working since you can
now resume using a different initrd&kernel than the one you're resuming
to). The main downside is usually that you won't be able to access
devices that require different drivers than the ones already loaded.


Stefan

[Bret Busby]

Have you tried running also
apt autoclean
and
apt purge
?

--
..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[David Wright]

On Mon 01 May 2023 at 11:06:25 (-0600), Charles Curley wrote:

> On Mon, 1 May 2023 13:51:06 +0000 > Bonno Bloksma wrote:
>
> > Guessing on what I see these are libraries for older kernel versions.
> > I usually clean up older kernel versions by using # apt autoremove"
> > All 3 servers have 1 older kernel version installed according to apt
> > autoremove.
>
> Autoremove removes packages, it does not purge. The difference is that
> remove leaves configuration files in place. So you have a tedious bit
> of "apt purge linux-image-… [linux-image-…]" etc. ahead. Just be sure
> to not purge the two most recent kernel packages, and especially not
> the kernel you are currently running on.

The modules aren't configuration files. AFAICT linux-image-*.debs
don't contain any. A small number of module.* files are generated
at installation time, eg modules.dep is probably the best known.

> > Why is this stuff there? Can I delete it?
> > If I can delete it, is there a proper way to clean it up or do I just
> > rm /usr/lib/modules/5.10.0-.... for the older kernels?
>
> See above.
>
> I conjecture that the reason updating the kernel removes rather than
> purges old kernels is in case the user has a custom kernel and wishes
> to preserve those customizations.

But if you create custom modules in the modules tree (which
I used to do with ndiswrapper), then they don't appear in
/var/lib/dpkg/info/linux-image-*.md5sums, so they should get
left behind by remove or purge.

The only other files that remove will normally leave behind
are those that are generated at installation time. The
package's postrm script attempts to delete these, and lastly
the /lib/modules/$version/ directory if it is empty.

Cheers,
David.

[David Christensen]

On 5/1/23 11:14, Bret Busby wrote:

>> On 5/1/23 06:51, Bonno Bloksma wrote:
>>> Hi,
>>>
>>> On my "new" Bullseye machines the root volume starts to fill up.

> Have you tried running also
> apt autoclean
> and
> apt purge
> ?

I updated and cleaned my daily driver recently:

2023-04-29 11:54:03 root@taz ~
# apt-get update
<snip>

2023-04-29 11:54:29 root@taz ~
# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
linux-headers-amd64 linux-image-amd64
<snip>
Do you want to continue? [Y/n] n
Abort.

2023-04-29 11:54:55 root@taz ~
# apt-get dist-upgrade
<snip>

2023-04-29 12:31:08 root@taz ~
# apt autoremove
<snip>

2023-04-29 12:32:11 root@taz ~
# apt clean
<snip>

2023-04-29 12:34:22 root@taz ~/taz.tracy.holgerdanske.com
# fstrim -a
<snip>


Something for today -- systemd journal:

2023-05-01 12:20:57 root@taz ~
# du -mx -d 1 /var/log | sort -nr | head
426 /var/log
401 /var/log/journal
15 /var/log/installer
1 /var/log/speech-dispatcher
1 /var/log/runit
1 /var/log/private
1 /var/log/lightdm
1 /var/log/cups
1 /var/log/apt

2023-05-01 12:23:03 root@taz ~
# journalctl --disk-usage
Archived and active journals take up 400.0M in the file system.

2023-05-01 12:25:46 root@taz ~
# journalctl --vacuum-size=100M
<snip>

2023-05-01 12:28:05 root@taz ~
# journalctl --disk-usage
Archived and active journals take up 104.0M in the file system.

2023-05-01 12:28:35 root@taz ~
# du -mx -d 1 /var/log | sort -nr | head
130 /var/log
105 /var/log/journal
15 /var/log/installer
1 /var/log/speech-dispatcher
1 /var/log/runit
1 /var/log/private
1 /var/log/lightdm
1 /var/log/cups
1 /var/log/apt


Current usage of boot and root:

2023-05-01 12:34:52 root@taz ~
# df /boot /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/sda2 921M 118M 740M 14% /boot
/dev/mapper/sda4_crypt 11145M 6575M 3983M 63% /


David

[Rick Thomas]

Another thing I usually do after doing an "apt upgrade" that installs a new kernel is:
aptitude -P purge '~o'
aptitude -P purge '~c'

The "-P" tells aptitude to ask permission before actually deleting anything.

Rick

[Timothy M Butterworth]

Did anyone else notice the massive jump in file size here? 4.7M to 309M is a huge increase in file size!

 

>>> 309M    5.10.0-21-amd64
>>> 309M    5.10.0-22-amd64
>>>
>>> Guessing on what I see these are libraries for older kernel versions.
>>> I usually clean up older kernel versions by using
>>> # apt autoremove"
>>> All 3 servers have 1 older kernel version installed according to apt
>>> autoremove.
>>>
>
> Have you tried running also
> apt autoclean
> and
> apt purge
> ?
>
> --
> ..
> Bret Busby
> Armadale
> West Australia
> (UTC+0800)
> ..............

Another thing I usually do after doing an "apt upgrade" that installs a new kernel is:
    aptitude -P purge '~o'
    aptitude -P purge '~c'

The "-P" tells aptitude to ask permission before actually deleting anything.

Rick

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[David Wright]

On Mon 01 May 2023 at 23:24:56 (-0400), Timothy M Butterworth wrote:
> On Mon, May 1, 2023 at 10:45 PM Rick Thomas <rick....@pobox.com> wrote:
> > On Mon, May 1, 2023, at 11:14 AM, Bret Busby wrote:
> > > On 2/5/23 02:06, David Christensen wrote:
> > >> On 5/1/23 06:51, Bonno Bloksma wrote:
> > >>> The cause seems to be the folder /usr/lib/modules#
> > >>> linams:/usr/lib/modules# du * -sh
> > >>> 4.7M 5.10.0-10-amd64
> > >>> 4.7M 5.10.0-11-amd64
> > >>> 4.7M 5.10.0-12-amd64
> > >>> 4.7M 5.10.0-13-amd64
> > >>> 4.7M 5.10.0-15-amd64
> > >>> 4.7M 5.10.0-16-amd64
> > >>> 309M 5.10.0-18-amd64
> > >>> 309M 5.10.0-19-amd64
> > >>> 309M 5.10.0-20-amd64
> > >>> 309M 5.10.0-21-amd64
> > >>> 309M 5.10.0-22-amd64
> > >>> 4.7M 5.10.0-7-amd64
> > >>> 4.7M 5.10.0-8-amd64
> > >>> 4.7M 5.10.0-9-amd64
> > >>>
>

> Did anyone else notice the massive jump in file size here? 4.7M to 309M is
> a huge increase in file size!

4.7MB is the size of the modules.* that are created during
installation, as I mentioned in my post. These are deleted
by purge but not by remove, whereas:

$ du -sh /lib/modules/5.10.0-22-amd64/
309M /lib/modules/5.10.0-22-amd64/
$

is the modules themselves, awaiting deletion. (Actually, this
particular listing is my live kernel.)

Host linams is the most burdened one, with five sets of modules.
I'm assuming that the kernels/initrds have gone from /boot. If
all five are still there, then the good news is that my first
post doesn't apply, and they've simply forgotten to remove the
1st, 2nd and 3rd oldest kernels (and it's best to use purge
for less clutter).

> > > Have you tried running also
> > > apt autoclean

I thought that just cleared /var/cache/apt/archives/.

> > > and
> > > apt purge

I've never tried that without a package name. What does it do?

Cheers,
David.

[Bret Busby]

RTFM ?

[Bret Busby]

On 2/5/23 16:58, Bret Busby wrote:
> On 2/5/23 11:42, David Wright wrote:

<snip>

>>
>>>>> Have you tried running also
>>>>> apt autoclean
>>
>> I thought that just cleared /var/cache/apt/archives/.
>>
>>>>> and
>>>>> apt purge
>>
>> I've never tried that without a package name. What does it do?
>>
>
> RTFM ?
>

man apt

...

[Tixy]

On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> On 2/5/23 16:58, Bret Busby wrote:
> > On 2/5/23 11:42, David Wright wrote:
>
> <snip>
>
> > >
> > > > > > Have you tried running also
> > > > > > apt autoclean
> > >
> > > I thought that just cleared /var/cache/apt/archives/.
> > >
> > > > > > and
> > > > > > apt purge
> > >
> > > I've never tried that without a package name. What does it do?
> > >
> >
> > RTFM ?
> >
>
> man apt

Which doesn't say what 'apt purge' does without a package name. It says
'Performs the requested action on one or more packages specified via
regex(7), glob(7) or exact match'. It doesn't go on to say what happens
if you leave that blank. 3 possibilities that spring to mind is that
this is and error, a noop, or means 'every package'. The latter you be
real bad, the other two now a useful suggestion to people. Of course,
it could be special cased to mean 'purge everything not installed',
which count be useful, but the man page doesn't say that.

--
Tixy

[Bret Busby]

install, reinstall, remove, purge (apt-get(8))

Performs the requested action on one or more packages

specified via regex(7), glob(7) or exact match. The requested action can
be overridden for specific packages by
appending a plus (+) to the package name to install this
package or a minus (-) to remove it.

A specific version of a package can be selected for
installation by following the package name with an equals (=) and the
version of the package to select. Alternatively the
version from a specific release can be selected by following
the package name with a forward slash (/) and codename (bullseye,
bookworm, sid ...) or suite name (stable,
testing, unstable). This will also select versions from this
release for dependencies of this package if needed to satisfy the request.

Removing a package removes all packaged data, but leaves
usually small (modified) user configuration files behind, in case the
remove was an accident. Just issuing an
installation request for the accidentally removed package
will restore its function as before in that case. On the other hand you
can get rid of these leftovers by calling
purge even on already removed packages. Note that this does
not affect any data or configuration stored in your home directory.
"

I expect that, by context, running
apt purge
without the restriction specifying particular package, will apply
apt purge
to all installed packages, according to what purge does, in relation to
packages.

[Bret Busby]

On 2/5/23 18:20, Bret Busby wrote:

> I had meant to include (but forgot to include) in the above message;
>
> perhaps, if reading this, a package developer/maintainer for apt could
> clarify the above.
>

However, in reading the man entry for apt, further, I am of the
impression that what
apt purge
does, is removes redundant configuration files, rather than redundant
dependencies (which, I take to include libraries).

So, given

"
autoremove (apt-get(8))
autoremove is used to remove packages that were
automatically installed to satisfy dependencies for other packages and
are now no longer needed as dependencies changed or the
package(s) needing them were removed in the meantime.

You should check that the list does not include applications
you have grown to like even though they were once installed just as a
dependency of another package. You can mark
such a package as manually installed by using apt-mark(8).
Packages which you have installed explicitly via install are also never
proposed for automatic removal.
"

I expect that, as
apt autoremove
removes redundant kernels (and "packages that were automatically
installed to satisfy dependencies for other packages and are now no
longer needed as dependencies changed or the package(s) needing them
were removed in the meantime"), that apt autoremove should also remove
redundant libraries, which goes to the query of the original poster.

If
apt autoremove
does not remove orphaned (as in redundant, because the "packages that
were automatically installed to satisfy dependencies for other packages
and are now no longer needed as dependencies changed or the package(s)
needing them were removed in the meantime") libraries, then, perhaps,
apt autoremove has a slight deficiency?

[Greg Wooledge]

On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> > man apt
>
> Which doesn't say what 'apt purge' does without a package name. It says
> 'Performs the requested action on one or more packages specified via
> regex(7), glob(7) or exact match'. It doesn't go on to say what happens
> if you leave that blank.

Yeah, I couldn't find it either. The apt(8) man page is pretty damned
annoying, in fact. One must guess and infer like crazy, because it
doesn't come out and *state* all the things that should be stated.

For example, apt(8) says this:

install, reinstall, remove, purge (apt-get(8))

What does that "apt-get(8)" mean at the end of that line? Does it mean
that more information on "purge" is to be found in apt-get(8)? Here's
what apt-get(8) says about it:

purge
purge is identical to remove except that packages are removed and
purged (any configuration files are deleted too).

And here's what it says about remove:

remove
remove is identical to install except that packages are removed
instead of installed. Note that removing a package leaves its
configuration files on the system. If a plus sign is appended to
the package name (with no intervening space), the identified
package will be installed instead of removed.

Do these things apply to "apt purge" as well? Maybe. In any case, it
doesn't tell us what happens when no package names are specified.

Here's another fun little observation: apt(8) does not mention simulate,
dry-run, -s, or any other synonym for a command that one might use to
probe the behavior of the options and actions that are under-documented.
Maybe apt uses the same --dry-run option as apt-get. Maybe not.
Who knows? Is it safe to try? Who knows!!

Maybe I can experiment? Let's see if "apt purge" is a syntax error:

unicorn:~$ apt purge
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

Rats! No luck here. Either "apt purge" is not an error, or the argument
processing and validation happens only after acquiring the lock.

Now we have to tread dangerous waters to find out more information.

unicorn:~$ sudo apt --dry-run
[sudo] password for greg:
E: Command line option --dry-run is not understood in combination with the other options

OK... that's progress. It looks like the --dry-run option exists.
So maybe we can use that to avoid destroying our system by trying commands
as root.

unicorn:~$ sudo apt --dry-run purge

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So... uh... what happened here? It certainly didn't complain about a
lack of package names. No error messages. It didn't appear to *do*
anything, though, other than spend a bunch of time and energy reading
package lists and building dependency trees for no apparent reason.

Just to verify, I *do* have some packages in "rc" state.

unicorn:~$ dpkg -l | grep ^rc
rc fuse 2.9.9-3 amd64 Filesystem in Userspace
rc libreoffice-sdbc-firebird 1:6.1.5-3+deb10u6 amd64 Firebird SDBC driver for LibreOffice
rc libsensors4:amd64 1:3.4.0-4 amd64 library to read temperature/voltage/fan sensors
rc python 2.7.16-1 amd64 interactive high-level object-oriented language (Python2 version)

So it looks like "apt purge" might not do anything at all. At least,
in combination with --dry-run it doesn't *say* that it's going to do
anything.

If you're braver than I am, you might try it without the --dry-run and
see what happens. I'm guessing it'll do nothing, but I cannot guarantee
that, and I take no responsibility for any losses or damage.

[Bret Busby]

I had meant to include (but forgot to include) in the above message;

perhaps, if reading this, a package developer/maintainer for apt could
clarify the above.

--

[Michel Verdier]

Le 2 mai 2023 Bret Busby a écrit :

> I expect that, by context, running
> apt purge
> without the restriction specifying particular package, will apply
> apt purge
> to all installed packages, according to what purge does, in relation to
> packages.

But as "apt purge <package>" remove this package and remove configuration
for this package, I hope that "apt purge" will not remove "all installed
packages". Personnally I will not test it...

[Bret Busby]

I believe that this is a case of a problem with having different primary
languages (me, English, the above poster, French), with things getting
"lost in translation".

I did not mean that purge will remove all installed languages; as
according to my last previous post in this thread (I think it was my
last previous post - I am not sure);
apt purge
apparently removes obsolete configuration files (orphaned configuration
files - that would have been associated with only packages that have
been removed), and, so, where a particular package is specified as an
argument to the command, all obsolete configuration files associated
with the package, will be removed, and, where no package is specified as
an argument to the command, all obsolete configuration files for "all
installed packages", will be removed.

No suggestion has been made, insofar as I am aware, other than in the
above post, that using
apt purge
will remove all installed packages.

I think that, to remove all installed packages, a system administrator,
from the superuser level, needs to run something like
rm -r /
(assuming that the /bin and /sbin (etc, etc, etc) directories are within
the / partition, and, not in partitions separate to the / partition)
- the use of which command, I do not recommend.

[Michel Verdier]

Le 2 mai 2023 Bret Busby a écrit :

> and, so, where a particular package is specified as an argument to the
> command, all obsolete configuration files associated with the package, will be
> removed, and, where no package is specified as an argument to the command, all
> obsolete configuration files for "all installed packages", will be removed.

Greg tests tends to show it is not the case.

> I think that, to remove all installed packages, a system administrator, from
> the superuser level, needs to run something like
> rm -r /
> (assuming that the /bin and /sbin (etc, etc, etc) directories are within the /
> partition, and, not in partitions separate to the / partition)

Even separate partitions will be emptied if mounted

> - the use of which command, I do not recommend.

Neither do I. But I remember a rm -r *
* is so close to enter... :/

[Tixy]

On Tue, 2023-05-02 at 22:28 +0800, Bret Busby wrote:
> I think that, to remove all installed packages, a system administrator,
> from the superuser level, needs to run something like
> rm -r /

Or

apt remove '*'

Man page for apt says it accepts regex and globs for package
specifiers. Other tools like apt-get and aptitude also allow some form
of wildcard specification.

I don't know which of the various packaging tools allow you to force
uninstalling priority essential packages though, but the low level dpkg
itself does, so you can come up with a shell one-liner to get a list of
installed packages and remove them all. Of course, this would break at
some point after removing a package with executable programs used by
package scripts. ;-)

--
Tixy

[The Wanderer]

I continue to be bewildered that the idea that it will do *anything* has
even come up.

My understanding, for more than a decade now, has been (as it continues
to be) that:

'apt-get remove packagename' will remove the package, if it's installed,
but not remove its config files.

'apt-get purge packagename' will remove the package, if it's installed,
and also remove its config files, if they are present.

'apt-get remove' with no 'packagename' argument is a syntax error.

'apt-get purge' with no 'packagename' argument is a syntax error.

The command 'apt' is newer than that, I think, but I see no reason to
think that these verbs would behave any differently between the two
commands.

Aside from some possibly-unclear wording in the man page(s), where is
the idea that running either of these verbs with no package-name
argument will make them apply to *all installed packages* coming from?
That would be an *insane* design decision, IMO, and it seems bizarre
that anyone is even coming up with the idea in the first place, let
alone that it's being given any credit.

> I think that, to remove all installed packages, a system administrator,
> from the superuser level, needs to run something like
> rm -r /
> (assuming that the /bin and /sbin (etc, etc, etc) directories are within
> the / partition, and, not in partitions separate to the / partition)
> - the use of which command, I do not recommend.

That would remove far more than all installed packages; it would also
remove all files not included in any package, and potentially also all
files on any mounted network shares, et cetera.

IIRC, there are packages which the system will refuse to remove, unless
an appropriate overriding action is taken. It may now be the case that
there are packages which the system will refuse to remove entirely,
without offering any means to override the refusal.

If that were not the case, removing all installed packages could
probably be done by something like

apt-get remove $(apt-mark showmanual) $(apt-mark showauto)

except that A: the resulting list of packages would probably be too long
for a single command line, and B: one of the packages which this would
try to remove (probably fairly early on, since they'd be listed in
alphabetical order) would be the 'apt' package itself, which contains
both 'apt-mark' and 'apt-get', and so the process would probably break
after that.

It's a pointless thing to discuss, in any case, since I have been unable
to think of essentially any reason why anyone would ever want to do any
such thing.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[David Wright]

On Tue 02 May 2023 at 08:09:57 (-0400), Greg Wooledge wrote:
> On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
> > On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> > > man apt
> >
> > Which doesn't say what 'apt purge' does without a package name. It says
> > 'Performs the requested action on one or more packages specified via
> > regex(7), glob(7) or exact match'. It doesn't go on to say what happens
> > if you leave that blank.

> unicorn:~$ sudo apt --dry-run purge
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> So... uh... what happened here? It certainly didn't complain about a
> lack of package names. No error messages. It didn't appear to *do*
> anything, though, other than spend a bunch of time and energy reading
> package lists and building dependency trees for no apparent reason.

> So it looks like "apt purge" might not do anything at all. At least,
> in combination with --dry-run it doesn't *say* that it's going to do
> anything.
>
> If you're braver than I am, you might try it without the --dry-run and
> see what happens. I'm guessing it'll do nothing, but I cannot guarantee
> that, and I take no responsibility for any losses or damage.

It seems a bluff was called. Anyway, I got
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
as it seems bookworm's libfreetype6 was upgraded overnight.

And I'm not brave; the system was installed last night for the
umpteenth time, this partition having been used to test the d-i
for bookwork-RC1 several times for different purposes.

Cheers,
David.

[David Wright]

On Tue 02 May 2023 at 22:28:11 (+0800), Bret Busby wrote:
> On 2/5/23 20:23, Michel Verdier wrote:
> > Le 2 mai 2023 Bret Busby a écrit :
> >
> > > I expect that, by context, running
> > > apt purge
> > > without the restriction specifying particular package, will apply
> > > apt purge
> > > to all installed packages, according to what purge does, in relation to
> > > packages.
> >
> > But as "apt purge <package>" remove this package and remove configuration
> > for this package, I hope that "apt purge" will not remove "all installed
> > packages". Personnally I will not test it...
> >
> I believe that this is a case of a problem with having different
> primary languages (me, English, the above poster, French), with things
> getting "lost in translation".
>

> I did not mean that purge will remove all installed [packages]; as

> according to my last previous post in this thread (I think it was my
> last previous post - I am not sure);
> apt purge
> apparently removes obsolete configuration files (orphaned
> configuration files - that would have been associated with only
> packages that have been removed), and, so, where a particular package
> is specified as an argument to the command, all obsolete configuration
> files associated with the package, will be removed, and, where no
> package is specified as an argument to the command, all obsolete
> configuration files for "all installed packages", will be removed.

I just tried it. I removed bluez, which took out bluetooth, and left
the configuration files for bluez. It also listed nine packages that
are now ripe for autoremoval.

I then ran apt purge and it merely repeated the list of nine
packages. The bluez configuration files were still present.

> No suggestion has been made, insofar as I am aware, other than in the
> above post, that using
> apt purge
> will remove all installed packages.

You wrote:

"I expect that, by context, running
apt purge
without the restriction specifying particular package, will apply
apt purge
to all installed packages, according to what purge does, in relation to
packages."

which is as clear as mud to this English speaker. It would be easily
interpreted as:

apt purge <list of all packages on the system>

Cheers,
David.

[debia...@howorth.org.uk]

I think you're all speculating too far. It says it will purge 'one or
more packages specified via regex(7), glob(7) or exact match'. So if you
specify none, I expect it will purge none.

Oh, and 'purge is identical to remove except that packages are removed
and purged (any configuration files are deleted too)'. It doesn't JUST
remove config files.

[David Wright]

On Tue 02 May 2023 at 11:39:09 (-0400), The Wanderer wrote:
> It's a pointless thing to discuss, in any case, since I have been unable
> to think of essentially any reason why anyone would ever want to do any
> such thing.

It makes me think of that gruesome cartoon where a meat mincer's
handle is being turned by an arm emerging from the funnel.

Cheers,
David.

[songbird]

David Wright wrote:
...

> It seems a bluff was called. Anyway, I got
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> as it seems bookworm's libfreetype6 was upgraded overnight.

that was the only upgrade i saw this morning for my
testing partition.

> And I'm not brave; the system was installed last night for the
> umpteenth time, this partition having been used to test the d-i
> for bookwork-RC1 several times for different purposes.

if you're running testing you're a step further towards
chaos than those who run stable, but it's ok if you've
been running it long enough to know what to expect. for
me that is the most important thing, i know what i can
expect and so far Debian has been consistent in meeting
those expectations.


songbird

[David Wright]

On Tue 02 May 2023 at 13:03:48 (-0400), songbird wrote:
> David Wright wrote:
> ...
> > It seems a bluff was called. Anyway, I got
> > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> > as it seems bookworm's libfreetype6 was upgraded overnight.
>
> that was the only upgrade i saw this morning for my
> testing partition.

It's the "0 to remove" that was significant, ie apt purge
did nothing: no packages removed, no configuration files
removed, no syntax error, no nothing.

> > And I'm not brave; the system was installed last night for the
> > umpteenth time, this partition having been used to test the d-i
> > for bookwork-RC1 several times for different purposes.
>
> if you're running testing you're a step further towards
> chaos than those who run stable, but it's ok if you've
> been running it long enough to know what to expect. for
> me that is the most important thing, i know what i can
> expect and so far Debian has been consistent in meeting
> those expectations.

No chaos here: I've been installing bookwork-RC1 to attempt to
replicate problems reported by others here, though I no longer
have any MBR-partitioned disks, nor do I run exotic filesystems
or VMs either.

I haven't had the time to use bookworm beyond installing the
basic system, and there's been no real imperative to use it
as bullseye is working well on all my systems, which are from
six to nineteen years old.

Cheers,
David.

[Charlie Gibbs]

Oh yes, the one with the police inspector who dryly observes:
"It's the most determined case of suicide I've ever seen."

--
/~\ Charlie Gibbs | Life is perverse.
\ / <cgi...@kltpzyxm.invalid> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin

[Curt]

On 2023-05-02, Greg Wooledge <gr...@wooledge.org> wrote:
>
> unicorn:~$ apt purge
> E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
>
> Rats! No luck here. Either "apt purge" is not an error, or the argument
> processing and validation happens only after acquiring the lock.
>
> Now we have to tread dangerous waters to find out more information.
>

You really don't have to tread dangerous waters (or rather wade into
them, unless your Jesus) because you can simulate without root privileges.

curty@einstein:~$ apt -s purge
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!

Reading package lists... Done
Building dependency tree

Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

[Michel Verdier]

Le 3 mai 2023 Curt a écrit :

> You really don't have to tread dangerous waters (or rather wade into
> them, unless your Jesus) because you can simulate without root privileges.
>
> curty@einstein:~$ apt -s purge
> NOTE: This is only a simulation!

Nice parameter, thanks !

[to...@tuxteam.de]

On Wed, May 03, 2023 at 04:22:55PM -0000, Curt wrote:

[...]

> You really don't have to tread dangerous waters (or rather wade into
> them, unless your Jesus) because you can simulate without root privileges.

Yes, +1 for -s :-)

> curty@einstein:~$ apt -s purge
> NOTE: This is only a simulation!
> apt needs root privileges for real execution.
> Keep also in mind that locking is deactivated,
> so don't depend on the relevance to the real current situation!

^^^^^^^^^^^^^^^^^^^^^^^^^

...but then this sounds like a downright threat, doesn't it?

;-)

Cheers

Q: "Doctor, the -s option told me it would remove 0 packages"
A: "Yes, but we told you to nor depend on it"

--
t

[zithro]

On 03 May 2023 18:22, Curt wrote:
> You really don't have to tread dangerous waters (or rather wade into
> them, unless your Jesus) because you can simulate without root privileges.
>
> curty@einstein:~$ apt -s purge
> NOTE: This is only a simulation!

Quick nitpicking.
Even if "-s" is easily remembered as Simulate, there's also the
equivalent long option : "--dry-run".
Ok, it's longer to type

[Greg Wooledge]

On Fri, May 05, 2023 at 02:35:08PM +0000, Bonno Bloksma wrote:
> Just created a snapshot of my servers and then did:
> apt autoremove
> apt purge
> apt clean
> and I still have a working system so it will not just get rid of all installed packages. :-)
> But... I still also have all those folders in /usr/lib/modules

It seems like you're just trying random commands without understanding
what they do.

"apt autoremove" will remove (not purge) packages that meet various
criteria, which can be defined in /etc/apt/apt.conf.d/ configuration
files. The intent is to have it do something sensible for the ordinary
user. Among other things, it removes all but the two most recent
kernels, and it removes packages that no longer have anything depending
on them, and which are also not marked as manually installed.

"apt purge", as we've experimentally determined, seems to do nothing.

"apt clean" removes all of the cached *.deb files in /var/cache/apt/archives.
You may not HAVE any such files, if you've been using "apt" exclusively
(as opposed to "apt-get", which leaves the files behind).

> I am now cleaning some by hand. Running kernel -22 and having -21 as backup kernel I did:
> xxxxx:/usr/lib/modules# rm -rd 5.10.0-16-amd64/
> xxxxx:/usr/lib/modules# rm -rd 5.10.0-17-amd64/
> xxxxx:/usr/lib/modules# rm -rd 5.10.0-18-amd64/

One imagines that if you simply purged all of the kernel packages that
had been autoremoved, this would clean up the modules. But I'm not
100% sure about that. If you've got modules that were built by dkms
for example, I don't know whether those would be removed.

It would be nice to know whether you had to do this "rm -r" because the
"dpkg --purge linux-image-5.10.0-16-amd64" failed to remove the modules,
or whether you simply did not KNOW to try the dpkg --purge first.

[David Wright]

On Fri 05 May 2023 at 14:35:08 (+0000), Bonno Bloksma wrote:
> As I was trying to find out what would work and if I was doing something wrong getting rid of old kernels....
>
> After upgrading a new kernel for a week I will do apt autoremove to get rid of the old kernel(s).

And this will produce the situation you have with 16 and 17:

linutr:/usr/lib/modules# du * -sh
4.7M 5.10.0-16-amd64
4.7M 5.10.0-17-amd64

309M 5.10.0-18-amd64
309M 5.10.0-19-amd64
309M 5.10.0-20-amd64
309M 5.10.0-21-amd64

You need to run apt --purge autoremove in order to remove the
files that aren't in the linux-package that you installed. Look:

$ ls -Glg /lib/modules/5.10.0-21-amd64/
total 4968
drwxr-xr-x 12 4096 Jan 23 21:45 kernel
-rw-r--r-- 1 1241172 Jan 23 21:46 modules.alias
-rw-r--r-- 1 1187730 Jan 23 21:46 modules.alias.bin
-rw-r--r-- 1 5541 Jan 21 08:35 modules.builtin
-rw-r--r-- 1 0 Jan 23 21:46 modules.builtin.alias.bin
-rw-r--r-- 1 6754 Jan 23 21:46 modules.builtin.bin
-rw-r--r-- 1 38430 Jan 21 08:35 modules.builtin.modinfo
-rw-r--r-- 1 498055 Jan 23 21:46 modules.dep
-rw-r--r-- 1 671751 Jan 23 21:46 modules.dep.bin
-rw-r--r-- 1 476 Jan 23 21:46 modules.devname
-rw-r--r-- 1 154011 Jan 21 08:35 modules.order
-rw-r--r-- 1 1067 Jan 23 21:46 modules.softdep
-rw-r--r-- 1 562879 Jan 23 21:46 modules.symbols
-rw-r--r-- 1 685618 Jan 23 21:46 modules.symbols.bin
$

apt (auto)remove only removes the package files, dated Jan 21.
The ones here dated Jan 23 were generated when the package was
installed, and are only removed when you /purge/ the package.

> Debian will automatically keep the current kernel and the previous in the /boot folder.
> Somehow, I get the feeling there either is a bug which causes the /usr/lib/modules/ folder not to be cleaned up or there are somehow links to it from packages that were updated when a specific kernel was active.

> But.... is this a bug in the cleanup of an old kernel or are there realy links to the old modules, links that are now broken?
> If it s a bug, who will report it? I know only enough to report the symptoms.

Someone who demonstrates it. AFAICT you don't seem to be aware of
the --purge option and the necessity of using it here, and have
likely just forgotten to even run apt autoremove in the case of
versions 18 and 19 above (where the modules are also present).

On Fri 05 May 2023 at 11:54:55 (-0400), Greg Wooledge wrote:
> On Fri, May 05, 2023 at 02:35:08PM +0000, Bonno Bloksma wrote:
> > Just created a snapshot of my servers and then did:

[ … ]

> It seems like you're just trying random commands without understanding
> what they do.

Agreed. It makes you wonder how much in this thread that was written
about these commands has been absorbed.

> > I am now cleaning some by hand. Running kernel -22 and having -21 as backup kernel I did:
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-16-amd64/
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-17-amd64/
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-18-amd64/
>
> One imagines that if you simply purged all of the kernel packages that
> had been autoremoved, this would clean up the modules. But I'm not
> 100% sure about that. If you've got modules that were built by dkms
> for example, I don't know whether those would be removed.

Custom modules would remain, and the rest of the directory tree
removed. This is confirmed by the postrm script, which disposes
of the equivalents to those files dated Jan 23 above.

if [ "$1" = purge ]; then
for extra_file in modules.dep modules.isapnpmap modules.pcimap \
modules.usbmap modules.parportmap \
modules.generic_string modules.ieee1394map \
modules.ieee1394map modules.pnpbiosmap \
modules.alias modules.ccwmap modules.inputmap \
modules.symbols modules.ofmap \
modules.seriomap modules.\*.bin \
modules.softdep modules.devname; do
eval rm -f /lib/modules/$version/$extra_file
done
rmdir /lib/modules/$version || true
fi

> It would be nice to know whether you had to do this "rm -r" because the
> "dpkg --purge linux-image-5.10.0-16-amd64" failed to remove the modules,
> or whether you simply did not KNOW to try the dpkg --purge first.

I don't think dpkg had yet been suggested as a solution, but it would
do just the same thing, because that is what APT itself uses of course.
Again, custom files would remain, with the usual

dpkg: warning: while removing x, directory 'y' not empty so not removed

message as a reminder.

Cheers,
David.

[David Wright]

On Mon 08 May 2023 at 08:27:52 (+0000), Bonno Bloksma wrote:

> > "apt autoremove" will remove (not purge) packages

> [....]
> Thanks for the better explanation, that is what I understood as well.

I doubt that.

> > One imagines that if you simply purged all of the kernel packages that had been autoremoved, this would clean up the modules.

> Yes, that would seem to be prudent but I also do not understand why the modules would be left behind? As far as I understand they are the module part of the kernel. Without the kernel they are useless. Why not treat them as part of the kernel. When I remove the kernel, remove the modules.

In your linams system, used as the example below, you removed, but did
not purge, versions 7 through 16. We assume (because you haven't shown
us) that the kernel/initrd/config/systemmap have all gone, and we can
see that the *modules have also been deleted*. That's why each of those
/lib/modules/5.10.0-NN-amd64/ directories only occupies 4.7MB of space
rather than 309MB (as listed in your OP).

> > But I'm not 100% sure about that. If you've got modules that were built by dkms for example, I don't know whether those would be removed.

> As I use the apt and (apt-get) exclusively for package management I would like them to clean up what I do not need when I tell it to clean it up.

For the sake of brevity, I'm going to assume that you're not compiling
custom kernel modules, and so we can put on one side the fact that
even purge would not delete them.

As for "cleaning up", apt(-get) does just what you instruct it to do.

> > It would be nice to know whether you had to do this "rm -r" because the "dpkg --purge linux-image-5.10.0-16-amd64" failed to remove the modules, or whether you simply did not KNOW to try the dpkg --purge first.
>

> Look here:

Yes, look /carefully/ (at the number of links. That's the number
between permissions and owner).

> ------<Quote>---------------------
> xxxxxx:~# cd /usr/lib/modules
> xxxxxx:/usr/lib/modules# ll
> total 56
> drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-10-amd64
> drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-11-amd64
> drwxr-xr-x 2 root root 4096 Jun 17 2022 5.10.0-12-amd64
> drwxr-xr-x 2 root root 4096 Jul 29 2022 5.10.0-13-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
> drwxr-xr-x 3 root root 4096 Sep 17 2022 5.10.0-18-amd64
> drwxr-xr-x 3 root root 4096 Nov 2 2022 5.10.0-19-amd64
> drwxr-xr-x 3 root root 4096 Jan 3 16:51 5.10.0-20-amd64
> drwxr-xr-x 3 root root 4096 Mar 3 09:40 5.10.0-21-amd64
> drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
> drwxr-xr-x 2 root root 4096 Dec 13 2021 5.10.0-7-amd64
> drwxr-xr-x 2 root root 4096 Jan 24 2022 5.10.0-8-amd64
> drwxr-xr-x 2 root root 4096 Mar 11 2022 5.10.0-9-amd64
> xxxxxx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-7-amd64
> (Reading database ... 57231 files and directories currently installed.)
> Purging configuration files for linux-image-5.10.0-7-amd64 (5.10.40-1) ...
> xxxxxx:/usr/lib/modules# ll
> total 52
> drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-10-amd64
> drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-11-amd64
> drwxr-xr-x 2 root root 4096 Jun 17 2022 5.10.0-12-amd64
> drwxr-xr-x 2 root root 4096 Jul 29 2022 5.10.0-13-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
> drwxr-xr-x 3 root root 4096 Sep 17 2022 5.10.0-18-amd64
> drwxr-xr-x 3 root root 4096 Nov 2 2022 5.10.0-19-amd64
> drwxr-xr-x 3 root root 4096 Jan 3 16:51 5.10.0-20-amd64
> drwxr-xr-x 3 root root 4096 Mar 3 09:40 5.10.0-21-amd64
> drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
> drwxr-xr-x 2 root root 4096 Jan 24 2022 5.10.0-8-amd64
> drwxr-xr-x 2 root root 4096 Mar 11 2022 5.10.0-9-amd64
> xxxxxx:/usr/lib/modules#
>
> ------<Quote>---------------------
>
> So it seems using the dpkg --purge against the removed kernel version is the proper way(?) to get rid of the kernels.

If you want your 4.7MB (×8) of space back, yes.

> But I still think this should be part of the apt autoremove for kernels.

No, that's not policy. If "remove" purges, then why bother with
having a --purge option at all?

> I understand there are circumstances where not al modules assigned to a kernel version are part of the kernel. But... would they be of any use when that kernel version is no longer installed?

I've already explained exactly what is not deleted by "remove",
but requires "purge" as well or instead. I listed the actual
files, about ten of them:

https://lists.debian.org/debian-user/2023/05/msg00275.html

In the listing above, you have removed versions 7 through 16,
and then purged 7, as quoted above. The remaining 8 through 16
contain no modules, and the evidence is shown in your listing
above: there can be no kernel/ directory in any of them.

Debian has put in place some protections for kernels to try to
prevent users from making the system unbootable. What Debian
isn't going to do is change entirely the APT policy just to
suit your reluctance to purge kernels rather than just remove
them; viz:

remove: removes the files in the package, but not configuration
(or other) files that it or you might have installed.

purge: removes both the files in the package and the configuration
files, including those in the package and those generated at
installation time. (In addition, it makes enquiries when files
designated as configuration files are detected as having been
changed from what was supplied in the package.)

Cheers,
David.

[Lee]

On 5/2/23, Greg Wooledge wrote:
> On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
>> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
>> > man apt
>>
>> Which doesn't say what 'apt purge' does without a package name. It says
>> 'Performs the requested action on one or more packages specified via
>> regex(7), glob(7) or exact match'. It doesn't go on to say what happens
>> if you leave that blank.
>

> Maybe I can experiment? Let's see if "apt purge" is a syntax error:
>
> unicorn:~$ apt purge
> E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
> Permission denied)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend),
> are you root?
>
> Rats! No luck here. Either "apt purge" is not an error, or the argument
> processing and validation happens only after acquiring the lock.
>
> Now we have to tread dangerous waters to find out more information.
>
> unicorn:~$ sudo apt --dry-run
> [sudo] password for greg:
> E: Command line option --dry-run is not understood in combination with the
> other options
>
> OK... that's progress. It looks like the --dry-run option exists.
> So maybe we can use that to avoid destroying our system by trying commands
> as root.
>
> unicorn:~$ sudo apt --dry-run purge
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

you're a better sysadmin? I get

$ sudo apt --dry-run purge
[sudo] password for lee:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

The following packages were automatically installed and are no longer required:
linux-image-5.10.0-19-amd64 linux-image-5.10.0-20-amd64
Use 'sudo apt autoremove' to remove them.

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Regards
Lee