Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #197100 > unrolled thread

Is apt-get dist-upgrade worth the hassle?

Back to article view | Back to linux.debian.user

Contents

  Is apt-get dist-upgrade worth the hassle? Charlie Gibbs <cgibbs@surfnaked.ca> - 2018-07-01 22:20 +0200
    Re: Is apt-get dist-upgrade worth the hassle? Dan Ritter <dsr@randomstring.org> - 2018-07-01 23:50 +0200
      Re: Is apt-get dist-upgrade worth the hassle? Carl Fink <carlf@panix.com> - 2018-07-02 00:20 +0200
    Re: Is apt-get dist-upgrade worth the hassle? Felix Miata <mrmazda@earthlink.net> - 2018-07-02 00:00 +0200
    Re: Is apt-get dist-upgrade worth the hassle? David Wright <deblis@lionunicorn.co.uk> - 2018-07-02 00:50 +0200
      Re: Is apt-get dist-upgrade worth the hassle? The Wanderer <wanderer@fastmail.fm> - 2018-07-02 01:10 +0200
        Re: Is apt-get dist-upgrade worth the hassle? David Wright <deblis@lionunicorn.co.uk> - 2018-07-02 03:00 +0200
      Re: Is apt-get dist-upgrade worth the hassle? Joe <joe@jretrading.com> - 2018-07-02 11:20 +0200
        Re: Is apt-get dist-upgrade worth the hassle? Curt <curty@free.fr> - 2018-07-02 12:10 +0200
          Re: Is apt-get dist-upgrade worth the hassle? Joe <joe@jretrading.com> - 2018-07-02 13:00 +0200
        Re: Is apt-get dist-upgrade worth the hassle? David Wright <deblis@lionunicorn.co.uk> - 2018-07-02 20:40 +0200
    Re: Is apt-get dist-upgrade worth the hassle? David Christensen <dpchrist@holgerdanske.com> - 2018-07-02 04:50 +0200
    Re: Is apt-get dist-upgrade worth the hassle? Curt <curty@free.fr> - 2018-07-02 10:00 +0200
      Re: Is apt-get dist-upgrade worth the hassle? Charlie Gibbs <cgibbs@surfnaked.ca> - 2018-07-03 10:00 +0200
    Re: Is apt-get dist-upgrade worth the hassle? songbird <songbird@anthive.com> - 2018-07-02 19:20 +0200

#197100 — Is apt-get dist-upgrade worth the hassle?

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.

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

After this experience, I'm gun-shy about upgrading a system in place.

BTW is it ok to sudo apt-get, or should I su root and run it from an 
actual root prompt?

-- 
cgibbs@surfnaked.ca (Charlie Gibbs)

[toc] | [next] | [standalone]

#197105

On Sun, Jul 01, 2018 at 01:17:47PM -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.
> 
> 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.)

This is just a classic disk space problem, we can work it out.

Let's look at your options.

1. Grab a USB stick, mkfs.ext4 upon it, and mount it as
   /mnt/tmp.  Copy /var/cache/apt/archives/ to it. Double
   check. rm /var/cache/apt/archives/*. Mount the USB stick 
   as /var/cache/apt/archives. Proceed with the upgrade.
   When done, unmount the USB stick and reboot.

   Pros: this should work and not cause you to do much work.
         Cheap.
   Cons: you might run into disk space problems again.


2. Buy a nice SSD and a USB-SATA cable. Install stretch on it,
   keeping to two partitions: / and /home. Copy over /home from
   your internal disk. When it's all done, swap the internal
   disk for the SSD.

   Pros: clean system
         nice fast SSD
         partitions the size you want them to be
   Cons: expensive, relatively slow to do.

3. Backup /home, wipe this disk and reinstall, then restore
   /home.

    Pros: clean system
          cheap
    Cons: takes a long time, during which your system is
          completely out of commission. If something goes 
          wrong, you may need to buy a new disk anyway.

> After this experience, I'm gun-shy about upgrading a system in place.

It's just a filesystem-full problem. They're as common as people
not making good backups.

> BTW is it ok to sudo apt-get, or should I su root and run it from an actual
> root prompt?

No difference for this. Differences only come when environment
variables are important.

-dsr-

[toc] | [prev] | [next] | [standalone]

#197107

On 07/01/2018 05:44 PM, Dan Ritter wrote:
> Let's look at your options.
>
> 2. Buy a nice SSD and a USB-SATA cable. Install stretch on it,
>     keeping to two partitions: / and /home. Copy over /home from
>     your internal disk. When it's all done, swap the internal
>     disk for the SSD.
>
>     Pros: clean system
>           nice fast SSD
>           partitions the size you want them to be
>     Cons: expensive, relatively slow to do.
>
If you can afford it, do this. If you have spinning rust in your
system now, definitely do this. It avoids all the dist-upgrade issues
and the performance improvement is an order of magnitude.

-- 
Carl Fink          carl@finknetwork.com
Thinking and logic and stuff at Reasonably Literate
http://reasonablyliterate.com

[toc] | [prev] | [next] | [standalone]

#197106

Charlie Gibbs composed on 2018-07-01 13:17 (UTC-0700):

> After this experience, I'm gun-shy about upgrading a system in place.

I work mostly with limited space / filesystems, and I do dist-upgrades more
often than fresh installs. There are places other than apt's cache that can
gobble considerable space for no useful purpose.

If you have persistent systemd logging enabled, /var/log/journal/*/ may be
wasting considerable space accumlating antique logs. Logging generally may be
accumulating waste if logrotate isn't enabled.

Sometimes wasteful old icon caches can be found in /usr/tmp/ or /var/cache/.

If your current kernel works, you don't need older versions and initrds
consuming / space.

If /home isn't a separate filesystem, then browser and other caches can be
purged to make freespace, as can emptying DE trash.

Packages you don't actually use can be purged. Even packages you use can be
purged, then reinstalled after the dist-upgrade.

If space is still a problem after thorough cleaning, specific (large) parts of
the existing installation can be upgraded, one package or package group at a
time if necessary, such as libreoffice, firmware packages, Samba, KDE or Gnome,
followed by dist-upgrade for the balance.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

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

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#197109

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

Then you can refine it depending what you find:

du -sh /var/*/ 2>/dev/null

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

> After this experience, I'm gun-shy about upgrading a system in place.

Why? If you find the cause, you can fix it. Upgrades are careful
about preserving the system's integrity to run.

> BTW is it ok to sudo apt-get, or should I su root and run it from an
> actual root prompt?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#197113

[Multipart message — attachments visible in raw view] — view raw

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

>> 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've only filled up / once, on one system, so far as I recall - and it
was in fact due to /var/cache/apt/archives.

>> After this experience, I'm gun-shy about upgrading a system in
>> place.
> 
> Why? If you find the cause, you can fix it. Upgrades are careful 
> about preserving the system's integrity to run.

Yep. I tend to dist-upgrade (against testing) about once a week, except
when there's just been a release (and testing has come out of freeze),
at which point I do it about once a day or so.

I've rarely had problems, and when I have, it's generally been due to
newly-introduced package bugs - which should all have been ironed out by
the time a stable release is made, so you aren't likely to encounter any
when dist-upgrading from one stable release to another.

Even when a change resulting in (a behavior which you might see as
being) a problem was retained for - or not noticed until after - the
stable release, by the time you're dist-upgrading this late in the
cycle, there will generally be things on the Web documenting the problem
and one or more ways to address it.

(Note that that's only for dist-upgrading against testing or stable! A
dist-upgrade against sid is not something to run on a production
machine, pretty much *ever*.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#197116

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.

[toc] | [prev] | [next] | [standalone]

#197122

On Sun, 1 Jul 2018 17:43:02 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:


> 
> Why? If you find the cause, you can fix it. Upgrades are careful
> about preserving the system's integrity to run.
> 

Less and less with each version. 

I have a wheezy: I cloned it to a spare desktop machine, upgraded with
some significant difficulty to jessie, tried the next step to stretch
and abandoned it. I believe there will be less work in a new install,
which I'm now probably about a week into, with another week to go.

Back in the days of etch, it was an hour or two. Not any more.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#197125

On 2018-07-02, Joe <joe@jretrading.com> wrote:
> On Sun, 1 Jul 2018 17:43:02 -0500
> David Wright <deblis@lionunicorn.co.uk> wrote:
>
>
>> 
>> Why? If you find the cause, you can fix it. Upgrades are careful
>> about preserving the system's integrity to run.
>> 
>
> Less and less with each version. 
>
> I have a wheezy: I cloned it to a spare desktop machine, upgraded with
> some significant difficulty to jessie, tried the next step to stretch
> and abandoned it. I believe there will be less work in a new install,
> which I'm now probably about a week into, with another week to go.
>
> Back in the days of etch, it was an hour or two. Not any more.
>

I upgraded from Wheezy to Jessie to Stretch without a problem (except I
ran out of space, which conveniently circles back on a certain raison
d'être of this thread, and apt-get cleaned right in the middle of it all
to free up room, which got me through while at the same time nearly 
condemning me to a special circle of dependency hell).

Of course I'm talking here about upgrading *in situ*, a proven path, not
cloning to another machine, whose specificities are unknown to us
in relation to the cloned machine, and then upgrading from there, for
reasons only known to yourself. In fact, Joe, I'm declaring an illegal
goalpost move on you and fining you a blame (remember: three blames and
you're out--or is that strikes?).

;-)

-- 
“...Two people going to the bottom of a river, one falling and the other
diving.” Jung describing the relationship between Joyce and his schizophrenic
daughter, Lucia.

[toc] | [prev] | [next] | [standalone]

#197126

On Mon, 2 Jul 2018 09:55:48 +0000 (UTC)
Curt <curty@free.fr> wrote:

> On 2018-07-02, Joe <joe@jretrading.com> wrote:
> > On Sun, 1 Jul 2018 17:43:02 -0500
> > David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> >  
> >> 
> >> Why? If you find the cause, you can fix it. Upgrades are careful
> >> about preserving the system's integrity to run.
> >>   
> >
> > Less and less with each version. 
> >
> > I have a wheezy: I cloned it to a spare desktop machine, upgraded
> > with some significant difficulty to jessie, tried the next step to
> > stretch and abandoned it. I believe there will be less work in a
> > new install, which I'm now probably about a week into, with another
> > week to go.
> >
> > Back in the days of etch, it was an hour or two. Not any more.
> >  
> 
> I upgraded from Wheezy to Jessie to Stretch without a problem (except
> I ran out of space, which conveniently circles back on a certain
> raison d'être of this thread, and apt-get cleaned right in the middle
> of it all to free up room, which got me through while at the same
> time nearly condemning me to a special circle of dependency hell).
> 
> Of course I'm talking here about upgrading *in situ*, a proven path,
> not cloning to another machine, whose specificities are unknown to us
> in relation to the cloned machine, and then upgrading from there, for
> reasons only known to yourself. In fact, Joe, I'm declaring an illegal
> goalpost move on you and fining you a blame (remember: three blames
> and you're out--or is that strikes?).

No, I'm not talking about hardware incompatibilities, I mean software
rot. For the most part, a drive moved to another machine will either run
normally or not at all. The copy ran fine on the other machine. It's a
server, so I'm not bothered about super-whizzy peripherals, wifi etc.
As long as there's enough RAM, and enough bits in the processor,
there's not usually much trouble.

But it's loaded (encrusted?) with a lot of server software, some of it
dating from sarge. Sometimes a version upgrade involves a significant
software upgrade, sometimes it doesn't. FreeRADIUS has hardly changed
at all for many years (though it's one that won't even start in
stretch). But as I mentioned to Michelle, PHP5 is no more, so there was
a fair bit of tweaking to old php stuff. Samba has dropped deprecated
configurations, and I have two versions of windows clients, so that was
another afternoon of messing about. 

Systemd. Need I say more? It hasn't been all that difficult, but as I
said, old software, so a certain amount of mucking about with service
files. My iptables scripts were written on Linux From Scratch, then
installed on sarge. No go.

When there's that much work to do, upgrading seems pointless, one might
as well do a clean installation and leave at least some of the cruft
behind. That was my point: even with a lot of server software,
upgrading used to be a matter of half an hour for checking and cleanup,
half an hour of downloading, than maybe an hour of installation. Use
the new config files where needed, then another half-hour for tweaking
them to work like the old ones. Half a day at the most, with the
machine pretty well running normally during most of that time. It's not
like that now.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#197142

On Mon 02 Jul 2018 at 10:12:13 (+0100), Joe wrote:
> On Sun, 1 Jul 2018 17:43:02 -0500
> David Wright <deblis@lionunicorn.co.uk> wrote:
> > Why? If you find the cause, you can fix it. Upgrades are careful
> > about preserving the system's integrity to run.
> 
> Less and less with each version. 
> 
> I have a wheezy: I cloned it to a spare desktop machine, upgraded with
> some significant difficulty to jessie, tried the next step to stretch
> and abandoned it. I believe there will be less work in a new install,
> which I'm now probably about a week into, with another week to go.
> 
> Back in the days of etch, it was an hour or two. Not any more.

Can you be more specific. The only case I can think of "recently" was
the dist-upgrade from lenny to squeeze where, if you were still
running the original lenny kernel, it was important to make sure that
udev wasn't upgraded before the kernel was upgraded and running.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#197118

On 07/01/18 13:17, 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.
> 
> 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.)
> 
> After this experience, I'm gun-shy about upgrading a system in place.
> 
> BTW is it ok to sudo apt-get, or should I su root and run it from an 
> actual root prompt?

I have had a SOHO network with a couple Debian machines for ~15 years. 
My primary goal is reliable operations.


Doing a major version upgrade in place without understanding all the 
issues and risks involved has not work well for me.  And, I estimate the 
learning curve to be non-trivial.  Instead, I pursued the following:

1.  Put my drives in mobile rack drawers, put racks in my computers, 
and/or put trayless racks in my computers.

2.  Take good system administration notes for every machine.

3.  Place notes and all modified configuration files into a version 
control system.

4.  Invest in additional equipment and learning to implement robust 
backup, archive, and image procedures.

5.  Keep at least one spare machine available at all times.


These allow me to install, repair, upgrade, etc., computers within an 
acceptable (and predictable) effort level.


When I want to do a major version upgrade on a computer:

1.  Backup and archive the data and configuration files.  Remove the 
system drive and take an image of it.  Save drive.

2.  Get a fresh system drive.  Wipe and test it using the manufacturer's 
diagnostic utility.  Insert into machine.

3.  Download the latest Debian Stable and burn to media.  Do a fresh 
install.  Update and upgrade.  Install desired software.

4.  Edit configuration files and migrate settings by hand.  Restore data.

5.  Integrate into backup, archive, and imaging processes.


David

[toc] | [prev] | [next] | [standalone]

#197119

On 2018-07-01, Charlie Gibbs <cgibbs@surfnaked.ca> wrote:
>
> 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.
>

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#sufficient-space


-- 
“...Two people going to the bottom of a river, one falling and the other
diving.” Jung describing the relationship between Joyce and his schizophrenic
daughter, Lucia.

[toc] | [prev] | [next] | [standalone]

#197157

On 02/07/18 12:55 AM, Curt wrote:

> On 2018-07-01, Charlie Gibbs <cgibbs@surfnaked.ca> wrote:
>
>> 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.
>
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#sufficient-space

Thank you (and everyone else) for your help.  I tried an apt-get purge 
of a large package I wasn't using, but the upgrade still failed (after 
chugging away for an hour or so).  I have two Linux partitions on my 
laptop - / and /home - and have arrived at the conclusion that 10GB for 
everything but /home is just not enough.  Given the amount of time I've 
spent on this already, I'm way past the point of diminishing returns. 
For now I'll stick to my main machine for everything (my laptop is just 
for when I'm on the road plus I use it for Usenet).  When I find the 
time I'll figure out what in my laptop's root partition needs saving 
(e.g. /var/spool/slrnpull), back it up along with /home, download the 
Stretch install disk image, then delete the partitions and start over 
with a bigger root partition (say 20GB).  Hopefully that'll hold me for 
a few releases.

-- 
cgibbs@surfnaked.ca (Charlie Gibbs)

[toc] | [prev] | [next] | [standalone]

#197134

Charlie Gibbs wrote:

...
> Sure enough, / is full, with all the fun that that entails.

...

  there are a lot of potential places to get space back:

  - check /var/log

  - also, see if you have old kernels that can be removed.

  - your browser cache may be huge.

  - downloaded files directory may contain stuff you don't need.

  - music or video files you don't want/need any more.

  ...


  songbird

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web