Problem with /var/cache/apt/archives/

[Stephen P. Molnar]

I am running Bookworm on my Debian computer. When I installed the OS I
selected the option for separate /var etc, and selected the default
sizes of the partitions.

When I ran sudo apt update this morning I received the error message:

E: You don't have enough free space in /var/cache/apt/archives/

Can I increase the size of the /var partition on the ssd without having
to reinstall the system?

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype: smolnar1

[Greg Wooledge]

On Sat, Dec 16, 2023 at 08:45:41AM -0500, Stephen P. Molnar wrote:
> I am running Bookworm on my Debian computer. When I installed the OS I
> selected the option for separate /var etc, and selected the default sizes of
> the partitions.

How many disks are there? *How* did you partition them? Are you using
raw partitions under GPT or DOS partition tables? Are you using LVM?
RAID? Encryption?

> When I ran sudo apt update this morning I received the error message:
>
> E: You don't have enough free space in /var/cache/apt/archives/
>
> Can I increase the size of the /var partition on the ssd without having to
> reinstall the system?

If you used LVM and left a bunch of the disk unassigned, then you simply
assign some more space to the corresponding LV.

If there's any free space left over that you *didn't* assign to a
partition, you could create a separate /var/cache/apt file system and
mount that on top of /var. If not, then you'd need to steal some space
from another partition.

Or, perhaps, you just need to delete some old files from
/var/cache/apt/archives. How big *is* your /var partition? How much
space is currently used by /var/cache/apt? What's your retention policy
for the .deb files?

[john doe]

On 12/16/23 14:45, Stephen P. Molnar wrote:
> I am running Bookworm on my Debian computer. When I installed the OS I
> selected the option for separate /var etc, and selected the default
> sizes of the partitions.
>
> When I ran sudo apt update this morning I received the error message:
>
> E: You don't have enough free space in /var/cache/apt/archives/
>
> Can I increase the size of the /var partition on the ssd without having
> to reinstall the system?
>

LVM is one way to avoid this! ;^)

--
John Doe

[Joe Pfeiffer]

"Stephen P. Molnar" <s.mo...@sbcglobal.net> writes:

> I am running Bookworm on my Debian computer. When I installed the OS I
> selected the option for separate /var etc, and selected the default
> sizes of the partitions.
>
> When I ran sudo apt update this morning I received the error message:
>
> E: You don't have enough free space in /var/cache/apt/archives/
>
> Can I increase the size of the /var partition on the ssd without
> having to reinstall the system?
>
> Thanks in advance.

Are you doing anything to get rid of unused packages? If not the
archives just keep growing. An occasional

# apt-get autoclean

will do a lot for you.

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

autoclean (and the auto-clean alias since 1.1)
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.

[Felix Miata]

Stephen P. Molnar composed on 2023-12-16 08:45 (UTC-0500):

> I am running Bookworm on my Debian computer. When I installed the OS I
> selected the option for separate /var etc, and selected the default
> sizes of the partitions.

Separate filesystem for /var/ is a pointless complication for most installations.
I make /home/ separate, and the ESP as it must be, but keep the OS itself on one
filesystem.

> When I ran sudo apt update this morning I received the error message:

> E: You don't have enough free space in /var/cache/apt/archives/

> Can I increase the size of the /var partition on the ssd without having
> to reinstall the system?

If your /var/ is adjacent to your /, you might boot something else, delete the
/var/ and its fstab entry, and add its space to /. The better question is why you
don't have enough space. You may have made /var/ too small, but I'm guessing it's
full of .deb files you don't need. 'Apt clean' would quickly and easily take care
of the latter problem, as implied by the tail of Greg's response.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[Andy Smith]

Hello,

On Sat, Dec 16, 2023 at 03:03:38PM +0100, john doe wrote:
> On 12/16/23 14:45, Stephen P. Molnar wrote:
> > When I installed the OS I selected the option for separate /var
> > etc, and selected the default sizes of the partitions.

[…]

> > Can I increase the size of the /var partition on the ssd without
> > having to reinstall the system?
>
> LVM is one way to avoid this! ;^)

I really think that the partitioning section of the installer should
warn people in strong terms that creating multiple partitions to
directly use as filesystems is something they need to be sure they
want, and that if they're looking for flexible layout they should
use LVM or btrfs.

It's quite common to see here requests for help from non-experts who
heard that splitting their OS over multiple partitions was a good
idea, but sized them in a way that didn't stand the test of time —
including trusting that the suggested values will suffice.

It is hard to correctly make such decisions and most of the time
either a single partition or logical volume management is a better
idea.

The OP is potentially in for quite a lot of work to sort this out,
where a mistake can result in having to reinstall.

Thanks.
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Stephen P. Molnar]

Many thanks for the replies.

I'll add 'sudo apt-get autoclean to' my update bat file.

[Pocket]

On 12/16/23 08:45, Stephen P. Molnar wrote:

I am running Bookworm on my Debian computer. When I installed the OS I selected the option for separate /var etc, and selected the default sizes of the partitions.

When I ran sudo apt update this morning I received the error message:

E: You don't have enough free space in /var/cache/apt/archives/

Can I increase the size of the /var partition on the ssd without having to reinstall the system?

Thanks in advance.

You can bind mount more space from another partition or create a directory on another file system and sylmink it to /var/cache/apt/archives/

Maybe something like this

On a volume that has sufficient space

where <path> is some where on your filesystem

mkdir <path>/archives

cp -var /var/cache/apt/archives/ <path>/archives/

or

mv -v  /var/cache/apt/archives/ <path>/archives/

then clean up /var/cache/apt/archives
rm -rf /var/cache/apt/archives

ln -vs <path>/archives /var/cache/apt/archives

or 

mount --bind <path>/archives /var/cache/apt/archives

Add the bind mount to the end of /etc/fstab 

/var/cache/apt/archives <path>/archives none bind,nofail


https://www.baeldung.com/linux/bind-mounts


-- 
Hindi madali ang maging ako

[Charles Curley]

On Sat, 16 Dec 2023 10:46:27 -0500
"Stephen P. Molnar" <s.mo...@sbcglobal.net> wrote:

> I'll add 'sudo apt-get autoclean to' my update bat file.

Or add it to your crontab.

root@tsalmoth:~# grep clean /etc/cron.d/curley
0 4 18 * * root apt-get -y autoclean
root@tsalmoth:~#

--
Does anybody read signatures any more?

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

[to...@tuxteam.de]

On Sat, Dec 16, 2023 at 10:46:27AM -0500, Stephen P. Molnar wrote:
> Many thanks for the replies.
>
> I'll add 'sudo apt-get autoclean to' my update bat file.

Bat? 🦇

Cheers
--
t

[Charles Curley]

On Sat, 16 Dec 2023 20:30:27 +0100
<to...@tuxteam.de> wrote:

> > I'll add 'sudo apt-get autoclean to' my update bat file.
>
> Bat? 🦇

Yeah, bat file. That's what one uses to smooth the body putty on one's
custom batmobile.

[Joe Pfeiffer]

Charles Curley <charle...@charlescurley.com> writes:

> Does anybody read signatures any more?

I certainly don't.

[Max Nikulin]

On 16/12/2023 22:46, Stephen P. Molnar wrote:
>
> I'll add 'sudo apt-get autoclean to' my update bat file.

I have

APT::Keep-Downloaded-Packages "false";

in a file inside "/etc/apt/apt.conf.d/". However I use apt-cacher-ng. In
you case this settings may be excessively aggressive.

[Curt]

On 2023-12-17, Max Nikulin <mani...@gmail.com> wrote:
> On 16/12/2023 22:46, Stephen P. Molnar wrote:
>>
>> I'll add 'sudo apt-get autoclean to' my update bat file.
>
> I have
>
> APT::Keep-Downloaded-Packages "false";

I thought that was the default now for apt. But then he said "sudo apt" in the
OP and "apt-get" in the post you're responding to.

Anyway.

> in a file inside "/etc/apt/apt.conf.d/". However I use apt-cacher-ng. In
> you case this settings may be excessively aggressive.
>
>

--

[Cindy Sue Causey]

tl;dr I've stuck with this a couple hours now purely k/t less than
optimal brain functioning. I've been comparing symlink versus "mount
-B" on apt/archives during debootstraps because I've had bad fails in
the past. Ultimately, it finally boiled down to debootstrap(dot)log
documenting:

dpkg-deb: error: failed to read archive
'/var/cache/apt/archives/dpkg_1.22.1_amd64.deb': Too many levels of
symbolic links
dpkg: error: parsing file '/var/lib/dpkg/status' near line 2 package 'dpkg':
'Version' field value '': version string is empty

Too many levels of symbolic links... I've seen that over the years
while breaking my system. So I visually inspected the apt/archives
directory. Whatever debootstrap is seeing as too many symlinks is not
visually apparent.

In the past, I've seen directories present an infinitum linear path if
you keep clicking that same named directory each time you open the
next one. That is not the case today.

I've debootstrapped a few times today. The various failed logs changed
slightly. Diff showed that several /bin packages are missing (see
further below if bored). Cpio is one. One log but not all show a weird
problem that looks like something inserted an extra "/" in front of
debootstrap's /var directory during download (which implies a symlink
tie-in):

2023-12-17 18:02:24
URL:http://http.us.debian.org/debian/pool/main/c/cpio/cpio_2.13+dfsg-7.1_amd64.deb
[245036/245036] ->
"/home/candycane/deboot-apt-symlink//var/cache/apt/archives/partial/cpio_2.13+dfsg-7.1_amd64.deb"
[1]

That same (error or no?) reference does not occur in all
debootstrap(dot)log files across the multiple debootstraps that were
run using symlink instead of "mount -B" today.

All of that now melds in with the rest of my original email which is............

Apologies, I didn't know where to cull above, grin. A couple years
ago, I posted on Debian-User that I tripped over a BAD problem when
only symlinking apt/archives for my debootstraps. I just super quick
ran two comparative debootstraps, and the same issue still stands.

$ sudo LANG=C.UTF-8 chroot deboot-apt-symlink /bin/bash
I have no name!@northpole:/#

$ sudo LANG=C.UTF-8 chroot deboot-apt-mount-bind /bin/bash
root@northpole:/#

The "mount -B" debootstrap ends short and sweet with:

I: Base system installed successfully.

Go, Team!

The symlink version lost its mind this time. It used to say something
very different and much shorter. The previous concluding message was
so short that I missed it multiple times over and just assumed the
debootstraps were successfully completing as expected. Nope.

Today's (terminal CLI) message popped big time:

W: Failure trying to run: chroot "/home/candycane/deboot-apt-symlink"
dpkg-deb -f /var/cache/apt/archives/dpkg_1.22.1_amd64.deb Version
W: See /home/candycane/deboot-apt-symlink/debootstrap/debootstrap.log
for details
I: Installing core packages...
W: Failure trying to run: chroot "/home/candycane/deboot-apt-symlink"
dpkg --force-depends --install
/var/cache/apt/archives/base-passwd_3.6.3_amd64.deb
W: See /home/candycane/deboot-apt-symlink/debootstrap/debootstrap.log
for details

DISCLAIMER: Yes, that's referencing chroot, but that is NOT me
chrooting in. That's debootstrap running through the last lines of its
to-do list. When I chroot in afterward, I only see the first lines I
typed further above (e.g. "I have no name!").

With respect to deciphering what happens, I just thought to run "diff"
on the two different debootstrap directories from today. Nothing's
been done to those directories. It's only the initial download and
install step. A LOT of feedback came back for that diff command.

Top of the diff query results showed a sizable list of "only in" the
"mount -B" debootstrap's /bin. So I compared total sizes: 239.3MB for
deboot-apt-mount-bind and 160.6MB for the symlinked instance. That is
a lot of missing data (content) for the symlink instance. I expected
to see some differences but not that much.

That's all I've got on it. I've never attempted to dig deep into the
"why" of what happens. I simply write off symlink as being somehow
more of a "surface" function, less structured than "mount -B".

My recommendation from the standpoint of a 20-year+ long "perennial
newbie brained" user is.... "mount -B" wherever possible and
appropriate solely because of the HUGE difference in the outcomes of
my two different debootstraps today. Who knows what else that might be
silently affecting elsewhere in our systems.

To that end, a new checkpoint for users who complain about odd,
unsolvable problems: Do you have anything *significant* symlinked
anywhere in the immediately involved directories?

I hope all of that makes sense, especially in a logical manner. My
brain is "sundowning" again ("running out of words"), but I wanted to
get this out there because it causes a big fail with debootstraps AND
specifically involves the directory named in this thread's subject.

NOTABLE: This has been occurring for "several" years. A quick search
of my inbox shows I posted about it here on Debian-User at least going
back to 2017.02.12.

How I ever found out was an accident, was a pure blessing of the luck
of my brain capably functioning one day while fumbling around with
mount binding something unrelated. I was encountering discrepancies in
what data would present while mount binding. The experience of
debootstrap emphatically complaining "I have no name!" eventually came
to mind that day, and here we are now........... :)

Cindy :)
--
Talking Rock, Pickens County, Georgia, USA
* still running with that Linux LiveDVD wishlist as Happy New Year's
Resolution #1*

[Greg Wooledge]

On Sun, Dec 17, 2023 at 09:42:19PM -0500, Cindy Sue Causey wrote:
> dpkg-deb: error: failed to read archive
> '/var/cache/apt/archives/dpkg_1.22.1_amd64.deb': Too many levels of
> symbolic links
> dpkg: error: parsing file '/var/lib/dpkg/status' near line 2 package 'dpkg':
> 'Version' field value '': version string is empty
>
> Too many levels of symbolic links... I've seen that over the years
> while breaking my system. So I visually inspected the apt/archives
> directory. Whatever debootstrap is seeing as too many symlinks is not
> visually apparent.

Well, why not *show us*?

Here's one way to produce that error message:

unicorn:~$ mkdir /tmp/subdir
unicorn:~$ ln -s link /tmp/subdir/link
unicorn:~$ ls /tmp/subdir/link/foo
ls: cannot access '/tmp/subdir/link/foo': Too many levels of symbolic links
unicorn:~$ ls -ld /tmp/subdir/link
lrwxrwxrwx 1 greg greg 4 Dec 17 22:00 /tmp/subdir/link -> link

For your error message, you'd want to look at

ls -ld /var /var/cache /var/cache/apt /var/cache/apt/archives

I think we can assume that / isn't a circular symlink, but if you want
to throw in / as well, it wouldn't hurt.

You mentioned debootstrap, so it's not clear to me whether the error
is coming from your regular directories, or from a /var/cache/apt/archives
that's inside a chroot somewhere. If it's coming from a chroot, then
that's where you'll want to look.