Jim Mohr's SCO Companion

Index

Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/

Installing and Upgrading


I am sure that you are wondering why the installation portion appears so far back in the book. Well, it's something that I took a lot of time to think about. I'm betting that you already have an SCO system installed and you bought this book because you want to find out more. If you do need to install something at this point, then it's less likely that its the whole system, but rather something like new hardware or software. That's what the bulk of this chapter is all about. However, because you may (one day) want to install a system from scratch, we're going to talk a little about that.

If you already have ODT, then you are probably not going to do a fresh installation of it. More than likely, the next time you install the OS, it will be to do an install of OpenServer. However, tech support never plays the odds. I can speak from experience when I say that someone, somewhere out there is going to need to install an ODT system. Perhaps the system needs to be reinstalled because of hardware problems. Maybe there was an unopened ODT box on the shelve and the boss didn't want to waste money buying a copy of the new OS. For whatever reason, there will be someone.

In comparison to the installation guide of ODT, the one that comes with OpenServer is wonderful. Not that I am saying the one for ODT is bad. Rather it is an issue of them being two completely different books. The installation guide for ODT, basically just served the purpose of installing the system. In OpenServer it is called the "SCO OpenServer Handbook", with the sub-title of "How to install, configure, and start using an SCO OpenServer system." It covers much more than just installation and is an invaluable tool for administering your system. There is also the added benefit of having an index. The lack of an index in the ODT installation guide, made it difficult to find information you needed.

Before we jump into things, I'd like to briefly go some of the more significant changes to the OpenServer installation. After going through hundreds of installs myself and with customers on the phone, I can safely say that the OpenServer installation process is by far the simplest one yet. All of the questions are asked up front and once the files start rolling off the CD-ROM, you can go get some lunch and let the system do the work for you.

One of the most startling differences is that OpenServer only comes with a single floppy. I have been doing installs for years. There is supposed to be an N1 and N2 floppy, right? The kernel is almost the size of an entire floppy, so how can you get the kernel and the necessary programs to do an install on less than two floppies? You compress them!

Not only is the kernel compressed, but so are the installation programs. Although a certain amount of time needs to be spent uncompressing things, the kernel is uncompressed as it is being loaded. Since you do not have to switch floppies and begin loading that as well, the time you gain more than compensates for the time needed to uncompress things. A RAM disk is created and the root filesystem image is loaded into the RAM disk. Like the kernel, this filesystem image is compressed to get it to fit on the floppy. Note that although the files on the floppies are compressed, it is not a compressed filesystem.


Preparing for the Install

Both the ODT Installation Guide and OpenServer Handbook there is and "installation checklist". One thing I really like about the OpenServer Handbook checklist over the one in the ODT installation guide is that it contains comments and references to other pages in the handbook where you can find more information. Although there are comments, they come after the checklist. This means that you have to flip back and forth between pages.

I suggest you make a copy of these pages so you can fill in each entry and include it in a notebook. You will notice that there are some very basic questions like keyboard language and time zone. It may seem almost too basic to include this type of information, however, I can speak from experience that the more you have written down, the less prone you are to making mistakes. Even if the information is "basic".

Before you start you need to check out your system. The very first thing you need to check is the hardware itself. The first question to ask yourself is whether or not the hardware is supported. I'm sure there are a few of you out there who are groaning thinking this is an attempt to blow you off. I talked with many customers while I was in SCO Support that go ballistic when you even bring up the question of the hardware being supported.

"It works under DOS!" Is a common response. However, as I have said many times, all it really means is that the hardware is probably not broken. I say "probably" because I have seen defective hardware work under DOS, but not on UNIX. Under DOS a lot of hardware is accessed through the system BIOS. The BIOS is often build especially for that machine. It understands the hardware in way that SCO doesn't. Since the SCO device drivers are accessing the hardware directly, the hardware has to behave in a standard way. Otherwise, the SCO device drivers don't know what to expect.

Does this mean that your no-name hardware won't work? Not at all. My server is running a fair bit of "unsupported" hardware. Much of it is clones of supported hardware (which causes a lot of grief). However, it works. When I tried to install something that wasn't supported and it didn't work, there was no frustration because working was something that wasn't guaranteed. (Okay, there was a little frustration)

There is also the issue of conflicts. SCO is good about being able to install a wide number of cards at their default. The common place for conflicts is with cards of the same type, such as host adapters. However, having the list in front of you will confirm this before you try to install and have something go wrong.

The key pieces of information are:

Once you have installed the operating system and it works diligently for six months, the first problems may crop up. Now, what was the model of the hard disk? Rather than digging through a box of papers looking for the invoice, you have it right in front of you.

Okay, knowing that you should fill out the installation checklist is easy. Knowing what to put in each entry is the hard part. Because the OpenServer installation checklist is more detailed and even points you to other places in the installation guide, this may be of more value to people having to install ODT for the first time. (If there are any out there) However, I will be going into some details of many aspects of the installation that aren't mentioned in the installation guide.

It may already be too late, but an important thing to consider for the installation is the installation media. OpenServer is delivered on CD-ROM and you have to order it extra if you want it on 150MB cartridge tape or floppies. If you like pain, I would definitely suggest getting the floppy version. With 147 floppies, your wrists will get a good workout. If you're the patient kind, but don't like the work, maybe the tape media is best for you. Otherwise, I suggest you stick with the CD-ROM.

Consider the price of CD-ROM drives today. If you buy the CD-ROM version of OpenServer you save hundred of dollars(!) over the price of floppies. This literally pays for the CD-ROM drive. Now, a friend of mine said that this logic was comparable to his wife's when she went shopping. She would buy a dress that was on sale saying that she saved $30.00, not mentioning she probably would not have bought it if it hadn't been on sale. However, you are going to buy OpenServer even if it's not on sale. So why not get a "free" CD-ROM in the deal? There is also the added benefit of CD-ROMs being faster to access than either tapes or floppies. Once you get the CD-ROM drive you can then get SCO's Skunkware CD, which is loaded with fun stuff.

Doing a CD-ROM install is an arguable point in ODT when you need to install a single file. You can quickly find out what floppy a particular is on and extract the file within a matter of minutes. It takes longer for you to start custom and have the CD-ROM drive seek to the proper location. With OpenServer the problem is even worse since you cannot install single files. You must first remove the package and then reinstall it.

During the course of the installation, you will have the choice of several different installation types, from fully automatic to fully configurable. For the more advanced system administrators, the fully configurable allows you control of many different aspects of the install. Fully automatic, basically does everything for you. That is, it evaluates your system and essential makes all the decisions itself. My recommendation is that if you are a novice administrator and there is nothing on the hard disk that you want to save, then the fully automatic is your best choice.


Preparing for the Worst

One thing that many administrator's don't plan for is the possibility that things go wrong. Although, good planning and preparation can prevent many disasters, the most devastating are obviously the ones that are you are not prepared for. When doing an upgrade, there will come a point is which backing out is no longer possible. If the new operating system doesn't book and you cannot go back to the old one, then you have problems.

One problem that I have personal experience with is third party device drivers. Although the installation notes for the driver might say that it is for "SCO UNIX 3.2. version 4.0 and later," this may not be true. If it is an older card, then what they mean by "and later" is SCO UNIX 3.2 version 4.2 (ODT). In the case of the network card I had it wasn't true. What I had was an NE2000 compatible that worked fine in ODT. However, it gave me errors when I tried to relink it under OpenServer.

The problems that my brother encountered where much more dramatic. He has a 3rd party filesystem compression software on his system that he uses for his /u filesystem. Although this is a very stable product and he is completely satisfied with it, the version he has is incompatible with OpenServer. As a result, when he tried to relink, it failed. He then tried to load the backup software he had, only to discover that the install script did not work correct with the OpenServer custom. The choice was either to wait until he got the OpenServer version of the backup software or reinstall ODT. Since his work depends on timely access to his data, his only choice was to re-install. Since he had a complete backup of his system, he was running again within a couple of hours.

This story illustrates two important issues when doing an upgrade. First, be prepared for the possibility that your 3rd party drivers will not work. It is possible that the device was unsupported in ODT, but is now supported in OpenServer. Installing the manufacturer's driver may not only be unnecessary, it may cause problems. Check the SCO Hardware Compatibility Guide or the hardware vendor.

Keep in mind that the compression software is not a "device" In the traditional sense, despite having drivers. Therefore, you will not find it in the SCO Hardware Compatibility Guide. The best thing to do in cases like this is to talk to the vendor directly.

The other issue is that you must have a complete backup of your system before you start. In my brother's case, he did have a complete backup. The problem was that the backup software didn't work in OpenServer. However, since he was prepared before he started the upgrade and had a complete backup, he was running again with a short time. Not matter what goes wrong, these backups can get you running again.

One suggestion is to either have the new version of the backup software on hand and make sure that it is compatible with OpenServer or use some SCO tool like tar or cpio. Both the tar and cpio in OpenServer can read the backups created in ODT.

If you have access to CompuServe, you might want to consider downloading the demo copy of Lone-Tar from Library 8. This works with both ODT and OpenServer. This is a demo with a limited life span, but not limited functionality. I think you might be please enough with it to us it as your standard backup tool.


Upgrading an Existing System

The fact that your computer contains an existing SCO installation, presents it's own set of problems. Paradoxically, one of the primary trouble spots is one of the benefits that OpenServer is providing and that is the new file systems. As I mentioned in the section on filesystems, the /dev/boot filesystem was introduced to not only prevent the kernel from existing above the 1024 cylinder boundary, but also because the system cannot boot from the new filesystems types. Therefore, an upgrade installation means that you cannot use any of the new filesystems as your root filesystem.

Personally, I am not bothered by this. Although I have had good experience when doing upgrades, I am not an upgrade fan. Personally, I feel that doing a fresh install is safer, particularly when the system has one or more supplements installed. Although, I have never had problems, safe is safe. However, you may not have that option. There might be time or other constraints that "encourage" you to do an upgrade.

One aspect of your system that I am sure you will want to keep track of is your users. ODT provides the ap (account profile) command which allows you to save account information for every user listed in /etc/passwd. For details on this, see the OpenServer Handbook of the ap(ADM) man-page. However, there is much more information about your system that you may want to save. The OpenServer handbook contains a list of files that may have been changed from their defaults. Keep in mind that the heading "Files likely to be configured" is not entirely accurate (you don't configure /etc/wmtp), it does provide a list of files that might contain information that you would want to save.

If you are doing an install and have third party drivers, then the install is smart enough to keep from creating additional problems. Although the upgrade installation does not remove any drivers or device nodes, it does put an "N" in the /etc/conf/sdevice.d files of the drivers that it doesn't recognize. This way any relinks of the kernel during the installation should go smoothly. Later, you can change the N's to Y's and try to relink. Since the drivers and device nodes are still there, the relink has a good chance of being successful.

The upgrade to OpenServer also preserves other aspects of your system such as printers, network settings and additional filesystems. However, even if you do "need" to do a fresh install, the system is smart enough to pull many configuration settings directly from the old system. These are provided as default values as you go through the install.


Doing The Install

When it finally comes time to do the install, the first step is gathering all the documentation together. This includes not only all of the SCO doc, but all the handbooks (pamphlets?) that came with your hardware. The next thing to get is a notebook. Here you record all the details about your system configuration. Since you haven't installed anything, yet, now is a good time to start writing things down. This is the prefect opportunity to write down manufacturer, model and settings of all the hardware. This is a valuable set of information if you run into problems, either during the install or later. You should also write down the vendor support number if it's available. Here, again, having everything in one place save you time later.

Next is the checklist that we talked about earlier. Having a completed installation checklist has a couple of benefits. First, it can be a real time saver during the installation. You don't have to keep bouncing around between the doc and hardware or scratching your head thinking about what a good value for each entry would we. You've made all the decisions before and now you just fill in the blanks. You are therefore less likely to input mistakes or guess at what you should answer. In addition, this "forces" you to plan out the upgrade before you start.

When you boot from the floppy during the installation, one of the first things you need to consider are Boot-Time Loadable Drivers (BTLD). These are drivers for hardware that is not supported by SCO on the release you are currently installing, however the vendor provides the appropriate drivers which are then linked into the kernel at boot time. These are not necessarily drivers for hardware that you install after the OS is finished, but rather for hardware that you need during the installation. A good example would be the host adapter that your root hard disk is installed on. However, the mechanism used to install BTLDs is not just restricted to the installation. You can install a BTLD at any time. These are just drivers that are loaded at boot time, not just install time. For more details, see the section later on BTLDs.

When the kernel has finished loading and the root filesystem is uncompressed, the Installation Query Manager (IQM) is started. Although the IQM is OpenServer is conceptually the same as that for ODT, the new one is much more extensive in terms of both what areas are asked as well as the depth of information you can provide. Once you finish answering the questions, the IQM does the rest of the work.

One thing that really impressed me was the ability of the system to recognize my hardware. For example, when asking about my network configuration it asked if it should scan for a network card. When I said "yes," the system came up with the NE2000 card that mine was (supposed to be) compatible with. Later, after I had finished the install and wanted to restore my data, I absent-mindedly started a cpio without first running mkdev tape to add the tape drive. No problem. The tape started and the data was restored since the system had recognized and configured my tape drive for me during the install. (I was told by a SCO engineer that by default a tape is configured at SCSI ID whether the tape drive exists or not.)

One of the very first questions asked is the type of keyboard you have. What keyboard you have, is not as apparent an issue to Americans as it is to people other countries. Aside from the languages that have different characters than in American English, there are differences in the layout of the keyboard even between English speaking countries.

In OpenServer you no longer have to input your serial number and activation key. Instead you have a license number and license code. In some cases (with certain upgrades), there license data provided that must also be input during the installation. This is useful information to have when you need to call support, particularly if you don't already have a support contract.

The type of installation you are going to do is an important decision. In ODT, you were given three choices. Fresh, overwrite and upgrade. In a fresh install, you were considering your system as untouched and were going to overwrite everything on the hard disk. If you chose the overwrite option, the partition and filesystem information was left intact. Only the root filesystem was overwritten, and user filesystems were untouched. In an upgrade, the old files were moved out of the way, but everything else was left as it was.

In order to save time, many system administrators chose the upgrade option. Although this upgrade functionality has improved considerably since previous releases, it can't catch everything. There are many hardware and software products that become unusable after an upgrade and must be reinstalled. In the end, the administrator spends more time cleaning up from the upgrade than was saved by not doing a fresh install.

The alternative is doing an overwrite. This essentially removes all third party drivers and other products install on the root filesystem as this is completely overwritten. However, it is somewhat faster than a fresh install. The problem is that there is no overwrite option for OpenServer. You either upgrade or do a fresh install.

Personally, I'm not bothered by this. When I do an installation it is always a fresh install. Experience has taught me that the best way to avoid problems is not to let them happen. By doing a fresh install, I am much more aware of the effects each action has on my system. It may take longer initially. However, I am saved grief in the long run.

When you do a fresh install, there are a couple of key questions. First how should the disk be partitioned? If you have only one operating system, then using the entire disk for SCO is reasonable. If not, you need to consider how much will be used for each. The installation procedure of both ODT and OpenServer asks you how big you want different partitions to be. Despite that fact, there is still the question of "how big?".

One thing to consider is what other software is going to be installed. Some database applications require an entire partition for it's own purposes. Others may require their own filesystem. I've talked with customers who, after installing the OS discovered that they did not leave the necessary room for their application. They frantically call to support asking for some way to change the partition and filesystems without having to reinstall. The answer is no. Therefore know what your application expects before you start installing the operating system.

The next thing to consider is what other operating systems are you going to install. Although you can create the partitions for other operating systems during the SCO installation. It is much better to install them first and then SCO. Okay, you can get away with installing DOS after SCO, however if you are going to install OS/2, Windows NT or Windows 95, these should be installed first. The reason is that they write the partition table differently than SCO or DOS making the SCO partition in accessible.

If you are planning to install DOS, you will still be limited to the 32MB partition size if you are still running MS-DOS 3.3. Don't use any version of MS-DOS 4.x. This doesn't work well will SCO partitions. If you have anything after MS-DOS 5.0, then the partition size can be anything greater than 3Mb. Keep in mind that if you plan to use DOS DoubleSpace or some other disk compression software, the compressed partition will not be accessible by SCO utilties such as doscp, nor will you be able to mount the DOS filesystem. Also pay attention to which partition is active. I have talked with many customers who have overwritten one or the other partitions. Both DOS and SCO install to the active partition. If you install one and then install the other without first making the other partition active, you end up overwriting the first operating system.

Since DOS can be installed after SCO, some people do. Even, if you do remember to switch the active partition prior to installing DOS, some people forget about this later. They are used to booting systems with both DOS and SCO and seeing the SCO Boot: prompt. When the system boots directly into DOS, they have a heart attack and end up calling SCO Support. The way to correct this problem is to simply use DOS's fdisk to change the active partition to the UNIX partition.

Also keep in mind that when the SCO installation routines create the partitions, that's all they are doing. They are not formatting the partition. You must use native DOS programs to do that. Even the dosformat command will not format a DOS partition. This partitioning is done by the fdisk command, although you don't actually see it doing its work.

When considering the partitions size you need to also consider the swap and filesystem sizes as well. The size of your swap space needs to be considered carefully. The absolute minimum size is slightly more than the amount of RAM you have. The reason is that if the system should panic, it will dump all of memory to your swap device. If you do not have a large enough swap space, then you do not get a valid dump image and it makes tracking down the cause of the crash more difficult. The extra amount is needed to write crash data if the system panics. By increasing it by a megabyte you don't loose too much space.

I've seen references that say swap should be one-and-a-half to two times the amount of RAM. Personally, I think this is too much, without a good reason. The swap space should be considered a safety net, not an integral part of your memory system. If you are swapping then performance will suffer. If you think you would need the extra swap space, then consider buying more RAM. That way, you are less likely to swap in the first place.

However, you need to consider growth. If you expect to be increasing your RAM in the future, you should consider that when setting how much space you are going to use for swap. RAM just slides into your system. Increasing swap may require reinstalling the operating system. So, how much do you assign to swap? Good question. My suggestion is twice as much as RAM. The "good reason" I mentioned above is that it is easier to do it now and waste the space than to reinstall later. Another good reason is when you have more than one user running graphical applications. In this case, then even setting swap to 2 times RAM is reasonable. If you have all the space taken up on the primary hard disk, you can add a hard disk and use the swap command to add additional swap space.

You also need to keep in mind that swapping takes up system resources. The time to access the hard disk is hundreds of times slower than the time to access RAM. Therefore, if speed is an important consideration, you should think about having enough RAM so you don't swap.

At this point you also want to consider additional filesystems. With OpenServer, things are a complicated already. The first question is how big you want your boot filesystem to be (/dev/boot). This holds a few files and a couple of copies of the kernel. Therefore, it doesn't need to be too big. However, you need to consider how much the kernels can grow to. If you have a 3Mb kernel, then 5Mb for /dev/boot is not enough. However, making it 50Mb is going overboard at the other extreme. Personally, I think 10-15 gives you room for larger kernel, but also gives you room to grow. However, you need to consider that there will probably be at least three kernel here.

The next question is whether you should make additional filesystems. If you application requires a filesystem to itself (usually a raw division), then you definitely need to create it. What about a /u or /home filesystem for your users? There are advantages to having one as well as advantages to not having one.

If you have one, it is easier to come up with a backup schedule if you don't want to do a full back-up of the system every night. For example, you could back up the whole system once a week, and the /u filesystem with the data every night. In addition, most of the hard disk activity is on the root filesystem, if your data is there and there is a head crash, you can loose data. By moving your data to another part of the disk, you decrease the likelihood of data loss.

The disadvantage of a separate filesystem is that system accounts such as root or sys have their home directories in /usr. If you put other users in /u or /home, the home directories are in two different places. This may not be too big a problem if the system accounts, rarely, if ever, log in. The other problem is that creation of the file system does not mean that it gets mounted automatically. (At least not in ODT) As a result customers would end up calling to SCO Support saying that half their disk was missing. They had created the filesystem, but didn't run mkdev fs to have it get mounted. Although it is mentioned in the ODT doc that you need to do this, finding it requires that you either know the problem or read the doc cover to cover. OpenServer corrected the problem by asking if you want to create the appropriate entries to automatically mount the filesystem.

The other problem is that the default is to create user home directories in /usr. Therefore you need to change the HOME_DIR variable in /etc/default/authsh on ODT and in /etc/default/accounts on OpenServer. Personally, I think it's a good idea to have data on a separate filesystem and keep the root filesystem as static as possible. This makes backup schedules easier and there is less chance of corruption as the root filesystem is usually the busiest and therefore has a greater potential for corruption.

During the installation it is the divvy program that divides the partition into divisions and then calls mkfs to create the filesystems on those divisions. Although there are eight entries in the division table, the last one (Division 7) is reserved and is used to reference the entire partition. If you have a large enough disk, division 6 might be reserved as well. This is the scratch device that is used by fsck.

The filesystems created on the root hard disk are dependent on which OS you are installing. On ODT, the first division (division 0) is for the root filesystem. However, on OpenServer, the first filesystem is /dev/boot which contains the file necessary to boot. The root filesystem is then on the third division. In both cases, the swap division is in division 1. Additional filesystem are created after the systems filesystems.

If you choose block by block control over the filesystems, you can change the starting and ending blocks and therefore the sizes of the filesystems and get around any defaults enforced by the system. Here you can also name the filesystems anything you want. However, I would not change the name of any of the system filesystems. You can also add a filesystem here. If so, you need to ensure that you create it as well. This will run mkfs to create the superblock and inode table. Note that the maximum filesystem size that you can create is 1TB for both DTFS and HTFS, and 2GB for other filesystems.

Some of you might see this statement as being incorrect. The SCO doc says that the HTFS can only be 512Gb. The word I got from a SCO engineer is that this is incorrect. Both can handle 1TB.

Another question concerns what type of disk scan to select. If you have a SCSI disk, this step is skipped as it is expected that the SCSI disk will be doing the bad tracking itself. The system will create the bad track table, however, not prompt you to scan the disk. If it does a scan, tracks are read from the disk and rewritten. The value that is read is compared to the value that is written. This is done several times to ensure the integrity of the data. If you have a SCSI disk, you can scan it later using the scsibadblk utility. (If you have ODT, think about getting the new badtrk from SCO support.) If it is a non-SCSI disk you use the badtrk utility.

You have two characteristics to chose from. First is the speed of the scan. You are given the choice between a Thorough and a Quick scan. As one would guess, a thorough scan takes longer than a quick scan — several times longer. However, it is more reliable since the data is read and written more often.

You also choose between a destructive and non-destructive scan. A non-destructive scan reads the data first and then right back whatever was there originally. A destructive scan writes a known pattern of bytes on the disk first, and then reads it. This is obviously destructive because whatever was on that track is overwritten by this pattern. This is more reliable because you always know what the data is supposed to be. Assume the track is not "bad" just "flaky". That is only sometimes is it read incorrectly. With a non-destructive scan, you could have read in corrupt data, if you write it back and read it again. You don't know what is correct.

The moral? If there is any question about the integrity of the hard disk, then do a thorough, destructive scan. I say it three times: Destructive means destructive. Destructive means destructive. Destructive means destructive. I have had a number of calls from customers who did a thorough, destructive scan of the complete hard disk, only to find the data on the second filesystem (which they had hoped to preserve across the installation) was now gone. Their interpretation of destructive was anything from "destroying the bad tracks" to "I'm not a techie. How should I know?"

If badtrk finds a problem in the first few tracks of the partition, you are returned to fdisk¸ so you can re-partition the disk around these bad spots. If you repeated gets bad tracks at the beginning of the disk or all of the tracks appear to be bad, then the hard disk geometry is probably wrong. You will have to restart the installation and ensure that the system has the correct hard disk parameters.

When badtrk finishes, you are prompted for the number of entries to put in the badtrk table. Always put in as many as are recommended, if not more. If sometime in the future your disk develops problems and you need a lot of entries in the table, it can get filled up. Once it's full, there is nothing to do with additional bad tracks. The only solution is to reinstall. To calculate the amount of space lost, multiply the number of entries in the badtrk table by the sectors per track, then by 512 bytes per sector. (Think back to our discussion of the layout of the hard disk.)

What components of the product you install is also something to consider. Obviously the easiest thing is just to install everything. That way it's there if you need it. If you have a space problem, then installing everything is not always a good idea. Limited space is one reason why SCO came up with the Desktop product and why the DTFS was implemented. However, if you have ODT or are still cramped for space you might need to consider leaving out some packages.

If you are running NFS, a common package to remove is the man-pages and other on-line documentation. To can then use NFS (see the section on configuring your networking) to mount the doc from a remote machine. By having this on a central machine you not only save space, but it is also easier to include your own, local documentation since you don't have to worry about updating all you machines. Changes made on the "documentation server" are immediately available to everyone. Take a look at the section on automount in the Network chapter for ideas on that.

Whenever I have to do a floppy installation, I often leave out the documentation to save time. Once I am up and running, I can add the doc at my leisure. I will often bring the system up into multi-user mode and configure users or printers while I am installing the doc. Depending on the system and time constraints, I may even leave off packages like X or TCP. However, this is really only an issue with floppies. If I have a CD-ROM or tape install, it's easier to install everything and then later remove the pieces I don't want.

One aspect of the OpenServer installation that I am very grateful for is asking me whether I want scologin enabled by default or not. I don't. Although it is easy enough to disable it (scologin disable). I was annoyed at someone thinking that they knew better and that I would "naturally" want it enabled. I want the choice of starting X when I go into multi-user mode or not. (Interestingly enough, I almost always go into X. Old habits are hard to break.)

If the machine you are installing is going to be on a network, then the network configuration is also something to consider before you install. There are entries in the installation checklist for the configuration information, such as IP address, netmask, and broadcast. Which, like the other entries, when it is filled out in advance, saves you time when doing the install.

One very important thing you need to be aware if that the OpenServer installation does not prompt you to install the release supplement like it does in ODT. You must, instead, go through the Software Manager to install new software. This is very important as the Release Supplement contains last corrections to known problems (in English: bug fixes). One thing to keep in mind is that when you add the release supplement in OpenServet, you select "Add Patch" and not "Add New Software."

If somewhere during the installation you run into a snag and have to restart the installation, you need to be careful. For example, you get half through the installation and realize you did not leave any room for a /u filesystem. So, you need to restart. The problem, depending on how far you've gotten, is that if you power off and reboot from the installation floppy. The sytem will recognize that it has already reached a particular point and continue on from there. In order to get the system to restart the install from the beginning, you need to enter "restart" at the Boot: prompt.

Boot-Time Loadable Drivers

As their name implies Boot-Time Loadable Drivers (BTLDs) are drivers that are loaded at boot-time. This provides a very effective means of adding drivers to the system that are not contained within the normal distribution. In most cases, BTLDs come from third party vendors and are used to support devices that you need to install from, such as SCSI host adapters. (If you don't need it to install the OS, why not wait until later to install that driver.) Despite this generality, BTLDs can be loaded anytime you boot.

The desire to install a BTLD is indicated on the boot line by the link=pkg argument to the boot program, where pkg is the name of the package containing the driver I want to install. For example, I have a Wonder Works host adapter. The package name is "wwha". The boot string would look like this:

Boot: link=wwha

After the kernel has loaded (but before it starts to execute) the /link program is run. This prompts you to insert the floppy disk containing the BTLD you specified. Next you may be prompted to input values to configure that hardware, such as base address, DMA channel and interrupt vector. If you input values that conflict with existing hardware, link will scream at you and give you instructions on what you can do to correct the problem.

If you have multiple BTLDs that you wish to load, you can specify them all at the Boot: prompt. The system will then prompt you for each driver, in turn. For example, if you have the wwha and fyha, the bootstrings would look like this:

Boot: link="wwha fyha"

Note that you need to include all the drivers between the double quotes. You can also specify the link command on it's own, in which case you with prompted for the names of the package(s) that should be linked it.

One common misconception is that once you have added the driver at boot time, then the driver is part of your system for keeps. Well, it is until the next time you relink your kernel. The problem is that the driver is linked into the kernel that is being loaded, but is not made part of your link kit. The next time you reboot, the driver is gone. To get the driver into the link kit and into all subsequent kernels, you need to run the installpkg utility. Here you are prompted to insert the disk containing the BTLD. At this point, all subsequent relinks will include the new driver.

On the other hand, the installation of both ODT and OpenServer should prompt you to reinsert the BTLD disk to add it to the link kit. If so, it becomes part of the system for good. However, if you are not prompted, you will need to run installpkg.

After Installation

When you finally get through the installation, the work is not over, yet. OpenServer comes with a very complicated scheme to cut down on software piracy. This is a series of annoying messages that "encourage" you to register. Although the functionality is not obstructed when you don't register, you get a message on your screen every time you boot up and login, indicating that unregistered software is installed on the system.

Software registration is accomplished in two steps. First you need to fill out the registration card with all the "necessary" information (including the product serial number) and send to one of the registration centers. A short time later you will receive a registration code that turns of all those annoying messages. This is accomplished in the second step though the License Manager.

There are a couple of things to note here. Every SCO product that you install needs to be both licensed and registered. It's possible to install a product and not license it. This is useful if you wish one machine to be an installation server so you can install software across the network. However, you need to license the software before it will run. It is therefore possible to have several products installed on the license server, none of which work since none of them are licensed.

While you are waiting to get back your registration information, you can do something that can save you a lot of hassles later. Now is the time to make your first complete backup of the system. While you're at it, you can make a boot-root floppy set, "just in case."

Solving Problems with Licensing and Registration

The two most common problems that occur when licensing their products is the incorrect licensing information. Isn't that one problem? Well, sort of. In ODT this information is the serial number and activation key. In OpenServer this is the license number, license code and license data. The first problem is having the wrong information for the software you are trying to install. For example, if you are trying to install the Enterprise System then the licensing information for the Host System will not work. Although this is more common in larger installations with multiple systems, it does happen.

The next issue is the process of typing in the licensing information. Many people forget that UNIX is case sensitive. This applies to both the commands and the licensing information. If both upper and lower case letters are used, I hope it would be obvious that case is important. However, many customers will call into support insisting that the licensing information is incorrect. Turning of the Caps Lock key or pressing the shift key and the correct moment usually solves the problem.

There is one issue with the Certificate of License and Authenticity (COLA) that can cause you problems. The dot-matrix printer that is used to print the COLA makes the lower case q's (the letter right before 'r') look like g's (the letter right before 'h'). If you have both on the COLA, then this is not a problem. However, if you only have the q's (like I did), you may get a message saying you have invalid activation information. Just remember that the g's are curled a little to the left and the q's are not. In the meantime, the printer was replaced, so this should only be a problem with older registration cards.

Another problem occurs when upgrading from stand-alone UNIX to the Enterprise version of Open Server. Not only are you changing releases, you are changing the scope of your product . As a result you end up getting two sets of license information. One that brings you from your old product to the Host version (the closest in scope) and then the second that brings you from the Host version to the Enterprise version. The problem is that the Installation Query Manager (IQM, this is the installation program itself) will accept the license information from the Enterprise version without you ever having used the information for the Host version. If this happens, the only solution is to start over. Therefore, it is important that you use the Host version information first and then upgrade to the Enterprise Version. If you don't the installation appears to go fine, but when you reboot you get:


LOGIN: Upgrade license missing.

Overriding system login limit on tty01 only,

to allow emergency system maintenance.

But that's not all. If you license the Host version and then upgrade to the Enterprise version without having registered the Host version, you end up with another message and another problem. Fortunately, all that happens is that you continue to get the message that say your software is unregistered, even though you have registered the Enterprise version.

This is slightly easier to correct. You will first need to remove the Enterprise license. This is done in maintenance mode through the License Manager. You now will see the Host system in the License Manager. Next, register the Host system using the license manager. You can now license and register the Enterprise system.

One change to SCO's upgrade policy that changed with OpenServer is the introduction of the Software Enhancement Service (SES). This is actual a bundle of several products and services that SCO used to provide separately. As of this writing, the only way you can get an update to a product (that is, getting the product at a reduced rate) is through SES. Prices are based on your currently platform, so you should see SCO for details.

In principle, you can consider SES a kind of subscription service, which like other subscriptions, you pay for annually. Not only does it include the reduced costs upgrades, but also free Maintenance Supplements as well as the Support Software Library Which contains the entire Information Tools Database (IT scripts) as well as many of the more current Extended Functionality Supplements and Support Level Supplements.




Next: Configuring the Network

Index

Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/