linux-kernel* and linux-header* is NOT removed usin autoclea

Started by michaa7, 2013/05/21, 14:19:36

Previous topic - Next topic

michaa7

My /var/cache/apt/archives/ is 6.5 GB . Although using autoclean this (extra-) partition now has not enough space for the incomming packages.

While investigating /var/cache/apt/archives/ I discovered 39 linux-kernel* and 39linux-header* packages. This amounts to a huge number of bytes.

1) It seems autoclean doesn't delete them because the name is always different.
2) Is there no automated way (exept "clean") to remove those files automaticly (can't it be done with an improved version of kernel-remover?)?
3)How is it supposed to work normaly? Is it something which has to be done manually?

At least I understand now why normal Debian kernel packages always have the same name (no subversion) until the major number changes.
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

Smon

Older kernels aren't removed automatically. Try to purge them and then autoclean.
If you have bash completion make:
apt-get purge linux-image[TAB]
apt-get purge linux-header[TAB]

or use the kernel-remove script, i think it should be installed already

michaa7

There is a misunderstanding here: I speak about kernel and header packages in /var/cache/apt/archives/ although I did remove the kernels with kernel remover.
Currently I have installed one single kernel (usualy I have at least two), but 39 kernel packages in the archive.

Are you trying to tell me that removing kernels with kernel-remover deletes the packages in the archive on your system (here it clearly does not)? Sure? Did you controll?
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

Smon

No, i meant, autoclean does not remove packages, when they are installed.
I thought, you maybe have 39 kernels installed, because old ones aren't purged automatically.

Sorry, i maybe misunderstood your question in the first place.


Edit: Ok, same here. Not as much as you have, but more then installed in /var/cache/apt/archives/

michaa7

Ok, you can't code, but you still might be able to write a bug report for Debian's sake

Smon


piper

Using
apt-get clean
I have nothing in /var/cache/apt/archives/

clean
clean clears out the local repository of retrieved package files.
It removes everything but the lock file from
/var/cache/apt/archives/ and /var/cache/apt/archives/partial/. When
APT is used as a dselect(1) method, clean is run automatically.
Those who do not use dselect will likely want to run apt-get clean
from time to time to free up disk space.

autoclean
Like clean, autoclean clears out the local repository of retrieved
package files. The difference is that it only removes package files
that can no longer be downloaded, and are largely useless. This
allows a cache to be maintained over a long period without it
growing out of control. The configuration option
APT::Clean-Installed will prevent installed packages from being
erased if it is set to off.
I have a Lucky Rabbit:    "Svoot" ..... (It's Swedish)

I am MAGA

michaa7

Thanks piper.

I understand "apt-get clean", but I *want* to hold back the last two sets of packages as "autoclean" does. The problem is that those kernel and header packages accumulate due to thier names being different. I wasn't aware of this problem until the partition was full ;-).

I "solved" it manually. But as this situation seems to affect all users who want to keep (last two) current packages an automated removal would be great.
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

piper

I have a Lucky Rabbit:    "Svoot" ..... (It's Swedish)

I am MAGA

michaa7

Quote from: "piper"This is sid, wheres your sense of adventure :) :)

no, this has nothing to do with sid being adventuorus. It's boring and nerving to clean up the apt archives *manually*  :wink:
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

mylo

Hi all,
I checked my apt....archives and have 2.6 GB accumulated in this directory since 2010. Here no prob, because of available disk space.