[svlug] Debian upgrade (was Debian Upgrade 7.8)

Rick Moen rick at svlug.org
Fri Jan 16 12:27:57 PST 2015


Subject header revised because I'm increasingly doubting this has anything
whatsoever to do with the point release.

Scott DuBois wrote:

> Nah, the only separate partition is /home.

Above implies that /root is NOT a separate filesystem, which would mean that
you, Scott, misdescribed the problem.  (In the prior post, you said
'However, I now have this /root fill condition I need to work with.') 

Confusion almost invariably follows from that misdescribing the problem.  I
co-wrote an essay with some relevance, and can point to a section I have in
mind, detailing how to avoid that ever happening.  (Dunno how it will read
to you - the coauthors' differences in writing styles are night and day to
me - but, FWIW, this part is very much _my_ style, tone, and diction[1]:)

http://catb.org/~esr/faqs/smart-questions.html#symptoms

   Describe the Problem's Symptoms, Not Your Guesses

   It's not useful to tell hackers what you think is causing your problem.
   (If your diagnostic theories were such hot stuff, would you be consulting
   others for help?)  So, make sure you're telling them the raw symptoms of
   what goes wrong, rather than your interpretations and theories.  Let them
   do the interpretation and diagnosis.  If you feel it's important to state
   your guess, clearly label it as such and describe why that answer isn't
   working for you.
   [...]

   Since the preceding point seems to be a tough one for many people to
   grasp, here's a phrase to remind you:  "All diagnosticians are from
   Missouri."  That US state's official motto is "Show me" (earned in 1899,
   when Congressman Willard D. Vandiver said "I come from a country that
   raises corn and cotton and cockleburs and Democrats, and frothy eloquence
   neither convinces nor satisfies me.  I'm from Missouri.  You've got to show
   me.")  In diagnosticians' case, it's not a matter of skepticism, but
   rather a literal, functional need to see whatever is as close as possible
   to the same raw evidence that you see, rather than your surmises and
   summaries.  Show us.

OK, enough about that.  Looking further upthread, I see that you indeed
posted _there_ the output of 'df'.  Good.  The higher the percentage of raw
data (e.g., copy and paste from the command line) included in any problem
report, and the less post-event guesswork, the better.



Take Two, this time with feeling.

> rse at linux:~$ df
> Filesystem              1K-blocks      Used  Available Use% Mounted on
> rootfs                    9611492   8882076     241176  98% /
> 
> I would consider taking out GNOME to free up a bunch of space but based on
> what just happened? 

Speaking in the _general_ case, the first thing you must do with a full or
nearly full filesystem is figure out what's causing it.  If it's something
ongoing, like a big bulk copy operation, the next thing is to stop it.

In this case, pretty much the only thing going on was package operations,
right?  So, we can rule out things like you deciding to run all of
SourceForge on your laptop and the Apache logfile therefore exploding.

You gave yourself nine-plus gigs of space to play with.  Yeah, man, that's a
lot of software, I'd say.  Time to do 'zless /var/log/apt/history.log*', to 
see what packages you installed.  Fortunately, you have about 240MB of
headroom without even digging into space reserved to the root user[2], so, 
you should be able to start doing selective 'apt-get remove' operations to
cure the bloat.

If there _was_ something going on other than just package operations, you 
may have some detective work to do.  One of the reasons why you should 
be really careful what you elect to do with root authority is that (absent 
special security regimes not under discussion here) the root user can screw
around with anything and stow troublesome and unwanted junk anywhere.

If you need to find where the bloat is hiding, some use of the 'du' command
and use of this Perl script that finds the largest _individual_ files in a
subtree, will help.  Write this to /tmp/largest20 and do 'chmod u+x
/tmp/largest20'.

-----<script starts below this line>-----
#!/usr/bin/perl -w
# You can alternatively just do:  
# find . -xdev -type f -print0 | xargs -r0 ls -l | sort -rn +4 | head -20
use File::Find;

@ARGV = $ENV{ PWD } unless @ARGV;
find ( sub { $size{ $File::Find::name } = -s if -f; }, @ARGV );
@sorted = sort { $size{ $b } <=> $size{ $a } } keys %size;
splice @sorted, 20 if @sorted > 20;
printf "%10d %s\n", $size{$_}, $_ for @sorted
-----<script ends above this line>-----

The 'find' one-liner doesn't appear to work on modern systems.  Used to
work.  If you have time to spare and want a shell problem to chew on,
there's one for you.



[1] Except Eric's insertion of the reference to 'hackers' is an Eric thing.
We found we'd been writing similar essays, and joined forces rather than
write separately.  His was addressed to 'hackers', and mine wasn't.

[2] http://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why




More information about the svlug mailing list