Re: Is apt-get dist-upgrade worth the hassle?
On Sun 01 Jul 2018 at 19:04:31 (-0400), The Wanderer wrote:
> On 2018-07-01 at 18:43, David Wright wrote:
>
> > On Sun 01 Jul 2018 at 13:17:47 (-0700), Charlie Gibbs wrote:
> >
> >> I've been banging my head against the wall trying to compile
> >> OpenSSL clients on my Jessie laptop (see my recent posting titled
> >> "Can't link to OpenSSL on my laptop). I've decided to upgrade it
> >> to Stretch like my desktop machine, which compiles these programs
> >> successfully. However, "sudo apt-get dist-upgrade" shows the
> >> message:
> >>
> >> E: You don't have enough free space in /var/cache/apt/archives/.
> >>
> >> apt-get autoclean doesn't help; neither does apt-get clean. When
> >> I tried apt-get autoremove, the upgrade started, but at 99%
> >> completion it threw the message:
> >>
> >> Error writing to output file - write (28: No space left on device)
> >>
> >> Sure enough, / is full, with all the fun that that entails.
> >
> > It's worth knowing where the problem lies. I would type
> >
> > du -sh /[a-ln-z]*/ 2>/dev/null
> >
> > (I dodge m because /media has loads mounted under it; null avoids
> > permissions clutter if you do this as a user.)
>
> Is there a reason you don't add '-x' to that, to skip recursing into
> other filesystems? (Which would also avoid the need to omit /media.)
Habit. Slap my wrist, but I mount partitions on the internal disk
onto mountpoints in / (rather than /media), and I'm usually interested
in their usage as much as the rest. Also on my slowest two machines,
I would omit /usr (even though it's not hived off: but I can't do
anything about its size) as it takes too long to traverse it.
Yes, for this use case, a more considered commandline might be
du -hxd 1 /var 2>/dev/null
(And it's habitual for me to do it as a user, but the OP probably
wants accuracy and should run it as root.) BTW I don't think -x
works if you're selecting directories by globbing as I do.
> >> Is Jessie's default partitioning insufficient for Stretch, or have
> >> I somehow filled up / with extraneous junk? Would I be better off
> >> backing up /home, wiping the disk (e.g. with cfdisk) and starting
> >> from scratch? (Probably - I should probably split /var into a
> >> separate partition anyway.)
> >
> > A separate /home is more useful as it allows a fresh installation of
> > the / partition that doesn't touch it.
>
> I generally do one partition each for /, /boot, /tmp, /home, and /var -
> and formerly also /usr, but I understand that that's not supported
> anymore. I sometimes also do one for /opt, depending on what I expect to
> do with the system.
I need to justify each one to myself before I'll add to the admin
burden by making unnecessary splits¹. In turn:
/home is a no-brainer. All my machines have two Debian systems sharing
their home partition. Usually the two systems are different codenames.
/boot is "essential" if you encrypt the system. I have only ever
encrypted /home (beyond a trial), so I've no need.
/tmp In the years when I had long uptimes (~400d was my maximum),
this was of more importance. If / fills interactively, I know almost
straight away (I get a false overheat alarm) so I just clean it up.
/var Similar. The proportion of / taken up by logs is trivial now
compared with running DOS and linux on a 2GB disk. But it makes
good sense for a long-running server, as with /tmp. I shut down
all my machines at bedtime. Currently my server might be running
in a room at 90-100°F (we had 106°F outside last Thursday).
> I've only filled up / once, on one system, so far as I recall - and it
> was in fact due to /var/cache/apt/archives.
The first time I login to a machine after rebooting, my startup files
print a massaged df ; df -i and nag me if I haven't checked the
disk for over three weeks. As for /var/cache/apt/archives, I push
that problem onto my server by running apt-cacher-ng. On one or
two occasions, I ran into problems there because the version running
was too old for new-fangled files from apt-get update (which screws
its expiration run). This made /var/cache/apt-cacher-ng/ grow and
grow (slowly). Currently it's at 13GB.
¹ I know, others might use LVM.
Cheers,
David.
Reply to: