This is part of a series of articles that covers the
booting of an OSR5 machine. See Booting
OSR5 for other related articles.
The program that actually displays
SCO OpenServer(TM) Release 5 Boot :
is /boot, but there are several steps that precede this.
When an X86 processor is turned on, it runs in real mode. This is the mode that acts like the original 8086 processor, and physical memory was limited to 1 megabyte in those machines. The very top of that memory was, and still is, ROM. The processor starts reading instructions from that memory at 0xffff0. What's always there is a "jump" instruction that sends the CPU off to the PC bootstrap code.
That specific boot code might be part of your original ROM, or it might be on an add-on card such as a SCSI host adaptor or a boot capable network card. If it is a disk, it is that code's job to find out which disk boot from. One some PC's you may have some control over that choice, but historically the boot device has been the first IDE drive or SCSI ID 0. It is possible to boot and run SCO from SCSI drives other than ID 0, but that does add complication, so I'm going to ignore that until the end. It's also possible to boot from a network card, but if we were going to boot Unix over a network, that would most likely be done by /boot running on a floppy or small hard drive (see below).
The BIOS code doesn't do much. It's smart enough to find the boot disk and read the first sector of that disk into memory. The CPU then jumps to that code, which is expected to be the masterboot code (that's the MBR - Master Boot Record - in DOS terminology).
The same thing happens with a floppy disk (actually it's just a little bit different, but the concepts are the same. See "man HW boot" if you want the details).
You'll find an image of your masterboot code in /etc/masterboot, and you can use "dparam -w" to copy it to the first sector of the boot drive (see https://aplawrence.com/cgi-bin/ta.pl?arg=104323). Remember that /etc/masterboot is not what actually gets read by the BIOS- that's just a copy for your convenience. What actually gets read is whatever is in cylinder 0, head 0, sector 0- whether you put it there or something else did (like a boot sector virus from booting a Dos floppy).
The masterboot code looks for a partition table. That's stored just following the masterboot code itself, so it isn't hard to find. PC hard drives have 1 to 4 partitions. These are sometimes called fdisk partitions because the MSDOS program that created them was called that. Note these are NOT SCO divisions, and the program that can access them under SCO is also called fdisk. Here's the partition table from the machine I'm writing this on:
I was amused recently when someone suggested that I should have used an HTML table to display this. Actually, what follows is not my clumsy attempt at ASCII art, but is a screenshot of the real output you get with OSR5 fdisk.
Current Hard Disk Drive: /dev/rhd00 +-------------+----------+-----------+---------+---------+---------+ | Partition | Status | Type | Start | End | Size | +-------------+----------+-----------+---------+---------+---------+ | 1 | Active | UNIX | 16575 | 66299 | 49725 | | 2 | Inactive | UNIX | 1 | 16574 | 16574 | +-------------+----------+-----------+---------+---------+---------+ Total disk size: 66555 tracks (256 reserved for masterboot and diagnostics)
This is a little unusual: normally you'd have only one partition and if you did have more than one, usually it would be because you want to run multiple operating systems. For example, here's the partition table from another machine here:
Disk /dev/hda: 64 heads, 63 sectors, 1023 cylinders Units = cylinders of 4032 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 377 760000+ c Win95 FAT32 (LBA) /dev/hda2 378 1023 1302336 5 Extended /dev/hda5 378 386 18112+ 83 Linux /dev/hda6 387 990 1217632+ 83 Linux /dev/hda7 991 1023 66496+ 82 Linux swap
That machine runs both Linux and Windows and the partitions show that.
This is the output from Linux fdisk. There really are only 2 partitions on this disk; note that the Linux partitions all start within the "Extended" partition. If you ran fdisk from Dos or Windows, all you'd see is the Win95 and the Extended partitions. This particular configuration was due to using the Linux "fips" utility to shrink an existing Windows partition: see Installing RedHat 6.0.
Only one partition can be marked "ACTIVE". That partition is indicated by an "*" in the Linux partition table, and is marked "Active" on the SCO machine. The masterboot code identifies the active partition, and then loads code from the first sector of that partition. SCO calls that code hdboot0. As with the masterboot code, you can find the code for it in /etc/hdboot0, but remember that what is actually loaded is what is in the first sector of the active partition.
The hdboot0 code is only 512 bytes in size. It's primary function is to load the code starting at sector three of the active partion- 1536 bytes away from the start of it. That code is called hdboot1. Note that up until this point, there is no concept of file systems. Neither masterboot nor hdboot0 understand file systems; they load very specific sectors from very specific disks. The hdboot1 code, however, is almost 20kb in size, and it is able to understand EAFS file systems. That is, it can read the directory structure and follow paths to locate files, and once it has found what it wants, it can use the inode information to read the actual disk sectors needed. It can't understand HTFS or DTFS file systems, and that's why OSR5 root file systems must either be EAFS or there must be a /stand file system that is EAFS. The hdboot1 code needs to understand EAFS because it needs to find and load /boot (which usually becomes /stand/boot). After loading, control transfers to the /boot code.
Instructions for restoring these files are often given as:
dd if=/etc/hdboot0 of=/dev/hd0a dd if=/etc/hdboot1 of=/dev/hd0a bs=1k seek=1 dparam -w
Many Linux systems use LILO, which can't read any kind of file system at all, and therefore requires the raw disk locations to be hard coded. This is done by /sbin/lilo (which you run BEFORE booting a new kernel) reading a configuration file of what to boot, and then locating the actual disk locations, which it tucks into the LILO boot code.
The "active" partition is always /dev/hd0a, so it's easy to see that /etc/boot0 does get copied to the first sector of that partition. The /etc/boot1 ends up in the third sector because sectors are 512 bytes, and the "dd" command skips 1k, or two sectors.
On OSR5 systems, you can use "instbb" instead:
instbb hd /dev/hd0a dparam -w
"/etc/instbb" is a shell script; you can examine it to see how it actually works.
You can look at and compare the actual contents of your disk with these files using "hd":
hd /dev/hd0a | more hd /etc/hdboot0 | more dd if=/dev/hd0a skip=2 | hd | more hd /etc/hdboot1
Like hdboot1, /boot obviously understands EAFS file systems. It actually understands quite a few things. It even has a configuration file, /etc/default/boot, and that might make you think that it knows how to read more than an EAFS file system, but it doesn't (well, it can read Xenix file systems, and S51K file systems, but definitely not HTFS and DTFS). If you look in /stand/etc/default (I'm ignoring systems that don't use /stand), you'll find the file it actually does read and use. Normally, you don't have to be concerned about this, because any orderly shutdown (including a simple init 0) will copy /etc/default/boot to /stand/etc/default/boot.
This /boot (remember, it's actually /stand/boot on most systems) is a fairly clever program. It's only about 70k in size, but it knows how to do quite a few different tasks. the most important, of course, being loading the kernel. Which kernel? A kernel that is present on /stand, of course. The default kernel is specified in /stand/etc/default/boot, but you can override that. You can, for example, type "unix.old" and you'll boot that kernel. That's useful when the kernel produced by the last relink is somehow broken.
It also understands quite a few other commands. For example, "dir" will list the files it sees in its current directory, and "biosgeom" will display the geometry of the hard drive (it's also possible to set a new geometry with the same command). See "man HW boot" for details.
Before it even puts up that "Boot" prompt, it looks for and will read commands from .bootrc, if it exists. It reads that before looking at /etc/default/boot, so this can be used to load a tcp/ip driver so that a network boot can be done, for example. After that, it reads /etc/default/boot, and then waits for your commands.
It doesn't necessarily wait forever. One of the parameters in /etc/default/boot is the AUTOBOOT variable, which, if set to YES, specifies that /boot should just go ahead and load the default kernel if nothing happens for 60 seconds. You can speed that up or slow it down by adding a TIMEOUT variable to the default file, but if you do that, be very careful not to make the time too short. There will come a day where you will need to intervene at the boot prompt, and very short TIMEOUT combined with a fast machine can prevent you from doing that. If your default kernel won't boot, you have obvious trouble.
/boot can also load other partitions. This is useful for loading other operating systems (you don't need to buy Partition Magic or other tools to boot other partitions). Actually, /boot doesn't really do that directly: it uses "bootos". See "man bootos" for examples of that.
/boot also helpful if you need to boot from floppy. For example, if your boot code (masterboot,hdboot0 or hdboot1 or even /boot) were damaged, you could boot with an emergency boot floppy (mkdev fd) and at the Boot prompt type "hd(40)unix". This will load Unix from the hd(40) device (that's /stand on most OSR5 systems, and /dev/root on 3.2V4.2 systems).
By default, SCO Unix expected the boot drive to have ID 0. It was not uncommon to receive new systems with the ID set to 6, so we'd usually re-jumper the drive to what SCO expected. However, with a little understanding, you could boot SCO on any SCSI ID at all.
As it was usual to have to open the machine anyway (if for no other reason than to check that SCSI termination and cabling was done correctly!), I usually just reset the ID's rather than follow this procedure.
Newsgroups: comp.unix.sco.misc From: email@example.comREMOVETHIS (Bill Vermillion) Subject: Re: Installation problems ("free" UW 701) Message-ID: <F9wDoy.1Lpy@bilver.magicnet.netREMOVETHIS> Date: Fri, 9 Apr 1999 01:05:22 GMT ... You can boot SCO from almost any SCSI ID you wish. Many of the modern controllers have a setting to specify the boot drive, however that's not a major limitation if you have something as recent as an Adpatec 1542C (I've never tried from others). If you try to install on another drive - say 1 for example - and it is the first drive found in the system - and you don't change the boot command on install, you will have problems. The first drive seen is the boot drive. So if you had an HD (removeable perhaps) at ID0, another at ID1, and a Zip at ID6, the systsem would try to boot from ID1. However the OS 'thinks' it is drive 0. At the install time used the defbootstr option to set Sdsk to you adaptor code (blc,ad,??) followed by the parameters in the form of (0,0,0,0), which give the adator card number, the scsi bus, the SCSI id, and the LUN. Once you do that, anytime this drive appears as the first drive, it will be used for boot. On SCSI adpators that do not have the 'boot from drive xx' option, and using the above caveat that you have something like a 1542c or newer it's just as easy. Go into the SCSI card set up and turn Scan for BIOS OFF for all devices prior to the drive you wish to boot from. It's not black magic, and there is no truth that SCO can ONLY boot from ID0. I have a removeable HD (with power switch) as HD0. When I turn it's power off, the next ID - in this case 1, is listed as the first hard drive, and ID6 - a zip drive - is listed as the second hard drive. If I turn SCAN for BIOS off on 1 and 2. the first drive found is the ZIP at ID6, and I boot into MSDOS. (I did it to try, not than I run from it). SCSI is far too flexible to be constrained as most people seem to think it is. You can boot from any drive that you can make see as the boot PROVIDING you also supply the Sdsk parameters to boot: during the initial install phase. Then you never have to do that again. -- Bill Vermillion bv @ wjv.com
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-04-30 Tony Lawrence