[olug] Grub

[Christopher Cashell]

On Fri, Jul 29, 2011 at 9:14 PM, Kevin D. Snodgrass
<kdsnodgrass at yahoo.com> wrote:
> I NEVER EVER do upgrades.  Always do clean installs.  Entirely possible that I will never trust doing upgrades.  Clean installs generally work.  If an upgrade goes fubar, where do you start looking?

My old server[0], before it suffered catastrophic hardware failure,
had been successfully upgraded from Debian 1.3 "Bo", to 2.0 "Hamm", to
2.1 "Slink", to 2.2 "Potato", to 3.0 "Woody", to 3.1 "Sarge", to 4.0
"Etch".  It was initially installed in early 1998, and remained "in
production" until late 2007, when it died.  It was never re-installed
after the first Debian installation, just upgraded.

I have a good bit of confidence in Debian upgrades at this point.
I've done upgrades to other distributions with less consistent
success, but with some success, over the years.  I am admittedly a
good bit more cautious with them.

As for how to deal with an upgrade that fails, it depends on what
"fails".  I've had a few minor issues with upgrades that could be
corrected with a little bit of troubleshooting and tweaking.  If
you're talking about a major failure, those are easier to deal with if
you're prepared.

For starters, you should never do a major upgrade without running (and
checking) your backups.  You should always have a good backup
available.  If you need more roll-back capability, a modern Linux
system with LVM can provide a lot of flexibility.  You can snapshot
your LVM volumes, then attempt/perform the upgrade.  This is also a
place where Virtualization can offer some advantages.  Snapshot your
VM and then run your upgrade, or for downtime-sensitive production
systems, snapshot your VM and first test your upgrade on a snapshot.
After you've gone through the process and thoroughly tested it, you
can run it in production.

A slightly less safe rollback option I've seen used is to break your
RAID (assumes that your server is running on a RAID1 set (and if it
isn't, it probably should be)), perform the upgrade, and if problems
occur, you can go back to the yanked drive(s) to recover.  I wouldn't
recommend this as a best practice, but I've seen it work.

> Kevin D. Snodgrass

[0] IBM Intellistation: Dual Pentium Pro 200, 384MB of RAM, 2 x 4.5GB
SCSI HDD, 1 x 9GB SCSI HDD, 1 x 160GB SATA HDD.

-- 
Christopher