[svlug] Debian Upgrade 7.8

Rick Moen rick at svlug.org
Fri Jan 16 11:13:36 PST 2015


Scott DuBois wrote:

[apt-get update && apt-get dist-upgrade]

> I do this every couple of days; works great.  So far I'm thrilled so I'm
> not exactly sure what happened last night.  I tried going back through my
> bash history to see if I had executed some command by mistake and found
> nothing.

OK, I'm glad your system didn't get fundamentally broken by whatever
happened.  You might find history.log and term.log in /var/log/apt/ to 
be enlightening in determining what happened.

I guess what confused me in your initial (upthread) posting was your
characterising the situation as 'my first upgrade from 7.7 to 7.8'.  If you
were just every few days doing 'apt-get update && apt-get dist-upgrade' or
equivalent using aptitude[1] or one of the graphical front-ends for package
management, then I'm puzzled about how the existence of a new point-release
(7.8 vs 7.7) even entered the picture at all.  As you'll see if you look at
/etc/debian_version and elsewhere, that numbering isn't part of the
architecture of your system.  It's the point-release designation of a new
set of installation media, and enters the picture only if you're doing a
new, from-scratch installation and want the shiny-latest (by Debian Stable
standards) initial package contents and installation kernel during and
immediately after installation.

One of the characteristic traits of Debian is that, for most purposes, it's
an install-once system.  You do the initial installation, then you continue
to maintain it, going forward, solely by package updates, and the installer
is never relevant again.  The only time you're likely to even notice
_distro_ version changes is -- if tracking Stable -- at the time of full
releases, in which case there's an unusually large flurry of new packages
and some revision of basic archtitecture, but at the end of it you're still
running Stable.  (If the volunteer serving as Debian Release Coordinator has
done his job, the large jump forward at release time will all go smoothly, 
services will briefly stop and restart to implement new versions, and
everything will still be running.)

> However, I now have this /root fill condition I need to work with.

Well, before recommending remedies, it's relevant to ask:  What's now in
there?  And what does 'df -h | grep /root' say, i.e., how big is it?

(I'm assuming you didn't mean '/' when you wrote '/root'.  The former is the
root filesystem.  Having that be full is a more-serious matter than merely
having the root user's home directory full.)

To my knowledge, by default no package operations should ever put anything
into a user's homedir, and that includes /root, the default homedir of the
root user.

> apt-get clean & apt-get autoremove only freed a little space.

Those should not touch /root in any way.

If you mean '/', then say '/' and not '/root', as they are very much not the
same thing.










[1] I note elsewhere in the thread that Ivan likes aptitude, an alternative
to apt-get developed later and at one time intended to be its replacement, 
and providing both command-line functionality and a full-screen ncurses
mode.  Personally, I found aptitude sluggish and its default to installing
Recommends dependencies annoying, but that default can be changed in
/etc/apt/* settings.

The main thing, if considering apt-get vs. aptitude, is that it is best
practices to settle on one or the other but not continue to use both, as
they maintain separate package hinting records of some kind.  (Can't
remember details on that, at the moment.)



More information about the svlug mailing list