Remote Upgrade for Fedora/Redhat
by David K. Levine
This involves two machines, a master machine from which you will
conduct the operation, and a slave machine to be upgraded. The slave
machine does not need to have a monitor, keyboard, mouse, cd-rom drive,
usb port, etc. It does need a harddrive and a network connection and a
working redhat installation running sshd, but it may be located
anywhere
on the internet. The slave machine should be on a local network with
dhcp running.
step 0: ssh from the master
machine to the slave machine. On the slave machine execute steps 1 - 6
-------on the slave machine
step 1: get the iso's from
http://fedora.redhat.com/ and put them somewhere on a harddrive, for
example in /iso. Important: make sure you do not put
them on the / partition - this partition can easily be busy during
shutdown, rendering the isos unmountable during the initial part of the
Fedora installation and causing the entire procedure to fail.
step 2: mount the first iso,
for
example
$mkdir /mnt/iso
$mount -t iso9660 /iso/yarrow-i386-disc1.iso /mnt/iso -o loop
step 3: from the /isolinux
directory of the iso (in the example /mnt/iso/isolinux) copy the files
vmlinuz and initrd.img to the /boot directory, changing the names to
something sensible, for example /boot/vmlinuz-yarrow and
/boot/initrd-yarrow.img
step 4: find out the hardware
addresses of /iso and /boot; the df command will show your disk mappings
step 5: put a copy of the
kickstart file ks.cfg in the /boot directory modifying two lines.
Replace --partition=sda6 with the partition your /iso directory is
located on (and change the name of the directory from /iso if you
called
it something else; for example if you have a separate partition for
your iso's, you probably want --dir=/). Replace /dev/sda1 in the mount
command with your
/boot partition
#System language
lang en_US
#Language modules to install
langsupport --default=en_US
#System keyboard
keyboard us
#System mouse
mouse generic3ps/2
#network
network --bootproto=dhcp --device=eth0
#Use interactive kickstart installation method
interactive
#Use hard drive installation media USE YOUR OWN HARDDRIVE
harddrive --dir=/iso --partition=sda6
#Reboot after installation
reboot
#Upgrade existing installation
upgrade
%pre
#!/bin/sh
mkdir /tmp/boot
#USE YOUR OWN HARDDRIVE
mount -t ext3 /dev/sda1 /tmp/boot
cp /tmp/boot/grub/grub.conf /tmp/boot/grub/grub.sve
cp /tmp/boot/grub/grub.bak /tmp/boot/grub/grub.conf
Here is Gerry Reno's updated and commented script
mkdir /tmp/boot # create mount point
#-USE YOUR OWN HARDDRIVE ADDR
# mount filesystem on /dev/sda1 onto /tmp/boot (hiding mount's boot dir)
mount -t ext3 /dev/sda1 /tmp/boot
# so below here /tmp/boot/... is actually /boot/... on harddrive device
# 'date' preserves original grub.conf through multiple boot attempts
cp /tmp/boot/grub/grub.conf /tmp/boot/grub/grub.conf.$(date"+%Y%m%d-%H%M%S")
cp /tmp/boot/grub/grub.conf /tmp/boot/grub/grub.sve
cp /tmp/boot/grub/grub.bak /tmp/boot/grub/grub.conf
What this kickstart file does is
1. copies the grub.conf file with the grub.bak file; this means that if
the system reboots part of the way through the installation, it will
reboot into the original configuration rather than trying the install
again, giving you a fighting chance of fixing things. For example, if
something goes wrong, you can use vnc or a power recycle to reboot the
machine, and it will reboot to the original configuration provided the
installation program hasn't left things in an inconsistent state.
2. provides the minimal information needed to get the Redhat installer
anaconda running in upgrade mode. Once anaconda is running, with grub
configured correctly, it will launch vnc, and you can monitor further
installation progress from the master machine.
step 6: modify the grub.conf
file and make backups
In the /boot/grub directory (as root) edit the grub.conf file and add
to the end the following entry replacing sda1 with your boot device and
replacing lev0201.dklevine.com with the address of your master machine.
title Yarrow
root (hd0,0)
kernel /vmlinuz-yarrow
ks=hd:sda1:/ks.cfg vnc vncconnect=lev0201.dklevine.com ramdisk_size=8192
initrd /initrd-yarrow.img
Copy this file to /boot/grub/grub.bak, then edit it again. There will
be a line
default=n
This refers to the entry that will boot automatically. The first
entry is numbered 0. Determine which entry is your new entry, say m,
and change the line to read
default=m
Remark 1: You can delete
the ks and vnc vncconnect options and not bother with resetting default
if you are going to do the install using keyboard and screen, and
simply want to boot the installation program from grub.
Remark 2: The
documentation claims that you can start vnc from within the ks.cfg
file, but this does not work, start it as a kernel option.
Remark 3: the ramdisk_size=8192
is critical. If you leave it out, the installation program will not
have workspace needed to mount drives and everything will fail.
--------now back to the master machine
step 7: run
$vncviewer -listen
on the master machine
-------and finally on the slave machine
step 8: reboot the slave
machine, for example
$shutdown -r now
step 9: monitor the
installation procedure from the master machine vncviewer. You should
have only one option, what to do about grub. Choose the default, which
is to upgrade grub. This will make sure after the installation the
system will reboot to the upgraded operating system. Use F8 from
vncviewer if something goes wrong and you need to reboot the slave.
NOTES:
- kickstart is buggy; for example on one machine it refuses to
recognize the device hdb1 in the ks file, although it correctly allows
it to be selected from the menu. Second, it appears that the vnc
procedure will not work if the machine (for unexplained reasons) does
not support graphics mode installation. You might want to add bootloader --upgrade to ks.cfg so
that this question will be skipped.
- the --device=eth0 is crucial if you system has multiple ethernet
cards; otherwise ks will stop (before vnc is running and you can do
anything about it) and ask which card to configure
- the hacked preinstall script to get grub to reboot to the old
system if there is a failure does not work terribly well. It may be
possible to use the grub savedefault
command to force reboot in the previous configuration, but the grub
documentation is highly unclear on how this works, and I haven't had a
chance to test to see if there is a way to do this.