![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
Here at Northern Michigan University, we run a Linux lab with 14 workstations. Upgrading from Redhat 3.0 to Redhat 4.0 has been quite an adventure. This article describes the upgrading of one workstation.
The first thing to do when upgrading is to free up a significant block of time. We used a day and a night to upgrade one machine. That included downloading the software, making floppy disks, and fixing our errors along the way. In fact, if you're a busy person, and Redhat 3.0 is working fine for you, then you might choose to delay the upgrade, or even avoid it. However, at the Linux Lab at Northern Michigan, we try and stay near the cutting edge, so the upgrade was a must for us.
The next step is to decide your upgrade method. The choices are the same ones from Redhat 3.0:
The quickest and easiest way is to use the CD-ROM drive. This is the only way if you don't have a direct Internet connection, since you cannot download the necessary amount of data through a modem in any reasonable amount of time Since our workstations don't have CD-ROM drives, and do have an excellent Internet connection, we chose to do an FTP install.
Before an FTP install can begin, two disks named boot.img and supp.img must be downloaded from ftp://ftp.redhat.com/pub/redhat/current/i386/images/ . They can be written to the floppy disks with the commands
dd if=boot.img of=/dev/fd0 (switch disks) dd if=supp.img of=/dev/fd0
The second disk is only needed for an FTP install. Redhat 3.0 required three disks for all install types, so this change makes a significant savings in user effort. However, we had used the Redhat 3.0 disks as emergency boot disks to correct problems like forgetting the root password (yes, this does happen). The Redhat 4.0 boot disks are missing several important utilities (i.e. tar and vi) so cannot be used for this purpose.
Also, notice that these two disks work for any supported hardware configuration. The older Redhat 3.0 required that the user search through a list of boot disks for the correct choice based on his hardware. This search often took more time than the download itself. Redhat 4.0 is much improved in this regard (our favorite new feature).
The first thing you'll see after inserting the boot.img disk and rebooting the computer is a LILO prompt. Just the words:
boot:
We would have liked more explanation of our choices here. Redhat 3.0 offered a very nice menu of help text that explained the possible parameters and their effects. However, if you just wait in a perplexed fashion long enough, the system will become impatient and boot Linux for you.
The first difference you'll notice is that Redhat 4.0 prompts you to describe your hardware. It asks about SCSI controllers and network adapters, showing you a list of possible choices. Behind the scenes the Redhat 4.0 install script loads kernel modules to access your hardware.
While this is happening is a good time to switch to virtual console #3 (press <ALT>F3). This console shows what's happening in more technical detail, describing things like the mounting and unmounting of file systems, and the downloading of files. The older Redhat 3.0 did not have this feature, which we often use to debug problems. You can switch back to the main action by pressing <ALT>F1.
The install scripts also query the user for network information. You should know your IP number, netmask, gateway, hostname, domain name, and name server before starting the install. We notice that Redhat 4.0 creates a default gateway and name server entry based upon your IP number and netmask, but that these defaults are rarely right. Better in our opinion would be to have no default at all than a misleading one.
Redhat 4.0 will show you a menu of possible software upgrades and additions. This list is essentially the same as Redhat 3.0, except that most packages have increased in version number.
The biggest problem we had involved the remote login software (rlogin, in.rlogind, in.rshd and in.telnetd). These have been upgraded to use the P.A.M. library and kerberos. However, we often login into our Linux workstations from older Sun Sparcs that do not run this software suite. For some unexplained reason, the SunOS clients could not access the Linux servers. We solved the problem by simply re-installing the older software.
In general, we suggest letting Redhat upgrade everything you might ever use. You should avoid downloading any software you are sure you will not need. Avoiding unneeded software will decreases the total time needed and the probability of network errors during the download.
Step one of the download process is to pick an FTP site. There are many listed here. We started by choosing a site with a fast 'ping time' from us, since ping time is a reasonable approximation of FTP throughput and is quite quick to gather. To find out the ping tome to a site like www.redhat.com, just type:
ping www.redhat.com
After ping runs for several packets, kill it with <CNTL>C. The average ping time will be shown at the bottom. We saw ping times from 80 - 300 milliseconds. Downloads are four times faster from the best site compared to the worst. It is well worth your time to explore sing ping before picking a site at random. The fastest was the aptly named ftp://ftp.real-time.com/pub/redhat . Unfortunately, they were not accepting FTP connections, so we used ftp://uiarchive.cso.uiuc.edu/pub/systems/linux/distributions/redhat. We could FTP to that site, but the download failed. It seems that the download scripts also want to know the version and architecture of the packages you are trying to download. Therefore, the correct URL is ftp://uiarchive.cso.uiuc.edu/pub/systems/linux/distributions/redhat/current/i386. That was not obvious from the directions. We suggest that the Redhat folks either change their script to add these subdirectories or make their directions more clear.
For us, upgrading required downloading over 300 megabytes. I must say the status screen during the download is quite nice. The biggest problem with it is that it does not show the progress of downloading each package. Since the download was so long, we left it running overnight. Unfortunately, it failed on the download of LILO. The download script then waited for us to press a key acknowledging the error, which meant it stopped downloading some time during the night. Better would be to continue downloading while informing the user of this error.
Once the download is finished, and you answer a few simple questions, you get to reboot your computer into Redhat 4.0 (yea!!).
The first thing we noticed is that the kernel has been upgraded to Linux 2.0.19. Some problems we had before, like our tape drive not working, were fixed with this upgrade. Also, our Adaptec 2740 SCSI controller was accessible for the first time. Java support is included in the upgraded kernel.
We discovered the auto-mounter daemon (amd) was running, and had created a directory named /proc. Inside /proc is every computer mountable by your workstation. For example, /proc/foo is the root directory of the host foo, assuming foo will allow outside access. Nice feature!!
The ps command has been changed. Formerly, we used 'ps -augx' to see all processes on our system. That command will no longer work. The new equivalent is 'ps -ax'.
The passwd command has been changed. In fact, my former password is now considered ill advised, and I've had to pick a new password.
The window manager fvwm95 has been included in the upgraded Redhat. Surprisingly, workman, the musical CD player, was not. See http://www.redhat.com/linux-info/pkglist/rh40_i386/all-packages.html for the complete list.
Happily, the Redhat 4.0 upgrade left much of our custom configuration intact. For example, we run a custom X server that Redhat left in place, and our NFS mounts as described in /etc/fstab were retained, even though the upgrade did change /etc/fstab to add other entries (like the /net file system). We did have to re-edit /etc/rc.d/rc.local to set our NIS domain.
The errata can be found at http://www.redhat.com/support/docs/rhl/rh40-errata-general.html . It is actually quite long. Basically, the errata is a list of package upgrades to Redhat 4.0, along with a description of applicability. We counted up to 40 packages to download and install, depending on your configuration. That just too many!! Why does not Redhat make these improved packages a part of the latest redhat release, possibly called Redhat 4.0.1?
Luckily, the process is quite mechanical, and requires little thought. Just download the needed files, and run rpm -U on them.
Netscape has upgraded since we did our original install. Unfortunately, Redhat does not include Netscape, so Netscape must be updated separately. Perhaps there are legal reasons Redhat does not include Netscape, but Redhat does include other non-free software, such as xv.
During the upgrade, the install scripts creates backup copies of certain files in /etc/rc.d/rc*.d with the extension ".rpmsave". Once everything is set up correctly, you can delete any files in /etc/rc.d/rc*.d/*.rpmsave.
Overall, the Redhat package is well done. The installation is easier for Redhat than any other Unix we know of. Redhat 4.0 is a collection of small upgrades of many packages from Redhat 3.0. There are only a few new packages (i.e.: fvwm95, TheNextLevel). Overall, our system is much as it was before, but with many small improvements. Unless you have some need to upgrade, or just feel like messing around with your system, we suggest the results may not be worth the effort. Even so, we like Redhat 4.0 very much.
If you have comments or suggestions, email me at randy@euclid.nmu.edu