On Sun, Aug 10, 2008 at 10:16:09PM -0700, Andrew Lentvorski wrote:
The worst I could imagine is needing to use a fresh kernel. But, since
I can boot from a rescue disk, chroot into the new machine and pretty
much fix anything, it shouldn't be a problem.
Uhh, that doesn't count as a "restore" then. In fact, "fixing things up"
is often more work than just reinstalling. Especially if you have a well
automated install process.
I've never had an automated install process, since I've only done it a
handfull of times. There is just way too much customization I do to
make that practical.
I just checked my oldest machine. Unfortunately, I didn't record when I
first installed the machine, so I'm not completely sure. The oldest
mtime I can find is from 2002 (not counting installed files that have
old timestamps).
The oldest ctime is from august 2007, which is probably from the new HD
I got, when I copied the data over.
The machine is kept up-to-date. It's even gone through a complete
catastrophic machine failure (power supply fried everything). I
replaced the entire computer, booted my recovery disk, restored grubbed,
and it was up and running.
Only in the land of Linux would "rescue disk, chroot, recompile modules,
and update the kernel" be considered part of a "restore".
I've never had to do this as part of a restore.
The closest I've come is when I bought a motherboard that wasn't
supported by stable kernels. I ended up building a kernel on another
machine, and using that to bring up the machine. None of the
distributions I could find would even boot on it.
Those are the kind of days that make me long for 20+ year old operating
systems like VMS.
The alternative being the "other" model where you change something,
you're screwed and you start over again? One of the things I like about
Linux is that I can fix nearly anything that goes wrong.
Perhaps this is why I don't like most distributions.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
