SCO Unix Upgrades
© Tony Lawrence, aplawrence.com
I think most of us tend to delay upgrades. There is the natural fear of untested software, the expense, the time and trouble required, and of course the old "don't fix it if it isn't broken" adage.
But sooner or later we have to bite the bullet. As I write this, Year 2000 issues are causing some older systems to require changes. There is also the fact that new OS's like Openserver 5.0.5 and Unixware 7 offer new features and capabilities. Finally, older OS's like Xenix can often be incapable of working with new hardware.
Upgrades can be difficult. On the other hand, with a little bit of foresight and planning, the process can be smooth and easy.
The procedures here are most important when moving from an older version to a newer. If you are simply trasferring to new hardware, it's usually easy enough to just use one of the Supertars to move everything over. At worst you'll need to make some adjustments in /etc/conf/cf.d, and even that may not be necessary. However, there are cases where you want to take advantage of the opportunity to start clean: not just bring over every piece of junk from the old system. In that case, these techniques can be helpul for that, too.
This is a long, complicated article. Read it slowly, and think about everything you do.
The first consideration is whether or not to buy new hardware. In general, I'd say the answer to that should almost always be yes. There are several advantages: you will be able to keep the old system running until you are totally certain that all bugs and kinks are out of the new system; you won't be under pressure if something goes wrong or if some unforeseen software problem arises, and you'll probably be getting a performance boost just from the new hardware.
On that note, I'd also like to suggest that you don't overspend. Today's sub $1,000.00 computer makes $20,000 monsters of just a few years ago look anemic. If you buy less than leading edge, you aren't tying up large amounts of money in something that will be near to obsolete in two years anyway. This is especially true right now (Aug 98): the new machines on the horizon will have incredible capacity and power.
Of course that doesn't mean that you should underpower the machine. If you need the fastest possible box, then that's what you'll have to buy, knowing full well that in a very few months it will move down in price because something even faster will be out. That's life in the world of computers.
If you are not buying new hardware, and if your upgrade path path allows an In Place Upgrade (IPU), you may be tempted to take that option. On the face of it, it looks better than going through all the work of recreating your environment.
My best advice is not to do this.
With all OS upgrades sold in recent years, you have the option of installing fresh. Years ago, some upgrades truly were "upgrades": they only included the files necessary to bring the OS up to the new version. That has not been the case in recent years; the CD and license you receive is capable of doing a complete fresh install, and this generally is the path you should choose.
For some very minor upgrades, where you have a clear understanding of what is being replaced and what isn't, you might consider this if (and only if) the upgrade can also be backed out easily. But the unfortunate fact is, IPU's often cause problems. It is very difficult to anticipate every possible configuration, and nearly impossible to make a fool-proof IPU program. If all the IPU did was fail miserably, that wouldn't be so bad. However, the "failures" are apt to be more subtle, and take the form of annoying and seemingly inexplicable glitches.
There is also the issue that many upgrades deliberately don't replace or install certain components. Sometimes these include some of the very reasons you want the upgrade, and you'll end up doing a fair amount of manual work to get them anyway!
Trust me. I've been doing this for more than 20 years now, and you do NOT want to do IPU's. Do a fresh install, and work from there. It's cleaner, more reliable, and you will have far more control over the whole process.
See also IPU's vs. Fresh Installs
If you have more than one hard drive
Additional hard drives (and even additional divisions such as /dev/u that aren't part of the base OS) do not have to be overwritten during an install to the same box, or hard drives can be moved to the new box after install. If you do this, you do have to consider the following:
The other hard drives will need to be added into the kernel with "mkdev hd". If it's just a division on your existing hard drive, then this of course is not required.
Once that's done, you reboot. You now need to get at the hard drives or the partition with "divvy". If it is just a "/u" partition, then just type "divvy". If it's on another drive, you need to run divvy with the proper argument for the drive and fdisk partition. See "man HW hd" for the tricky situations, but probably it is as simple as:
divvy /dev/hd10 # second disk divvy /dev/hd2s0 # third disk
If you have trouble with this, just run "mkdev hd" again, but do NOT change the bad track table and do NOT create any new filesystems. You will have to "name" the division(s) and then "q"uit and "i"nstall. All that does is create device nodes using the names you chose that point to the proper drive/partition/division. If you understand the bits from "man HW hd" and can use "mknod", you could do this yourself- but why would you when "divvy" is so easy to use?
After this, you need to add the filesystems to /etc/default/filesys or run "mkdev fs". Then a "reboot" or just a "mountall" will give you access to your old data. See Adding a Disk Drive for more details on "mkdev hd", etc.
The next step is to check on software and drivers. Will all of your existing software run on the new version? If you are transferring old hardware like multiport cards, or reusing the old machine, will you need updated drivers and are there any compatibility issues?
If you are bringing in new hardware, does this have any affect on your software? For example, you may be changing multiport cards, and the tty numbering scheme may change: what used to be /dev/ttyi12 will now be /dev/ttya12 on the new hardware. That's plainly important for printers, but also some software has configuration information that is very specific about tty names (for example, Mas90).
Chances are that your disk space will be increasing. New disks get larger and less expensive every day, and for many uses, you may find that the smallest disk you can buy is far more than you need. That's great, but you have to decide how to lay this out. Will you still need or want a /u filesystem? Will you want other filesystems?
Some hardware changes may cause other problems, too: if your multiport cards are RJ connectors rather than DB-25, a change could require changes to wiring, because the signals can travel on different pins. You want to know about that ahead of time. See the article here on serial wiring if you need a refresher on this.
If you are re-using some hardware, but leaving the old machine up for the conversion, how will you handle the logistics? Are you certain the old hardware will work reliably in the new machine?
If new application software is required, how will you handle that cut-over? Will you do a trial conversion?
If you are putting a new tape drive in a new machine, can it read the old tapes? Should you perhaps consider having two tape drives in the new machine: one to be compatible with the older model and something else for real use?
New hardware should, of course, be checked on the SCO Hardware Compatibility Lists . But don't leave it at that: also check the Search page to make sure there aren't any problems with that hardware in certain configurations. For example, I recently had trouble with an Adaptec 2940 controller. It is a supported product, but in some configurations you need to use a driver provided with oss463b. It's nice to know about these sorts of potential problems before the install.
For some smaller installations, all of these issues may be able to be resolved in a few minutes. In larger and more complex environments, this may take weeks of planning and cross-checking. Obviously, the more critical the machine, the more need to carefully double-check each part of your plan.
You should also read the installation manual for the new OS. SCO always includes a section on upgrade issues, and it is worth reading over before jumping in.
I'm not going to cover IPU's here. As I said above, I don't recommend that. My assumptions here are that you will be making a fresh install, either on a new machine or on the existing hardware. If using existing hardware, there are some specific things you'll want to do before bringing that machine down for the last time. In either case, I'm assuming you have made an appropriate number of backups.
Special things to get from the old box
If you are moving from Openserver 5.0.x to 5.0.x or better, you'll want to get J.P. Radley's "savefiles" script. It's available from ftp://ftp.jpr.com/pub/ This script assumes that you now have a 5.x Openserver release and that you are upgrading to 5.0.4 or 5.0.5.
You cannot use this script for anything else!
However, it's still a useful script to look at to remind you of things you will want in other situations, so you might want to look it over anyway.
No matter what, a few things done ahead of time will save you trouble later. Some of these apply only to Unix systems and some are valid for both Unix and Xenix. We'll start with the things that should be done on any system: Note: I just recently tucked away all my old Xenix manuals and can't conveniently get at them just now. My memory of certain commands may not be perfect, so you will definitely want to examine the output of any command to be sure it worked correctly, and you'll want to check man pages if it didn't.
# this and all scripts here are to be run as root mkdir /tmp/upgrade hwconfig -hc > /tmp/upgrade/hwconfig # If upgrading on same hardware, pay particular attention to the output from the -c flag. lpstat -t > /tmp/upgrade/lpstat # See below for more discussion of printers crontab -l > /tmp/upgrade/crontab # Note this is root's crontab only. See below df -v > /tmp/upgrade/df
for Unix systems, add these:
/tcb/bin/ap -dg > /tmp/upgrade/ap.out grep ifconfig /etc/tcp > /tmp/upgrade/ifconfig llistat > /tmp/upgrade/llistat netstat -rn > /tmp/upgrade/netstat sar -v 5 5 > /tmp/upgrade/sar /etc/conf/cf.d/configure -x > /tmp/upgrade/configure
The purpose of these commands is to collect information that isn't easy to determine from examining files. If the old system will remain up and running during the upgrade, you really don't need to do any of these, because you can always get the information as you need it.
What you do not want to do is just start copying files from the old OS to the new. First, the formats may have changed, or may need to change because of the upgrade. For example, we're collecting tuning information above with configure -x. The 5.0.4 release introduced entirely different concepts for tuning, and if we just blindly copied /etc/conf/cf.d/stune, we'd make things worse. Root and system crontab files are another good example of things that you do not want to just blindly copy.
There is also the issue that permissions and ownerships may change from release to release, and that some commands require kernel changes that are best accomplished by reinstalling rather than copying.
You will make a complete backup of everything. I strongly recommend that you use one of the Super-tar products to do this (see Supertars), but otherwise do:
# this and all scripts here are to be run as root cd / find . -print -depth | cpio -ocvB > /dev/rct0
(adjust name of tape device as appropriate)
If you are installing the new OS on this machine, do it several times, and do test reads (cpio -itv) to sanity check yourself. Even if you have other filesystems that you plan to preserve across the upgrade, back them up anyway. Better safe than sorry, and better too many tapes than not enough. Tapes do break now and then.
Backup the files in /tmp/upgrade to a floppy. You may also want to print some of them out if you are upgrading this machine; the output of hwconfig and df -v are especially nice to have.
You are now ready to install the new OS. Covering that is not the purpose of this article, so I'll just pretend you have that done and proceed from there.
However, some of the information collected above can be very useful. If you are installing on the same machine, or transferring some hardware from that machine, the output of the hwconfig will be helpful. The llistat will give you your nic cards MAC address, and also tell you if it has been overridden. The ifconfig will have the ip addresses you used, and the netstat will have routing information (If you don't have TCP/IP, of course none of this is applicable).
The sar and configure information will be useful after the install for tuning.
After the Install
The very first thing to do is to install all required patches.
Next, install any applications that can't be restored from your backup. It's very important to do this BEFORE using any of the scripts below.
It's now time to restore the floppy and the tape. The floppy files can go anywhere, but you need a new directory for the tape. I call it "/oldstuff" or something like that. So,
# this and all scripts here are to be run as root mkdir /oldstuff cd /oldstuff pwd
You really are in /oldstuff, right? OK.
cpio -itv < /dev/rct0 | more
That's just to make sure you have the right tape, and that it's relative, that is, the file names do not start with /. If everything is OK, restore it:
# this and all scripts here are to be run as root cpio -icdumvB < /dev/rct0
Now the real work begins. Move your user directories over using a script like this:
# this and all scripts here are to be run as root cd /oldstuff/usr for i in * do if test -d /usr/$i then : else mv $i /usr/$i fi done
Now restore your password entries. If you were upgrading from a Unix system, you have ap.out from your floppy, and can recreate with ap -rv -f ap.out . Note that without the -o option, you won't overwrite any existing system accounts on the new system.
If you do not have ap.out, you can still use ap. In this case, you'd
cd /oldstuff /tcb/bin/ap -u . -v
For Xenix systems, you'll use addxusers. This is more complex, but the man page gives step by step instructions. Be sure to read it.
If /oldstuff came from a 5.0.x system, then /tcb/files/auth is a symbolic link and will need to be repointed using the "mkoldstufflinks" script above.
You can use the same type of script used for user directories to move other directories in place, always being careful that the sub-directory doesn't already exist.
Similar techniques can be used to move individual files. You may have binaries installed in /usr/bin for examnple. However, you do have to be very careful moving commands from /usr/bin or /bin. You may have additional programs there that need to be moved, but Unix and Xenix keep things in different places, so what used to be in /usr/bin in Xenix might be in /bin in Unix, etc. Therefore you do not want to just arbitrarily copy stuff over just because you don't see it in the same directory.
Also, /bin and /usr/bin may become the same directory in future releases (that's already true in Unixware 7 : /bin is a symbolic link to /usr/bin).
Something like this is a little safer:
# this and all scripts here are to be run as root for i in bin usr/bin do cd /oldstuff/$i for j in * do if test -r /bin/$j -o -r /usr/bin/$j then : else test -h $i || mv $j /$i/$j # note: for even more safety, you might consider # this instead: # mv $j /usr/local/bin/$j fi done done
Note that this script fails for sub-directories like /usr/bin/X11. It's supposed to fail. For subdirectories, you use a similar script to determine what needs to be copied.
Also note the suggestion to copy to /usr/local/bin. However, doing this may break scripts that look specifically in /bin or /usr/bin.
It is possible that things may break anyway. Suppose that the old system had command xyz which didn't exist in that release's OS (in other words, the command was added by an application), but now does happen to exist in the new release. The script above will not clobber the new command, but the old application is not going to work. That kind of problem can be hard to find and might even be hard to correct, but fortunately it's rare.
You also have to watch out for symbolic links. That's why the scripts include a "test -h" for those- generally speaking anything with a symlink introduces enough complication that you'll want to step back and handle it carefully. For example, I had a client get into a mess on a 5.0.6 upgrade because I didn't know he was running Merge. The 5.0.6 requires a new version, but scripts like those above had copied symlinks for parts of the old version. When the new version tried to install, it got all confused by the symlinks that pointed to non-existent places. If the new Merge had been installed BEFORE the rest of the fixing up, this wouldn't have happened.
Bill Vermillion suggests a slightly different procedure. Bill removes everything in /oldstuff that already exists on the new system, and then examines what's left. This does have the advantage of leaving you less to examine, but if the new release happens to have a command that uses the same name as something custom you had on the old, this will lose that. Of course, finding that sort of problem is difficult anyway, and fortunately is rare. Modifying the script above for that would result in:
# this and all scripts here are to be run as root for i in bin usr/bin do cd /oldstuff/$i for j in * do if test -r /bin/$j -o -r /usr/bin/$j then rm $i else : done
Be careful moving around within /oldstuff- it's easy to accidentally follow a symbolic link and end up on your new system. That's because the symbolic links you restored are going to point to where they always pointed. IT IS VERY EASY TO BECOME CONFUSED. If, for example, you "cat /oldstuff/etc/ttys", you'll either get nothing (if you have been upgrading from a different version) or you'll get the newly installed /etc/ttys (if you are transferring the same version to different hardware). Also, when removing files, make sure you remove at the topmost level. Running "rm -r" on symbolic links is safe; only the link itself will be removed. But running "rm */*" is a different story entirely.
You may want to use this script to "correct" the symbolic links:
#!/bin/sh # mkoldstufflinks # correct symbolic links to point at /oldstuff test -h $1 || exit 0 j=`ls -l $1 | sed 's/.*-> //'` rm $1 ln -s /oldstuff/$j $1
You can run this against any symbolic link in /oldstuff.
Printers can be transferred fairly easily from /oldstuff. One simple way to assure success is to cd to /oldstuff/usr/spool/lp/ interfaces (on Unix it's /usr/spool/lp/admins/lp/interfaces) and do
for i in * do if test -r /usr/spool/lp/model/$i then : else cp $i /usr/spool/lp/model/$i fi done
Then recreate your printers, choosing their own names for the interfaces. This guarantees that you will get back the correct interfaces for your printers. Note that HP network printers need some more work here: the scripts for these end up calling scripts in interfaces/model.orig.
If transferring from 5.x to 5.0.x you could just restore the /usr/spool/lp hierarchy. However, I prefer to recreate, because that way I know I'm not transferring permission problems or anything else that might have gone awry. If your /oldstuff is a 5.0.x system, the /usr/spool/lp hierarchy has symbolic links that will need to be corrected with the "mkoldstufflink" script above.
I've also done this:
cd /oldstuff/var/spool/lp/admins/lp/printers for i in * do /usr/lib/lpadmin -p $i -m dumb -v /dev/null cp $i/* /var/spool/lp/admins/lp/printers/$i cp /oldstuff/var/spool/lp/admins/lp/interfaces/$i /var/spool/lp/admins/lp/interfaces/$i done /usr/lib/lpshut sleep 1 /usr/lib/lpsched
Xenix printers can be transferred with a script like this:
cd /oldstuff/usr/spool/lp/member for i in * do # make sure we aren't overwriting an existing model if test -r /usr/spool/lp/model/$i then echo "Model $i already exists" else cp ../interface/$i /usr/spool/lp/model /usr/lib/lpadmin -p $i -v `cat $i` -m $i /usr/lib/accept $i enable $i fi done
None of these scripts take classes or other unusual situations into account.
I have had at least one situation where the interface scripts copied from an old system caused problems on the new. I didn't take the time to investigate if there had been modifications, but something was sure wrong because the spooler would always think the printers had faulted. It would then stop the printer, wait a while, and reprint the job. This generated infinite output, or would have if we hadn't run out of paper overnight.
To find what ttys need to be enabled,
cd /oldstuff/etc # Xenix grep "^1" /etc/ttys # Unix grep respawn /etc/inittab
Don't forget to look in /oldstuff/etc/ttytype to get your term types. If the ttys are the same, you can just read that in to /etc/ttytype.
If you are doing a lot of this, you'd want to write scripts to handle this and the printers.
These are the BASICS. You may have many other issues to deal with. Some of the more common issues are detailed here.
UUCPIn most cases, you can just copy the files over from /oldstuff/usr/lib/uucp. However, I prefer to manually merge the data in, because it lets me review how things are set up. Obviously at a minimum you'll need to recreate the Devices entries.
Depending on what you were upgrading from, there may be new dialers and/or features available. Check the man pages before transferring old files.
If you are upgrading from something really old, the /usr/lib/uucp files may be the older style (if you see L.sys you've got the old files); if so, you'll need some hand-work there. If my memory is right, you can simply pick out lines and merge them into new files for the most part, keeping in mind that there may be new features as noted above.
If converting from mmdf to sendmail, you've got handwork for sure.
rc scriptsIf you had startup scripts in /etc/rc or /etc/rc.d, review them CAREFULLY and make sure they are appropriate for the new system. /etc/rc.d/8 was a common place to put things on Xenix systems; ups daemons might be there or in rc.d/7.
ScoshExamine .appllist2 files to be sure they are appropriate; copy over or merge the system defaults.
SkunkwareMost Skunkware programs should be reinstalled; other programs in /usr/local/bin may be able to be moved: try moving first; if you have problems, reinstall.
CrontabsDon't forget user's crontab files (again, do NOT blindly copy system crontabs!). Examine them to be sure that the commands they contain are appropriate for the new system.
ProfilesDon't neglect additions that may have been made to /oldstuff/etc/profile or other shell startup files.
The nice thing is that whatever you forgot, it's there in /oldstuff.
© August 1998 Anthony Lawrence. All rights
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version