Upgrading Red Hat (Alpha & Intel) w/o rebooting

[Robert G. Brown]

On Thu, 6 Jul 2000, Philip E. Varner wrote:

> > In general, how would Debian/FreeBSD get around getting the
> > new kernel running without a reboot? Also, updates to things
> > like libc are problematic without rebooting.
> 
> The problem was not rebooting itself.  The problem is rebooting _with a
> floppy disk_, as is required by Red Hat's installer.  If the floppy drive
> is broken, this won't work.  Debian has apt and FreeBSD has their
> {wonderful,horrible} ports collection, so you can upgrade versions (as in
> Debian 2.1 to Debian 2.2, not as in just kernel versions) without having
> to reboot onto a floppy.  
> 
> I'm pretty sure that just running "rpm -F *.rpm" on the latest set of RPMS
> isn't the same as using RH's installer.  Else, they would just state that
> somewhere in their literature.  Does anybody have any evidence to the
> contrary? 

I've actually tried upgrading with repeated rpm -F *.rpm's and it
doesn't work very effectively, although it does work "sort of".  The
full upgrade is much better.  However, with patience one can make this
work.  One can also write a perl script of sorts that tries to just
upgrade all your installed packages, working through the revealed
dependencies in order.  Obviously this sucks, partly because there are
damn near dependency loops in some applications and they have to be
resolved by hand.  Also, it doesn't help you much with upgrading your
kernel, which typically also has to be done by hand.  Finally,
"something" won't work, possibly because it has been moved off the
primary RH disk, or because you have installed software from somewhere
other than the original RH disk with dependencies that lock in the older
version.

However, Seth's solution posted yesterday (at my request) actually will
do a real RH upgrade without a floppy.  Basically you boot (via e.g.
lilo) a local kernel image from your hard disk that goes into the RH
install/upgrade routine.  This lets you do a "real" upgrade and exit by
just rebooting your upgraded system.  Since the RH upgrade both
preserves as nearly as possible your existing installation selections
and can manage things like the kernel upgrade while maintaining your
existing configuration settings it is a Good Thing to work this way.

If you use RH and maintain approximately homogeneous nodes, it is also
well worthwhile to build a kickstart install for your nodes (as opposed
to trying the "upgrade" option of the usual install script) and then
simply reinstall nodes via kickstart from the debugged ks script and the
nodes don't need a monitor or keyboard or mouse at all.  That way you
can test/upgrade a single node repeatedly until your ks script works
perfectly for a new release (usually a very simple thing -- only a few
changes are typically needed) and then rerun ks on all nodes.  The
advantage of doing this is that if a node ever crashes by e.g. losing a
hard disk, you can rebuild it and bring it back up in literally twenty
minutes.  Presuming of course that you don't store data on your nodes (a
generally bad idea in most cases, although there are certainly
exceptions).

Yet another solution is to arrange a "diskless" boot from your local
hard disk.  Without a floppy this might be a bit tricky, but you
"should" be able to boot from a local kernel and NFS mount root via a
suitable lilo configuration or kernel options entered at boot time.  At
that point you can e.g. clone a "standard node" you've already
installed, edit a few files and rerun lilo (don't forget!) and reboot.
This is a bit risky -- there is no net if you screw up and render your
hard disk unbootable by e.g. forgetting to run lilo on the mounted hard
disk after the clone (so don't forget!) -- but with care it should be
easy enough especially if you only have one or two nodes with broken
floppies.  Did I mention that you shouldn't forget to rerun lilo?

There are likely a few other ways to do it.  I'd still suggest working
through Seth's recipe first as it is tried and proven and should yield
significant advantages in overall scaling of maintenance.  For example,
here he uses this method for ALL nodes ALL of the time.  That way he
doesn't even have to be physically present for an upgrade, let alone
walk around with a boot floppy and/or a CD.  He can upgrade by simply
building the upgrade and then setting a trigger in a cron script.  The
next day voila!  All the hosts selected are upgraded when he gets in in
the morning.  Of course you don't do it this way the very first
time...;-)

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu