[buug] Trapped in Upgrade Hell

[Michael Paoli]

========================================================================

> Message-ID: <199540-2200430755728568 at M2W085.mail2web.com>
> Reply-To: jzitt at josephzitt.com
> To: buug at weak.org
> Subject: [buug] Trapped in Upgrade Hell
> Date: Sun, 7 Mar 2004 00:57:28 -0500

> I seem to have gotten my system into a bizarrely hosed state. I first tried
> to upgrade the box from RedHat 9 to Fedora Core 1 (I no longer recall why).
Ouch - I wouldn't recommend "upgrading" (if one can call it that)
between operating systems or distributions that aren't official upgrade
paths, unless one is well skilled in administration of both starting and 
target operating systems/distributions and one is also very willing to 
risk loss of all the data involved in the attempt and willing to work
through potentially a lot of headaches to actually get all the kinks  
worked out (if it does in fact turn out to be reasonably, or at least   
semi-feasiblely, possible).

> So I gave up on that and tried to upgrade to Mandrake 9.2, having
> understood that to be relatively foolproof. It wasn't. The system now bombs

> However, when I boot up from a Knoppix Live CD and look at what's in its

> mystical way, files-but-not-files, but what that means in a practical sense
> is a complete mystery.
... yes, device files, see my comment above about "well skilled in
administration of both starting and target operating
systems/distributions", etc.

> Is there anyway to turn this back into a usable, bootable machine? I am
Yes, do a complete restore from the full backup you made just before you
started your "upgrade" attempts.

> Is there any further information I can provide? I am off the edge of my
> knowledge and, after 7 years of slamming my head against trying to get
> Linux systems working, quite near the edge of my patience.
7 years is a relatively long time, try refining the technique (e.g. less  
head slamming).  Perhaps hindsight's always 20/20, but ...
-perhaps a bit more research might have helped a lot (i.e. research the
relative ease vs. difficulty of the "upgrade" one is contemplating,
perhaps even asking quite specific version/configuration detailed  
questions in advance and gathering a consensus (or at least plurality)
of opinions and experience
-backup, backup, backup; and periodically test backups and that one has
everything necessary to do a full "cold metal" recovery; don't forget to
cover off-site issues and it may be prudent to backup in manner(s) which
give one more flexibility in recovery (e.g. to potentially significantly
different hardware or configuration)
-I'll skip attempts at analogy (which would probably be poor anyway),
but what you attempted in my estimate (I'm not a Red Hat and Fedora
expert, so my estimate may be off a fair bit) is probably rather to
quite non-trivial, and perhaps even relatively infeasible.  Adding
Mandrake, etc., to your initial "upgrade" actions also doesn't exactly  
act to simplify the situation.  It's not the type of "upgrade" I would
attempt without first doing a lot of research, being willing to
potentially use/waste a lot of time on it, and being prepared and
willing to possibly discard the results (or attempts thereof), restore  
from backup, and pick another route from there.

========================================================================

] From: "f.johan.beisser" <jan at caustic.org>
] To: "jzitt at josephzitt.com" <jzitt at josephzitt.com>
] cc: buug at weak.org
] Subject: Re: [buug] Trapped in Upgrade Hell
] In-Reply-To: <199540-2200430755728568 at M2W085.mail2web.com>
] Message-ID: <20040306220058.D2055 at pogo.caustic.org>
] References: <199540-2200430755728568 at M2W085.mail2web.com>
] Date: Sat, 6 Mar 2004 22:05:31 -0800 (PST)

] 1: it's hosed. give up, reinstall.
I'm inclined to concur.

] 2: upgrading between distrobutions is pretty much impossible, not to
] mention very likely to break everything.
At best, highly risky.  I'm aware of some tools to go between certain 
specific distributions, but I'd still consider doing such to generally
be quite risky.

] 3: when doing major changes like this, you're best off starting over.
Essentially agreed.  I'd think for such a change, where one wanted to
preserve as much data, "environment", etc., as possible, and with such  
significantly different distributions, I would be more inclined to do a
"fresh" installation of the target distribution, then carefully merge in
selected data from backup of the prior distribution (e.g. things that
likely aren't distribution specific - such as most of the contents of
user's home directories, ... the 100GiB or so of data that was mentioned
- less all the Red Hat specific stuff (e.g. personal movie/sound
archives, or whatever's taking up the bulk of that space).

] back up your data before putting it at risk.
Yup, ... like frequently; e.g. if it's on a hard drive (especially just
one), it's at risk.

] rebuilds are faster than recoveries, 8 out of 10 times.
I guess here I'm inclined to both agree and disagree, but perhaps it's
semantics.  In any case, certainly doing a clean fresh install is
typically faster and easier than doing a complex conversion/migration 
(which is really what was attempted - not an "upgrade" in the
conventional sense).  Recoveries may or may not be fast - really depends
a lot on what's involved, what one is recovering to, and what one is
recovering from.

] once you've chosen a distribution of linux, stick with it.
Yes, for the most part that's much easier than trying to jump
distributions with data and matching up configurations and all.  If one 
does the LINUX systems administration, I'd also recommend however, one
learn - at least generally - what is the same and different among LINUX
distributions, so at least one can have a rough estimation of the
difficulty of switching distributions (so one might better evaluate when
it might actually make sense - and when it (generally) doesn't).

========================================================================

> Message-ID: <410-2200430764847532 at M2W065.mail2web.com>
> Reply-To: jzitt at josephzitt.com
> From: "jzitt at josephzitt.com" <jzitt at josephzitt.com>
> To: buug at weak.org
> Subject: Re: [buug] Trapped in Upgrade Hell
> Date: Sun, 7 Mar 2004 01:48:47 -0500

> So is there a practical way to back up 100 GB of data given a single slow
> CD-R burner and no network?
Not particularly.  One needs to asses costs and risks.  When that hard
drive irrecoverablely and without warning dies (or the server catches
fire), how are you going to restore your data?  What's it worth to you
(both monetarily and willingness to spend how much time to ensure that  
it's backed up "often enough").

========================================================================

] From: "f.johan.beisser" <jan at caustic.org>
] To: "jzitt at josephzitt.com" <jzitt at josephzitt.com>
] cc: buug at weak.org
] Subject: Re: [buug] Trapped in Upgrade Hell
] In-Reply-To: <410-2200430764847532 at M2W065.mail2web.com>
] Message-ID: <20040306230207.F2055 at pogo.caustic.org>
] References: <410-2200430764847532 at M2W065.mail2web.com>
] Date: Sat, 6 Mar 2004 23:05:34 -0800 (PST)

] yes. you may want to try to put it on a spare hard drive.
Well, for some cost/risk tradeoffs, that may be satisfactory.  It does
have key drawbacks such as:
-if there are only two hard drives, and something goes quite wrong
during backup, all data may be lost
-if significant problem/corruption/loss is discovered latently in the 
data, one may not have a sufficiently old backup to recover the data (or
even analyze the history of the problem).
-if the backup hard drives is transported, it's relatively fragile, if  
not there's greater probability of simultaneous loss of both original
and backup.
Of course it's still better than no backup :-)

========================================================================

} From: Nick Moffitt <nick at zork.net>
} To: buug at weak.org
} Subject: Re: [buug] Trapped in Upgrade Hell
} Message-ID: <20040307160647.GC13653 at zork.net>
} References: <410-2200430764847532 at M2W065.mail2web.com>
} In-Reply-To: <410-2200430764847532 at M2W065.mail2web.com>
} Date: Sun, 7 Mar 2004 08:06:47 -0800   

}         It's called a "tape drive", and you ought to install one.  
Absolutely.  Still the best "general" solution (but not always the best
cost/risk tradeoff for all scenarios).

========================================================================

) To: buug at weak.org
) Subject: Re: [buug] Trapped in Upgrade Hell
) References: <199540-2200430755728568 at M2W085.mail2web.com>
) From: Ian Zimmerman <itz at buug.org>
) In-Reply-To: <199540-2200430755728568 at M2W085.mail2web.com>
) Message-ID: <87n06s8w60.fsf at buug.org>
) Date: 07 Mar 2004 08:21:59 -0800

) If it still matters, likely keywords to look for are initrd and devfs.
I'll also add these comments:
-"user" data, e.g. most of the data in user's home directories may be
the more/most "recoverable" (portable) of the original data (i.e. the
many 10s of GiB of data on the drive which isn't specifically Red Hat
stuff).
-ext2 filesystems would generally be the most portable among LINUX
distributions.  Ext3 can be treated as backwards-compatible subset of
ext2 (e.g. you can treat and use ext3 as an ext2 filesystem - that will
lose the journaling benefits and effectively convert from ext3 to ext2,
but on can then later relatively easily convert from ext2 to ext3)
-backup first (and always - or at least sufficiently frequently)
-research first
-such a complex conversion may be easier if filesystems are reasonably
separated out (e.g. separate filesystems for /boot, /, /tmp, /usr, /var,
/home)
-in 1998 I "upgraded" (I'd consider it an upgrade, but not in the
conventional sense) from
SCO UNIX System V/386 Operating System RELEASE: 3.2 Version 4.1
to Debian GNU/Linux "Hamm" (Hamm was in "frozen" state, but release as
2.0 was still forthcoming); in 1990 I upgraded from SCO XENIX 386 to SCO
UNIX 386 while continuing to use/retain/(re)install the SCO XENIX
development and text processing software (that software was really only 
designed for SCO XENIX, however SCO UNIX provided backwards binary
compatibility with SCO XENIX); neither of those
upgrades/configurations were things I'd consider easy or very close to
trivial, but with proper backups, planning, testing, research, etc., they
were both accomplished with relatively minimum of headache and no major
unpleasant surprises.
-unless* this is business critical, it may be better to avoid slamming
one's head against the wall on such issues when one isn't most fresh for
dealing with potentially complex and challenging problems and difficult
decisions (i.e. 0:00 to 2:00 Sunday might not be optimal timing   
for working on the stickiest parts of such a problem).
*and perhaps especially if

========================================================================