FC3 upgrade without booting off cd

[David A. Bandel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regurgitating the prose of Net Llama! Net Llama!
<netllama at linux-sxs.org> on Thu, 11 Nov 2004 11:26:48 -0500 (EST):

|[snip]

|
|Yea, i've done glibc upgrades on a live system many times.  But that is
|just one of many packages invovled in upgrading to FC3.



|
|> > > This is one of the nice things about Debian upgrades.  They
|aren't a> > > .. OK, everything is going down for the next few hours ..
|deal.  Same> > > for Gentoo.  You upgrade little by little on a daily
|or weekly basis> > > and are always current.
|> >
|> > Yea, but you still have to reboot for a kernel change.  And if
|added or> > removed udev/devfs that would be really scary trying to
|activate the> > change on a live system without a reboot.
|>
|> How long does it take your system to reboot?  A matter of minutes, I
|> assume (2-3 max?).  This is a _lot different than being down for
|hours> (or even 30 minutes).
|

|Sure, but if your live upgrade goes poorly, you're going to be down for
|alot more than 30-90 minutes.

Yep.  Your point is?

If I want to upgrade my production server with a minimal of downtime,
I'm going to upgrade my test box first.  And I'm going to upgrade my
test box without any downtime if at all possible.

|
|> I run an ISP.  I can afford to reboot a system once in a while (maybe
|> even once a day).  But if a system goes down for even 5 minutes (much
|> less 30 or more to do an upgrade), the phone calls from irate
|> customers delay me even longer.
|>
|> I don't risk downtimes longer than a reboot.  At least not
|> deliberately.  Uptimes are not as important to me as not having
|> services go down, or if they do, for _very_ short intervals.
|
|For anyone concerned about uptime as you are, all upgrades should be
|done on a test system that mirrors the production system to ensure that
|the results are positive.  Anyone doing major upgrades (where major is
|defined as changing any package that if broken would result in
|downtime) on a live system is taking a fairly significant risk.

Yes, but you test the way you want to do it on your minimal down-time
production server.  I wouldn't upgrade a test box one way and the
production server a different way -- that would be really dumb.  I
perform upgrades on a number of client systems (as well as my own).  I
have a test box.  But I don't reboot the test box with the CD to perform
the upgrade then turn around and do the upgrade differently on the
production servers.  Once I've tested something, ALL subsequent work for
my servers and my clients is done _EXACTLY_ the same way.  It worked
once (or twice or more), it will work again.  Avoid failure, use a
tested method.

Again, I do this all the time.  I've upgraded glibc at least 3 times in
the past year on over a dozen different systems.  I've upgraded lots
more packages too.  Same way.  Historically, the most difficult upgrades
were:
aout to elf
libc5 to glibc6

Those required reboot with install/upgrade.  All subsequent upgrades
have been a cinch in comparison (only requiring reboot to run a new
kernel).  Even glibc-2.0 to 2.2.  The current round of glibc's upgrade
seamlessly.  They just require restart of some services is all.

If I wanted to shut down for hours, boot/format/install I could run
Windoze.

Ciao,

David A. Bandel
- -- 
Focus on the dream, not the competition.
		Nemesis Racing Team motto
GPG key autoresponder:  mailto:david_key at pananix.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBk6e5j31PLQNUbV4RAlRFAJ4rU40NPCbcbFdSN/KMWB86q52EmgCfdFKf
8ifED1noRRg87g/kjiADSXE=
=jxKh
-----END PGP SIGNATURE-----