Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #255451 > unrolled thread

solution to / full

Back to article view | Back to linux.debian.user

Contents

  solution to / full lina <lina.lastname@gmail.com> - 2023-03-01 14:40 +0100
    Re: solution to / full Jochen Spieker <ml@well-adjusted.de> - 2023-03-01 15:20 +0100
      Re: solution to / full The Wanderer <wanderer@fastmail.fm> - 2023-03-01 18:00 +0100
      Re: solution to / full Jonathan Dowland <jon+debian-user@dow.land> - 2023-03-02 10:50 +0100
        Re: solution to / full Greg Wooledge <greg@wooledge.org> - 2023-03-02 13:30 +0100
          Re: solution to / full Jonathan Dowland <jon+debian-user@dow.land> - 2023-03-02 14:20 +0100
            Re: solution to / full Curt <curty@free.fr> - 2023-03-03 16:50 +0100
              Re: solution to / full davidson <davidson@freevolt.org> - 2023-03-03 20:10 +0100
              Re: solution to / full David Wright <deblis@lionunicorn.co.uk> - 2023-03-04 18:20 +0100
                Re: solution to / full Jonathan Dowland <jon+debian-user@dow.land> - 2023-03-06 11:50 +0100
                  Re: solution to / full Jonathan Dowland <jon+debian-user@dow.land> - 2023-03-06 15:20 +0100
    Re: solution to / full Klaus Singvogel <klaus@singvogel.net> - 2023-03-01 17:00 +0100
    Re: solution to / full <tomas@tuxteam.de> - 2023-03-01 17:50 +0100
      Re: solution to / full Brian <ad44@cityscape.co.uk> - 2023-03-01 19:20 +0100
        Re: solution to / full <tomas@tuxteam.de> - 2023-03-01 19:40 +0100
          Re: solution to / full Brian <ad44@cityscape.co.uk> - 2023-03-01 21:30 +0100
        Re: solution to / full Greg Wooledge <greg@wooledge.org> - 2023-03-01 19:40 +0100
          Re: solution to / full Joe <joe@jretrading.com> - 2023-03-01 21:00 +0100
            Re: solution to / full Greg Wooledge <greg@wooledge.org> - 2023-03-01 21:10 +0100
          Re: solution to / full Brian <ad44@cityscape.co.uk> - 2023-03-01 21:30 +0100
        Re: solution to / full Joe <joe@jretrading.com> - 2023-03-01 20:50 +0100
          Re: solution to / full Brian <ad44@cityscape.co.uk> - 2023-03-01 21:20 +0100
          Re: solution to / full songbird <songbird@anthive.com> - 2023-03-03 05:10 +0100
            Re: solution to / full David Wright <deblis@lionunicorn.co.uk> - 2023-03-03 06:20 +0100
    Re: solution to / full Andy Smith <andy@strugglers.net> - 2023-03-01 18:10 +0100
      Re: solution to / full Nicolas George <george@nsup.org> - 2023-03-01 20:00 +0100
        Re: solution to / full Andy Smith <andy@strugglers.net> - 2023-03-01 21:00 +0100
          Re: solution to / full David Wright <deblis@lionunicorn.co.uk> - 2023-03-02 00:30 +0100
          Re: solution to / full songbird <songbird@anthive.com> - 2023-03-03 05:10 +0100
      Re: solution to / full Richard Hector <richard@walnut.gen.nz> - 2023-03-03 07:50 +0100
    Re: solution to / full David Christensen <dpchrist@holgerdanske.com> - 2023-03-01 22:00 +0100
    Re: solution to / full Charles Curley <charlescurley@charlescurley.com> - 2023-03-01 22:30 +0100
      Re: solution to / full Jonathan Dowland <jon+debian-user@dow.land> - 2023-03-02 10:40 +0100
    Re: solution to / full Jeffrey Walton <noloader@gmail.com> - 2023-03-02 00:00 +0100
      Re: solution to / full Felix Miata <mrmazda@earthlink.net> - 2023-03-02 00:10 +0100
      Re: solution to / full Greg Wooledge <greg@wooledge.org> - 2023-03-02 00:20 +0100
        Re: solution to / full <tomas@tuxteam.de> - 2023-03-02 06:50 +0100
          Re: solution to / full lina <lina.lastname@gmail.com> - 2023-03-02 09:50 +0100
            Re: solution to / full lina <lina.lastname@gmail.com> - 2023-03-02 10:00 +0100
              Re: solution to / full <tomas@tuxteam.de> - 2023-03-02 10:20 +0100
      Re: solution to / full David Christensen <dpchrist@holgerdanske.com> - 2023-03-02 23:50 +0100
      Re: solution to / full David Christensen <dpchrist@holgerdanske.com> - 2023-03-02 23:50 +0100
        Re: solution to / full Felix Miata <mrmazda@earthlink.net> - 2023-03-03 00:20 +0100
          Re: solution to / full David Christensen <dpchrist@holgerdanske.com> - 2023-03-03 01:20 +0100

Page 1 of 3  [1] 2 3  Next page →

#255451 — solution to / full

[Multipart message — attachments visible in raw view] — view raw

Hi,

My / is almost full.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            126G     0  126G   0% /dev
tmpfs            26G  2.3M   26G   1% /run
/dev/nvme0n1p2   23G   21G  966M  96% /
tmpfs           126G   15M  126G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/nvme0n1p6  267M   83M  166M  34% /boot
/dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
/dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
/dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
/dev/nvme0n1p7  630G  116G  482G  20% /home

# ncdu -x
--- /
--------------------------------------------------------------------------
   17.4 GiB [##########] /usr

    3.2 GiB [#         ] /opt
   16.5 MiB [          ] /etc
    7.3 MiB [          ] /root

What is the best solution so far?

I have done some purging already.
:/usr# du -sh *
742M bin
4.0K games
260M include
8.1G lib
36M lib32
4.0K lib64
140M libexec
33M libx32
3.4G local
53M sbin
4.6G share
215M src


Thanks,

[toc] | [next] | [standalone]

#255452

[Multipart message — attachments visible in raw view] — view raw

lina:
> 
> My / is almost full.
> 
> # df -h
> Filesystem      Size  Used Avail Use% Mounted on
> udev            126G     0  126G   0% /dev
> tmpfs            26G  2.3M   26G   1% /run
> /dev/nvme0n1p2   23G   21G  966M  96% /
> tmpfs           126G   15M  126G   1% /dev/shm
> tmpfs           5.0M  4.0K  5.0M   1% /run/lock
> /dev/nvme0n1p6  267M   83M  166M  34% /boot
> /dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
> /dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
> /dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
> /dev/nvme0n1p7  630G  116G  482G  20% /home

This is a good example why it often makes sense to use LVM even on a
private system. With LVM you could have allocated only 20% of space
where you actually need it and resize filesystems on-demand (and
online). But that does not help you now, sorry.

> I have done some purging already.
> :/usr# du -sh *
> 742M bin
> 4.0K games
> 260M include
> 8.1G lib
> 36M lib32
> 4.0K lib64
> 140M libexec
> 33M libx32
> 3.4G local
> 53M sbin
> 4.6G share
> 215M src

/usr/local might be worth a look. You probably have some stuff there
that you put in manually.

The program dpigs from the package debian-goodies can help you find the
biggest debian packages you have installed. Of course you need to check
yourself whether you need them.

J.
-- 
I frequently find myself at the top of the stairs with absolutely
nothing happening in my brain.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

[toc] | [prev] | [next] | [standalone]

#255456

[Multipart message — attachments visible in raw view] — view raw

On 2023-03-01 at 09:15, Jochen Spieker wrote:

> lina:
> 
>> My / is almost full.
>> 
>> # df -h
>> Filesystem      Size  Used Avail Use% Mounted on
>> udev            126G     0  126G   0% /dev
>> tmpfs            26G  2.3M   26G   1% /run
>> /dev/nvme0n1p2   23G   21G  966M  96% /
>> tmpfs           126G   15M  126G   1% /dev/shm
>> tmpfs           5.0M  4.0K  5.0M   1% /run/lock
>> /dev/nvme0n1p6  267M   83M  166M  34% /boot
>> /dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
>> /dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
>> /dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
>> /dev/nvme0n1p7  630G  116G  482G  20% /home
> 
> This is a good example why it often makes sense to use LVM even on a
> private system. With LVM you could have allocated only 20% of space
> where you actually need it and resize filesystems on-demand (and
> online). But that does not help you now, sorry.
> 
>> I have done some purging already.
>> :/usr# du -sh *
>> 742M bin
>> 4.0K games
>> 260M include
>> 8.1G lib
>> 36M lib32
>> 4.0K lib64
>> 140M libexec
>> 33M libx32
>> 3.4G local
>> 53M sbin
>> 4.6G share
>> 215M src
> 
> /usr/local might be worth a look. You probably have some stuff there
> that you put in manually.
> 
> The program dpigs from the package debian-goodies can help you find the
> biggest debian packages you have installed. Of course you need to check
> yourself whether you need them.

It might also be worth having a look at the output of

# du -hx --max=1 /

rather than just looking at /usr alone. The '-x' will mean it won't
cross the boundaries into the other filesystems, so you'll still just be
looking at what's on / ; '--max=1' means it'll report one directory
level deep from the items you specified on the command line ('--max=0'
is equivalent to '-s').

You might even find benefit from repeating that same command with /usr,
or with any other directory that specifically looks to be bigger than
expected, to find out what part of it is taking up so much of the space.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#255498

On Wed, Mar 01, 2023 at 03:15:07PM +0100, Jochen Spieker wrote:
>The program dpigs from the package debian-goodies can help you find the
>biggest debian packages you have installed. Of course you need to check
>yourself whether you need them.

It's a shame that this requires installing debian-goodies (and
associated transitive dependencies), which can be a problem when the
root filesystem is full or nearly so.

A while ago I (privately) re-wrote dpigs in standard tools for this
reason (mostly for operating inside small containers). Once I got to
feature parity I was going to submit a wishlist bug to split it out from
debian-goodies, but the last feature was awkward to implement and I
never finished it.

Anyway, for OP's purpose, what I have is good enough. Presented in case
it's useful:

--✂--✂--✂--✂--✂--✂--✂--✂--✂--✂ --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂--

STATUS_FILE=/var/lib/dpkg/status
dpigs()
{
     TL=${1-10}
     awk -v RS='' '/Status:.*installed\n/' "$STATUS_FILE" \
         | grep -E '^(Installed-Size|Package)' \
         | cut -d: -f2- \
         | paste - -  \
         | sort -rnk2 \
         | awk '{ print $2 "\t" $1 }' \
         | head -n "$TL" \
         | tac
}
dpigs "$@"

--✂--✂--✂--✂--✂--✂--✂--✂--✂--✂ --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂--

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#255500

On Thu, Mar 02, 2023 at 09:45:38AM +0000, Jonathan Dowland wrote:
> --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂ --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂--
> 
> STATUS_FILE=/var/lib/dpkg/status
> dpigs()
> {
>     TL=${1-10}
>     awk -v RS='' '/Status:.*installed\n/' "$STATUS_FILE" \
>         | grep -E '^(Installed-Size|Package)' \
>         | cut -d: -f2- \
>         | paste - -  \
>         | sort -rnk2 \
>         | awk '{ print $2 "\t" $1 }' \
>         | head -n "$TL" \
>         | tac
> }
> dpigs "$@"
> 
> --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂ --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂--

I don't understand why you used sort -r, but then reversed it again with
tac at the end.  You could drop both of the reversals, and just change
head to tail.

Anyway... I wrote mine in perl, quite a few years ago (timestamp says
September 2004).  There's a copy at <https://wooledge.org/~greg/ds>.
I named it before I even knew that "dpigs" existed.  I can't blame past
me for not knowing... dpigs is extremely well hidden.

[toc] | [prev] | [next] | [standalone]

#255505

On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
>I don't understand why you used sort -r, but then reversed it again with
>tac at the end.  You could drop both of the reversals, and just change
>head to tail.

The short answer is because I wrote all but the last "tac" several years
ago, and added the last "tac" in writing the mail, when I realised the
output was the other way around to how I'd prefer.

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#255550

On 2023-03-02, Jonathan Dowland <jon+debian-user@dow.land> wrote:
> On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
>>I don't understand why you used sort -r, but then reversed it again with
>>tac at the end.  You could drop both of the reversals, and just change
>>head to tail.
>
> The short answer is because I wrote all but the last "tac" several years
> ago, and added the last "tac" in writing the mail, when I realised the
> output was the other way around to how I'd prefer.

You'd think you'd want the biggest pigs listed first.

But I haven't been following.


-- 

[toc] | [prev] | [next] | [standalone]

#255559

On Fri, 3 Mar 2023 Curt wrote:
> On 2023-03-02, Jonathan Dowland <jon+debian-user@dow.land> wrote:
>> On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
>>> I don't understand why you used sort -r, but then reversed it again with
>>> tac at the end.  You could drop both of the reversals, and just change
>>> head to tail.
>>
>> The short answer is because I wrote all but the last "tac" several years
>> ago, and added the last "tac" in writing the mail, when I realised the
>> output was the other way around to how I'd prefer.
>
> You'd think you'd want the biggest pigs listed first.

Yeah, it makes no sense backwards

Home
All the way
This little pig went wee wee wee
This little pig had none
This little pig had roast beef
This little pig stayed home
This little pig went to market

> But I haven't been following.
>
>
>

-- 
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

[toc] | [prev] | [next] | [standalone]

#255589

On Fri 03 Mar 2023 at 15:42:37 (-0000), Curt wrote:
> On 2023-03-02, Jonathan Dowland <jon+debian-user@dow.land> wrote:
> > On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
> >>I don't understand why you used sort -r, but then reversed it again with
> >>tac at the end.  You could drop both of the reversals, and just change
> >>head to tail.
> >
> > The short answer is because I wrote all but the last "tac" several years
> > ago, and added the last "tac" in writing the mail, when I realised the
> > output was the other way around to how I'd prefer.
> 
> You'd think you'd want the biggest pigs listed first.

But then when there's a drove, the biggest go AWOL
off the top of screen.

> But I haven't been following.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#255652

On Sat, Mar 04, 2023 at 11:10:48AM -0600, David Wright wrote:
>But then when there's a drove, the biggest go AWOL
>off the top of screen.

Quite. I habitually alias ls to 'ls -lhrt', (and  cdls() { cd "$@" && ls
-lhrt; }; alias cd=cdls) so I'm very used to only looking at the bottom
of a long list of size-sorted-ascending. But I think it's a matter of
taste.

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#255658

On Mon, Mar 06, 2023 at 10:41:22AM +0000, Jonathan Dowland wrote:
>Quite. I habitually alias ls to 'ls -lhrt', (and  cdls() { cd "$@" && ls
>-lhrt; }; alias cd=cdls) so I'm very used to only looking at the bottom
>of a long list of size-sorted-ascending.

Err, of course, that's date-sort-ascending, not size. But I hope the
point I was making got through regardless.

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#255453

lina wrote:
> Filesystem      Size  Used Avail Use% Mounted on
[...]
> /dev/nvme0n1p2   23G   21G  966M  96% /
> /dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
> /dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
> /dev/nvme0n1p7  630G  116G  482G  20% /home

[...]
> I have done some purging already.
> :/usr# du -sh *
[...]
> 742M bin
> 8.1G lib
> 3.4G local

Perhaps it might be a solution to
- move your /usr/local to /home  (do as root: mv /usr/local /home)
- create a symlink from /home/local to /usr/local (do as root: ln -s /home/local /usr/)

I can't recommend this to do it with /usr/*bin oder with any /usr/*lib* directories, as booting might not work anymore, or at least not properply.

I can't say for sure that my solution has no impact on starting services in your system, as the risk exists, that starting some services from /usr/local might happen before mounting /home at system start.

And as a final word: even this/my suggestion might not work forever, as your / partition is really small (btw, your /tmp either). I would suggest to buy and install a second 500 Gb disk (don't do that much segmentation on the disk and use LVMs) and work on that disk instead. You might use the current disk later as backup space, or for a raid-1.

Best regards,
	Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

[toc] | [prev] | [next] | [standalone]

#255454

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:
> Hi,
> 
> My / is almost full.
> 
> # df -h
> Filesystem      Size  Used Avail Use% Mounted on
> udev            126G     0  126G   0% /dev
> tmpfs            26G  2.3M   26G   1% /run
> /dev/nvme0n1p2   23G   21G  966M  96% /
> tmpfs           126G   15M  126G   1% /dev/shm
> tmpfs           5.0M  4.0K  5.0M   1% /run/lock
> /dev/nvme0n1p6  267M   83M  166M  34% /boot
> /dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
> /dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
> /dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
> /dev/nvme0n1p7  630G  116G  482G  20% /home
> 
> # ncdu -x
> --- /
> --------------------------------------------------------------------------
>    17.4 GiB [##########] /usr
> 
>     3.2 GiB [#         ] /opt
>    16.5 MiB [          ] /etc
>     7.3 MiB [          ] /root
> 
> What is the best solution so far?
> 
> I have done some purging already.
> :/usr# du -sh *
> 742M bin
> 4.0K games
> 260M include
> 8.1G lib
> 36M lib32
> 4.0K lib64
> 140M libexec
> 33M libx32
> 3.4G local
> 53M sbin
> 4.6G share
> 215M src

The one which sticks out a bit is /lib, but not outrageously so.
My /usr/lib is 4.1G.

You just might need a bigger disk?

In a pinch, you can "sudo apt-get clean", which purges the APT
package cache, which lives in /var. You didn't show us /var,
which might be interesting too (/var/log, in case some logs
aren't rotated properly?)

Cheers
-- 
t
> 
> 
> Thanks,

[toc] | [prev] | [next] | [standalone]

#255461

On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:

[...]

> In a pinch, you can "sudo apt-get clean", which purges the APT
> package cache, which lives in /var. You didn't show us /var,
> which might be interesting too (/var/log, in case some logs
> aren't rotated properly?)

There should not be any actual packages in /var/cache/apt.
Cleaning out pkgcache.bin and srcpkgcache.bin is not really
of permanment value as they reappear after 'apt update'.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#255462

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote:
> On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:
> 
> [...]
> 
> > In a pinch, you can "sudo apt-get clean", which purges the APT
> > package cache, which lives in /var. You didn't show us /var,
> > which might be interesting too (/var/log, in case some logs
> > aren't rotated properly?)
> 
> There should not be any actual packages in /var/cache/apt.
> Cleaning out pkgcache.bin and srcpkgcache.bin is not really
> of permanment value as they reappear after 'apt update'.

Doh. Forget my post anyway. I've had a better look at the mount
table now.

Sorry for the noise
-- 
t

[toc] | [prev] | [next] | [standalone]

#255473

On Wed 01 Mar 2023 at 19:37:10 +0100, tomas@tuxteam.de wrote:

> On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:
> > 
> > [...]
> > 
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which lives in /var. You didn't show us /var,
> > > which might be interesting too (/var/log, in case some logs
> > > aren't rotated properly?)
> > 
> > There should not be any actual packages in /var/cache/apt.
> > Cleaning out pkgcache.bin and srcpkgcache.bin is not really
> > of permanment value as they reappear after 'apt update'.
> 
> Doh. Forget my post anyway. I've had a better look at the mount
> table now.
> 
> Sorry for the noise

No problem. I've been caught out by this regeneration on a
space-constrained system in the past.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#255463

On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote:
> On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:
> 
> [...]
> 
> > In a pinch, you can "sudo apt-get clean", which purges the APT
> > package cache, which lives in /var. You didn't show us /var,
> > which might be interesting too (/var/log, in case some logs
> > aren't rotated properly?)
> 
> There should not be any actual packages in /var/cache/apt.

This depends on whether one uses "apt" or "apt-get" or some other
program to install packages.  By default, "apt" removes the .deb files
from /var/cache/apt/archives/ after installing them, but "apt-get"
does not.  For other programs, who knows.

[toc] | [prev] | [next] | [standalone]

#255470

On Wed, 1 Mar 2023 13:33:32 -0500
Greg Wooledge <greg@wooledge.org> wrote:

> On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:
> > 
> > [...]
> >   
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which lives in /var. You didn't show us /var,
> > > which might be interesting too (/var/log, in case some logs
> > > aren't rotated properly?)  
> > 
> > There should not be any actual packages in /var/cache/apt.  
> 
> This depends on whether one uses "apt" or "apt-get" or some other
> program to install packages.  By default, "apt" removes the .deb files
> from /var/cache/apt/archives/ after installing them, but "apt-get"
> does not.  For other programs, who knows.
> 

I've just asked about this but forgot to mention that I use apt, I'll
only use apt-get if a version upgrade recommends it. As I said, I have a
fairly well-used archives directory. I do recall, when apt became a
thing, reading what you posted there about apt removing the debs. There
must be a configuration which prevents that.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#255471

On Wed, Mar 01, 2023 at 07:53:34PM +0000, Joe wrote:
> On Wed, 1 Mar 2023 13:33:32 -0500
> Greg Wooledge <greg@wooledge.org> wrote:
> > By default, "apt" removes the .deb files
> > from /var/cache/apt/archives/ after installing them, but "apt-get"
> > does not.  For other programs, who knows.
> 
> I've just asked about this but forgot to mention that I use apt, I'll
> only use apt-get if a version upgrade recommends it. As I said, I have a
> fairly well-used archives directory. I do recall, when apt became a
> thing, reading what you posted there about apt removing the debs. There
> must be a configuration which prevents that.

Indeed.  That's why I said "by default".

unicorn:~$ apt-config dump | grep Keep
Binary::apt::APT::Keep-Downloaded-Packages "0";

You probably created or modified some file under /etc/apt/apt.conf.d/
which changes the default behavior.

[toc] | [prev] | [next] | [standalone]

#255474

On Wed 01 Mar 2023 at 13:33:32 -0500, Greg Wooledge wrote:

> On Wed, Mar 01, 2023 at 06:12:09PM +0000, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, tomas@tuxteam.de wrote:
> > 
> > [...]
> > 
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which lives in /var. You didn't show us /var,
> > > which might be interesting too (/var/log, in case some logs
> > > aren't rotated properly?)
> > 
> > There should not be any actual packages in /var/cache/apt.
> 
> This depends on whether one uses "apt" or "apt-get" or some other
> program to install packages.  By default, "apt" removes the .deb files
> from /var/cache/apt/archives/ after installing them, but "apt-get"
> does not.  For other programs, who knows.

Of course it depends. I assumed a default usage usage of
package management. It's been around long enough.

-- 
Brian. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web