Re: Problem with /var/cache/apt/archives/
On 12/16/23, Pocket <pocket@columbus.rr.com> wrote:
>
> 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|
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*
Reply to: