boot(HW) 06 January 1993 boot(HW) Name boot - UNIX boot program Description boot is an interactive program used to load and execute standalone pro- grams. It is used primarily for loading and executing the UNIX System kernel, but can load and execute any program linked for standalone execu- tion. boot is a required part of the operating system and must be present in the root directory of the root filesystem to ensure successful loading of the UNIX System kernel. The boot program is invoked by the system each time the computer is started. To restart the system without going through the lengthy shutdown(ADM) procedure, you can use the reboot command. This causes the system to reboot after shutting down without waiting for keyboard input. See haltsys(ADM) for more information. For diskette boot, the procedure has four stages: 1. The ROMs load the first half of the boot block from sector 0 of the floppy. 2. The boot block loads its second half from sector 1 of the floppy. 3. The now-complete boot block loads /boot from the floppy filesystem. 4. /boot locates the console and prompts for a command. For hard-disk boot, the procedure has five stages: 1. The ROMs load in the masterboot block from sector 0 on the hard disk. 2. The masterboot block then loads the partition boot block (boot0) from sector 0 of the active partition (see fdisk(ADM)). 3. Then, assuming the UNIX partition is active, boot1 is loaded starting from 1K in the active partition. boot1 spans 20 physically contigu- ous 1K blocks on the disk. 4. boot1 loads /boot from the UNIX filesystem. 5. boot locates the console and prompts for a command. /boot and /unix can lie on tracks that have been mapped by badtrk(ADM). masterboot, boot0, and boot1 cannot lie on bad tracks. During installation, a custom masterboot is placed on the hard disk. If a non-standard disk is specified, its parameters are stored and enabled in this masterboot. The hard disk boot procedure is invoked if the diskette drive is empty. boot locates the console using the procedure described in the section ``Selecting the system console'' and then prompts for a command: SCO UNIX System V/386 [ on i80486 ] Boot : The command line you enter should be of the form: standalone [ arguments ] ... where standalone is the name of command to execute (for example, defbootstr, unix, unix.old, link), and the (optional) arguments are the ``bootstring'' passed to that command. The default standalone command (that is, the command assumed if only <Return> is pressed) is defined by defbootstr in the initial defaults file: /etc/default/boot on the booted media. defbootstr is normally defined to be the UNIX kernel. Hence, entering defbootstr is identical to just pressing <Return>. The following standalone commands are built into boot: ? Lists the devices boot knows about; boot can only load standalone programs and boot-linked driver packages from these devices. systty=digit Specifies the system console used by the UNIX kernel. Please see the section ``Selecting the system console'' for details. mem=ranges Defines the default core location and size available for use by both boot and the UNIX kernel. Please see the section ``Defining the available memory'' for details. dir [ directory ] Lists the files in directory; the default is the root of the file- system from which boot was loaded. link [ standalone [ arguments ] ... ] Causes boot to prompt for a list of packages to link-edit to the standalone command. Please see the section ``Boot-Time loading of device drivers'' for details. Alternatively, the argument link="package list" may be used to specify the packages to be linked into standalone on the command line. This argument is described later in this section. If standalone is not recognized as one of the built-in commands, then the defaults file is searched for an alias of the form: standalone [ = ] definition If the initial defaults file contains a definition of the form: ALTDEF [ = ] defaults then the named defaults file (if it exists) is used instead. This pro- cess is repeated (up to 100 times) until the current defaults file does not contain an ALTDEF definition, or the specified defaults file cannot be opened. The arguments (if any) are appended to the standalone definition (if any) from the defaults file. The result should name a standalone program. boot loads that program into core and runs it, passing the booted program most of the specified arguments. boot uses an extension of the normal UNIX filename syntax; the device containing the file should also be specified. The question mark ? stan- dalone command lists the devices known to boot. The extended format for the device and pathname are any of the following: xx(m,o)filename xx(m)filename filename * _____________________________________________________________________ Name Description Example _____________________________________________________________________ xx Device name hd Hard disk fd Floppy diskette m Minor device number 40 Primary hard disk root filesystem 104 Secondary hard disk root filesystem 64 Floppy diskette filesystem o Filesystem offset (optional; usually 0) filename Standard UNIX pathname, relative to the filesystem's root directory. * Depending on usage, the default device is typically either the media the computer booted or the media from which boot is loading the standalone program being booted. All numbers are in decimal. See the hd(HW) and fd(HW) manual pages for minor device numbers of those devices. The offset is optional. Not all filesystem types are recognized; those which are understood include XENIX, S51K, and AFS. Not all arguments are passed by boot to the loaded standalone command. Some are processed by boot itself: cache=[/n|/y][/d|/e] Controls the i80486 internal cache. The following flags are recog- nized: /n The cache is off after the kernel is loaded. This may be neces- sary for some machines where there are problems with cache coherency (this occurs when DMA does not notify the internal cache that memory has been written to directly). /y The cache is on after the kernel is loaded (this is the default). Machine performance will be enhanced if caching is enabled. /d Flush cache code is disabled. Booting will take less time if flushing is disabled, however, this may cause some machines to fail to boot. /e Flush cache code is enabled (this is the default). prompt [ ="string" ] boot prints the string and waits for <Return> after loading (but before starting) the standalone command. The default string is: Loaded, press Return The string should be enclosed in quotes ("). mem=range Overrides the default core location and sizing established by the mem= standalone command (described above); please see the section ``Defining the available memory'' for details. btld=device The device, in the form where offset o is optional, from which boot-linked driver packages are loaded. The default is the media from which boot was loaded. Please see the section ``Boot-time loading of device drivers'' for details. The alternative form btlddev=device is equivalent. link="pkg1 pkg2" Names of BTLD (Boot-Time Loaded device Driver) packages to be linked into the loaded UNIX kernel by boot. The list of package names should be enclosed in quotes ("), and the package names separated by spaces. Each package name may be optionally preceded by a device; if no device is specified, the package is loaded from the above btld device. The link standalone command overrides the link=bootstring argument (note that this is opposite of mem=). Please see the sec- tion ``Boot-time loading of device drivers'' for details. All other arguments are passed by boot to the standalone program. Recent versions of the UNIX kernel make the bootstring arguments passed to it available via the special file /dev/string/boot. boot may add a few additional arguments to those entered or read from the defaults file: kernel.auto Nothing was typed in response to the boot prompt, AUTOBOOT is set to YES in the defaults file, no drivers are being boot-linked, and the prompt bootstring argument was not specified. The UNIX kernel and init(M) are to start the system assuming no human is present; init is passed an argument of -a. If necessary, an appropriate kernel.systty bootstring argument is added to the bootstring by boot; please see the section ``Selecting the system console'' for details. For compatibility with older systems, boot does not include the kernel module name; please see the section ``Configuring the Kernel'' for details. If AUTOBOOT=YES is set in the defaults file, then boot will wait n seconds for a reply to its first prompt (n is the value of TIMEOUT in the defaults file). If nothing is typed within those n seconds, boot assumes a reply of RETURN (that is, the defbootstr defined in the defaults file) and proceeds to auto-boot the system. If you wish to install DOS on the hard disk, it is recommended that you do so before you install the Operating System. The dos standalone com- mand boots your installed DOS. Configuring the kernel Except for the bootstring arguments described above, boot passes all of the arguments to the UNIX kernel. The kernel parses the bootstring to adjust its configuration; for example, to set the root, dump, and swap devices. Appropriate default values are assumed if the bootstring does not specify a value. All bootstring arguments passed to the kernel have the form: module.name=value The module, =, and value are all optional (obviously, if a value is specified, a = must also be given; a = without a value is the same as a value of "" or the empty string). The default module is kernel; for safety, unknown kernel names or illegal values usually cause the UNIX kernel to halt (thereby forcing the system to be rebooted and a correct name or value to be entered). Some values specify a device. These device values, which are parsed by the UNIX kernel and not by boot, are identical to what boot uses: xnamex (m) xnamex (m,o) except that the device names (UNIX: xnamex; boot: xx) are not always identical, and the kernel always ignores the offset (o). The default de- vices depend on the kernel's configuration and can be (but usually are not) changed; the default values of the initial configuration shipped with the system are listed below. The recognized kernel names include: kernel.root=device The root filesystem; default is usually hd(40). The alternative form kernel.rootdev=device is equivalent. kernel.swap=device The initial swap area; default is usually hd(41). The alternative form kernel.swapdev=device is equivalent. kernel.swplo=s First block (starting with 0) in the swap area the system can use for swapping and paging. The default is usually 0. kernel.nswap=n Number of blocks in the swap area the system can use for swapping and paging. The blocks used are s through s + n - 1 , inclusive (where s is the kernel.swplo value). Some drivers override the specified kernel.nswap and kernel.swplo values if they detect they are the swapping device; otherwise there is no default kernel.nswap value. kernel.dump=device The system image dump area. Should the kernel panic, an attempt is made to save the system's memory on this device for later analysis by crash(ADM). If a kernel.swap area is specified, it is the default dump area; otherwise the default is usually hd(41). The special device none means the kernel should not attempt to save a core image if the system panics. The alternative form kernel.dumpdev=device is equivalent. kernel.auto The system is automatically booting; init(M) should be started with an argument of -a. kernel.ronly The root filesystem is read-only. Under normal conditions, use of this option will prevent any changes from being made to the root filesystem and in normal use will probably cause your system to malfunction. It is intended for use only by the installation pro- cedure. kernel.inboard The motherboard is an Intel Inboard, which should be run in ``turbo'' mode with caching enabled. This bootstring argument does not need to be specified on Inboard-equipped systems (but it is use- ful for improving performance), and must not be specified on any other type of system. kernel.ignorefpu Do not use any 287 or 387 present for floating point computations; the (slower) floating point emulator will always be used instead. The default is to use any FPU found for floating point. This is useful if the FPU is suspected of malfunctioning or if the kernel incorrectly recognizes an FPU when one is not present. kernel.hd=xnamex The xnamex driver controls the primary hard disk; xnamex is the ``internal name'' of the driver specified in column 1 of its mde- vice(F) entry. By default, the kernel searches for a hard disk (which it assumes is the primary unit) by querying a pre-configured list of drivers for a hard disk controller which is present. kernel.disable=adapter1, adapter2, ... De-configure the pre-configured SCSI host adapters. The de-config- ured host adapters will not be used by the system. kernel.systty=xnamex [(m [,params, ...])] The system console is controlled by driver xnamex, and is minor de- vice m (default 0). Only the sio and cn drivers (xnamex) are sup- ported. The optional list of params specify the baud rate, charac- ter size, parity, and number of stop bits. The known baud rates include B50 (50 baud), B75, B110, B134, B150, B300, B600, B1200, B2400, B4800, and B9600 (9600 baud), plus the two undefined speeds EXTA (typically 19,200 baud) and EXTB. Only two character sizes are recognized: CS7 (7 bits) and CS8. By default, parity is neither checked nor generated. If PARENB is specified, parity generation and checking is enabled with a parity bit added to each character. Even parity is used unless PARODD (odd parity) is also specified. If CSTOPB is specified, two stop bits are used; normally, only one stop bit is used. For example: kernel.systty=sio(1,B1200,PARENB) would specify that the system console is /dev/tty1b (minor device 1 of the sio driver) at 1200 baud with even parity and one stop bit. See the termio(M) manual page for additional information. Normally, an alternative system console is specified by use of the systty=standalone command or the SYSTTY setting in the defaults file. Please see the section ``Selecting the system console'' for details. Note that the systty=standalone command and SYSTTY defaults setting use a different syntax than the kernel.systty boot- string argument. kernel.ct=type(base,irq,dma) Define the primary tape system connected to the system; by default, the ct driver searches a pre-configured list of tape controllers for one which is present. The type specifies the controller. The known controllers include: mountain, ibm6157, everex/archive, tecmar/wangtek, archive, compaq, and emerald. Not all types are recognized on all systems. The special type none means there is no primary tape (so if there actually is one, it is ignored and cannot be used). The base is an I/O port address; irq is the interrupt request (interrupt vector) number; and dma is the DMA channel. The base, irq, and dma must be specified unless the type is none. All drivers are interpreted as decimal unless preceded by "0x" for hexa- decimal or "0" for octal. kernel.adapter=host(base,irq,dma) Overrides the default hardware parameters for SCSI host adapter host1. kernel.xnamex=host(num, id, lun) Specifies the SCSI host adapter used by the generic SCSI interface driver (Sdsk, Srom or Stp). Specific drivers may use additional bootstring arguments; they do not have a module of kernel but usually use their internal name as the module: xnamex.name [=[ value ... ]] The name bootstring argument with optional value applies only to driver xnamex. Consult the individual driver manual pages for a description of the recognized bootstring arguments. Selecting the system console You can select the system console at boot time either by entering systty=digit standalone command at boot's prompt, or by placing the key- word SYSTTY=digit in the defaults file. The digit is either 0 or 1: _________________________________________________________________________ Digit Console _________________________________________________________________________ 0 Primary display adapter 1 Serial adapter at COM1 boot follows this procedure to determine the system console: 1. If there is a SYSTTY=digit in the defaults file, that defines the console. 2. If SYSTTY is not found or the defaults file is unreadable, boot checks for a display adapter and (if one is found) assigns it as the system console. 3. If no display adapter is found, boot looks for COM1. If the console is not a display adapter (that is, it is a serial port such as COM1), boot sets the serial port to the parameters specified by the SERIAL setting in the defaults file. See the description of the systty bootstring argument passed by boot to the UNIX kernel for a description of the possible params. The default params are B9600 (9600 baud), CS8 (8 data bits), one stop bit no parity. After determining the system console, boot prompts. You can then change the console recognized by the kernel by entering the systty=digit stan- dalone command. For example, to assign the system console to the serial port at COM1, enter this standalone command at the boot prompt: systty=1 To have boot automatically set the system console to the serial port at COM1 (on every boot), the line: SYSTTY=1 should be in /etc/default/boot. If the console is not the primary display adapter and the bootstring arguments passed to the standalone command do not include a kernel.systty bootstring argument as described in ``Configuring the kernel'', boot gen- erates an appropriate bootstring argument. Defining the available memory boot attempts to automatically determine how much RAM is in the machine, and where it is located. On most systems this automatic search succeeds in finding the memory. However, on some machines the search does not find all the available memory, or ``finds'' memory which does not actu- ally exist (or which should not or cannot actually be used). It is pos- sible to control where, and how, boot searches for RAM by using either the mem=standalone command or bootstring argument: mem= [ range ] [ /flag ] ... [ , ... ] The (optional) range is either: start - end The memory begins at address start and ends prior to address end. If the end is prior to the start, the two addresses are exchanged and the /d flag is assumed. start + size The memory begins at address start and continues for at most size bytes. (So end is equivalent to start + size.) The start and end addresses, and the size, are specified in either kilo- bytes (1024 bytes per kilobyte) or megabytes (1024 kilobytes per mega- byte); a suffix of k is kilobytes, and m is megabytes. For example, all of the following mean the two megabytes starting at address one megabyte: 1m-3m 1m+2m 1024k-3m 1m+2048k The k or m suffix is required. The (optional) flags are: /n This memory range is not DMAable. All memory above 16m is automati- cally marked non-DMAable. Only the standalone program's text is placed in non-DMAable memory by boot. /d This memory should be scanned downwards (from the end towards the start address); normally boot verifies the memory range by scanning from the start towards the end. Specifying /d is equivalent to giv- ing an end address lower than the start address. /r This memory range is reserved; boot must not load any part of the standalone program into it. However, the memory is available for use by the UNIX system. (To hide memory from both boot and the UNIX system, simply do not include it in any range.) /s This memory is ``special'' and is best used to load the standalone program's text (not data) section. ``Shadow RAM'' usually should be so marked, but shadowing RAM can only be used if the shadowing fea- ture is disabled. That is, if the shadow RAM is hidden by a ``sha- dowed'' copy of the machine's startup ROM, then the underlying RAM is inaccessible to both boot and the UNIX kernel and must not be used. Only the standalone program's text is placed in ``special'' memory by boot. /L The UNIX kernel's text must be loaded below 16m; this flag is recom- mended when booting earlier releases (that is, versions earlier than Release 3.2 Version 4.0) of SCO UNIX. /p Print a concise summary of the RAM found. This summary can be writ- ten down and used as the mem=input on a later attempt to force boot to find the same memory it found on this boot (provided none of the described RAM was removed in the meantime). All memory below 640k is automatically determined by the machine, and there is never any memory in the range 640k-1m. All mem= descriptions of this ``base memory'' below 1m are silently ignored. Hence, mem= should only be used to specify the extended memory configuration at and above 1m. The default mem= specification is equivalent to: mem=1m-16m,16m-256m/n on most machines (plus up to 640 kilobytes of base memory). boot scans each range and 16m-256m by default, stopping its scan as soon as no mem- ory can be found. Thus, if there is a ``hole'' in the specified memory range, all RAM above the first hole in the range will not be found by boot. Consider a machine with: + 512 kilobytes of base memory, + extended RAM from one to three megabytes, + some additional RAM from ten to twenty megabytes, and + 50 kilobytes of shadow RAM ending at 32 megabytes (shadowing disabled). By default, boot would only find: + 512 kilobytes of base memory, + extended RAM from one to three megabytes, and + additional RAM from sixteen (16) to twenty megabytes. Most of the RAM -- the six megabytes starting at address ten megabytes -- is not found (due to the hole starting at address three megabytes). Clearly then, on such a machine, it's advisable to define the memory which really exists. This machine can be specified as: mem=1m-3m,10m-20m,32718k-32m/d/s Note that 32718k is the address starting 50k before 32m. Since all mem- ory above 16m is automatically marked as non-DMAable, the above is equivalent to: mem=1m-3m,10m-16m,16m-20m/n,32718k-32m/d/s A simple: mem=/p will print out the automatically found memory (which is: mem=0k-512k,1m-3m,16m-20m/n on the example machine); to print out the memory found for a specific configuration, /p must be included in the mem= specification. Thus, add- ing /p to the first specification above: mem=1m-3m,10m-20m,32718k-32m/d/s,/p would print out the equivalent of the second definition (on the described machine): mem=0k-512k,1m-3m,10m-16m,16m-20m/n,32718k-32m/d/s On most machines boot scans the defined memory ranges and deletes from the definition any RAM not actually found. Thus, if the following is specified on the described machine: mem=1m-5m,12m-25m,31m+1m/d/s,/p the printed result would be: mem=0k-512k,1m-3m,12m-16m,16m-20m/n,32718k-32m/d/s Note that the RAM from ten to twelve megabytes, despite existing, was not found by boot, because it was excluded from the mem= definition. On most machines, shadowing must be disabled using the machine's setup procedures. boot automatically disables startup ROM shadowing only on a few machines. The RAM hidden by shadowing the startup ROM cannot be used by boot or the UNIX kernel unless the shadowing is disabled. Boot-time loading of device drivers Some device drivers can be added to the loaded UNIX kernel by boot prior to the kernel starting to run. Such a driver is called a BTLD: Boot- Time Loaded device Driver. The boot-linker (which does the boot-time loading) is invoked by either entering the link standalone command or by giving the link=bootstring argument. BTLDs are distributed in ``packages''. The link standalone command prompts for the names of the packages to boot-load: What packages do you need linked into the system, or q to quit?: pkg1 pkg2 and the link=bootstring argument takes the names of the packages as its value: link="pkg1 pk2" The link standalone command causes any link=bootstring argument to be ignored. After the UNIX kernel is loaded, each package pkg is prompted for. The appropriate diskette should be inserted into the drive. If the package name (pkg) does not include a device, the default device defined by the bltd (or btlddev) bootstring argument device is used. That is usually the same media as boot was loaded from. The diskette should contain the files described in btld(F). For each driver listed in /pkg/install/btld the same process is repeated (an error in a preceding step aborts the link and subsequent steps are not done): 1. The driver's Master, System and Bootload files (if any) are read. 2. The appropriate object modules (as defined in Bootload) are loaded; the default is Driver.o and Space.o. 3. Any tune-able parameters (defined in Bootload) are prompted for. 4. The function dispatch tables defined in Master, and any tuneed or patched symbols are adjusted. If any conflicts occur (for example, if the interrupt vector that the boot-loaded driver wants to use is already occupied by another driver), boot explains the problem, lists the possible resolutions, and prompts for what to do about the con- flict. Please see the section on ``Resolving BTLD conflicts'' for details. 5. Unresolved references in the object modules are resolved. The boot-linker queues the changes to the UNIX kernel (step 4), so if there is a problem in resolving references (step 5) the linking can be aborted without forcing a reboot: the loaded kernel has not been changed. The queued changes to the kernel are not applied until the relinking (step 5) has completed successfully. If every driver in the package was successfully linked by the boot- linker, the first line of the file /pkg/install/bootstring is appended to the bootstring and the name of the package is added to the ``package string'' passed to the UNIX kernel. The package string can be read from the special file /dev/string/pkg. Hardware usually has jumpers, switches, or a DOS (or standalone) setup program to configure the board. When boot-loading the drivers for such boards, the tune directive in the Bootload file (see btld(F)) causes boot to prompt for the settings of these jumpers or switches. The information boot may prompt for includes: vector The interrupt vector or IRQ used by the hardware. DMAchan The channel used by the hardware to directly access memory. SIOA Base or start I/O register address of the board. EIOA Ending (or extra) I/O register address of the board. SCMA Start or base bus, controller, or dual-ported memory address used by the board. ECMA Ending bus, controller, or dual-ported memory address used by the board. units Number or size of the peripherals attached to the board. The manufacturer's instructions should say how to set the jumpers or switches, and what to reply in response to any prompts. Resolving BTLD conflicts The Master and System files on the BTLD diskette instruct the boot-linker how to configure the boot-loaded driver into the loaded kernel. Three types of conflicts with drivers already present in the kernel may occur: 1. Another driver is already using the major device number the boot- loaded driver wants to use. 2. Another driver already occupies the interrupt vector the boot-loaded driver wants to occupy. 3. A function dispatch table is full and so the appropriate boot-loaded driver's function cannot be added to the table. When a conflict is detected, boot explains the problem and offers several possible ways of dealing with the issue. If there is a comparatively safe alternative, that is the default resolution. There are several answers which may always be given: q Quit: The boot-linking of this driver is stopped; the kernel has not been changed. RETURN Use the default answer (if any). M List the major device numbers and associated drivers. I[ vecno ] Display interrupt vector vecno (0-255). Tfuncs Prints the function dispatch table funcs; some of the dispatch tables include ioinit, iostart, and iohalt. The major device number is how the UNIX kernel refers to a specific driver. Each driver is identified by its unique major number. When boot-loading a driver, major numbers may present a problem because: + The Master file specifies a major number which is already in use. + The Master file does not specify a particular major number, but there are no available (free) major numbers. + The driver is both a block and character device, but the block and character major numbers specified in the Master file differ. + The major number specified in the Master file is out-of-range. + Another driver has the same internal name (column 1 mdevice(F)). This should never happen unless you are boot-linking a driver to a kernel which already contains that driver; doing so (called ``driver replace- ment'') is unreliable. The possible resolutions include: a Add the driver using an available (free) major number. number Use major number; if that major is in use, boot prompts again to confirm the choice. r Replace the ``other'' driver (which has either the same inter- nal name or is using the desired major number). This is inherently unreliable, not supported, and is never recommended. Major device number conflicts are unlikely to occur. Should one occur, boot's default (if possible) is a -- add the driver using an available major number. The initial system installation procedure does not rely on boot-loaded drivers using any specific majors, even if the Master file gave a specific value. (However, there may be conflicts later when the driver is added to the kernel using the Link Kit.) Most devices use interrupts. When they complete, or are ready to do some I/O, they asynchronously notify the CPU and wait for a response. Drivers for devices which use interrupts usually have an interrupt-handling pro- cedure and priority defined in the System file (columns 6 and 7 in sde- vice(F)). Some drivers want the boot-linker to install the handler at the specified priority; these drivers have a non-``0'' type (column 5 in sdevice(F)) in the System file and no G characteristic in Master. Other drivers only want the boot-linker to check that the driver itself should be able to later install its handler at that priority; these drivers also have a non-``0'' type but include the G characteristic. When boot- linking a driver, interrupt handlers (or ``vectors'') and priorities (or IPL -- ``interrupt priority level'') can be a problem because: + There is another handler of the same name at this vector. This should never happen unless you are boot-linking a driver to a kernel which already contains that driver; such driver replacement is unreliable. + The boot-loaded driver wants exclusive use of the vector, but the vec- tor is already in use. (The driver's type is 1 or 2.) + The boot-loaded driver is willing to share use of the vector, but the vector is in use by another driver that wants exclusive use. (The driver's type is 3 or more, but the vector is occupied by a type 1 or 2 handler.) + The vector is full and cannot be shared with any more handlers. + The vector is in use and sharable but the priority (IPL) is wrong. The possible resolutions depend on whether or not the boot-linker should actually configure the handler or just check the configuration. If the boot-linker is only checking the configuration (the driver has the G characteristic), the possible answers include: d Delete all handlers from the vector. The corresponding devices probably cannot be used, or the system may not function prop- erly. number Delete a specific handler from the vector. That device prob- ably cannot be used or the system may not function properly. A ? lists the handlers using the vector. s Convert an unsharable vector into one which can be shared. This may result in a handler not designed to share a vector nonetheless sharing a vector; the system may not function prop- erly. If the boot-linker should configure the handler into the system, the pos- sible answers include: number Which handler already installed in the vector should be replaced by the boot-loaded driver's handler. The device con- trolled by the replaced driver probably cannot be used and the system may not function properly. a Add the boot-linked driver's handler to the vector. The system should work unless the vector was unshareable (and hence had to be converted to a sharable vector); if such a conversion is done, the system may not function properly. r Replace the entire list of handlers sharing this vector with the boot-linked driver's handler. Probably none of the replaced devices can be used or the system may not function properly. An additional resolution is always possible: n Do nothing. The boot-loaded device probably cannot be used, or the system may not function properly. If a vector is already in-use, the interrupt priority level (IPL) may need to be adjusted: l The boot-loaded driver's IPL is less than that of the vector; lower the vector's IPL to that of the driver. r The boot-loaded driver's IPL is greater than that of the vec- tor; raise the vector's IPL to that of the driver. c Keep the vector's current IPL ignoring the driver's setting. number Set the vector's IPL to number (1 - 7 inclusive). Since the system will probably malfunction if the driver's interrupts occur with a higher priority that the driver was designed for, r (raise) is never recommended. Whichever of l (lower) or c (current) that results in the least IPL (lowest priority) is always recommended. Interrupt vector and priority conflicts are the most common problems encountered when boot-linking a driver to a kernel. The best resolution is to shut down the machine, change the IRQ (interrupt vector) setting on board using the jumpers, switches or software setup as per the manufac- turer's instructions, and try the boot-link again. Hardware which has jumper or switch selectable configuration parameters is preferable to ``hard-wired'' (fixed) equipment. The boot-loadable drivers for jumper or switch selectable boards should use the tune directive in the Bootload file to prompt for the settings of the switches or jumpers. The new values should be entered in response to the prompts, as per the manufac- turer's instructions. If the hardware does not have a switch-, software- or jumper-selectable IRQ, or the boot-linker fails to prompt for values, there is no ideal resolution. If possible, boot's default action is either s (convert an unshareable vector into a shareable one) or a (add the handler to the vector, converting the vector if necessary). Either may result in an uninstallable system. Function dispatch tables list driver routines called on certain events (such as system startup or shutdown). Problems which may arise when add- ing a boot-linked driver to these tables include: + The dispatch table is full. + There already is another routine of the same name in the table. This should never happen unless you are boot-linking a driver to a kernel which already contains that driver; such driver replacement is unreli- able. The possible resolutions include: number Replace a routine already in the dispatch table with the boot-linked driver's routine. a Add the driver's routine to the table. n Do nothing; the driver's routine is not added. The boot-linked de- vice may not work. Dispatch table conflicts are unlikely to occur. Should one happen, boot's default (if possible) is a -- add the driver's function to the end of the table. Default file settings The defaults file is used by several programs involved in the startup process, including boot itself and init(M). The default defaults file is /etc/default/boot on the filesystem from which boot was loaded; however, this can be changed for boot only by use of ALTDEF, described below. All keywords and aliases boot recognizes are n the form: name [ = ] value If no = is used, one or more tabs or spaces should separate the name from the value. An = separating name from value may be preceded or followed by spaces and tabs. Programs other than boot which read the defaults file require the = and do not allow spaces or tabs. The keywords boot recognizes include: ALTDEF=defaults The file defaults, if it exists, is used instead as the default file (for boot). This process is repeated up to 100 times. AUTOBOOT=YES or NO If YES, boot automatically loads the UNIX kernel as per the defbootstr setting after waiting for input for the time specified by TIMEOUT. The default is NO. RONLYROOT=YES or NO Whether or not the root filesystem is mounted readonly. This must be used only during installation, and not for a normal boot. It will effectively prevent writing to the filesystem. TIMEOUT=n How many seconds to wait for input after the first prompt before assuming an answer of RETURN (thus causing the defbootstr to be used). Applies only when AUTOBOOT is YES; default is 60 seconds. SYSTTY=digit If digit is 0, the system console is the display adapter; if 1, the system console is COM1. Please see the section ``Selecting the sys- tem console'' for details, including the default console search pro- cedure. SERIAL=param1, param2, ... List of parameters specifying the baud rate, character size, parity, and number of stop bits of the serial console (SYSTTY=1). The params are the same as for the kernel.systty bootstring argument. Please see the section ``Selecting the system console'' for details, including the default values. PWRCHECK=Y or N Applies only to some machines equipped with a built-in uninterrupti- ble power supply (UPS): if Y, checks the mains and battery condi- tion; if the battery is low or the mains power has failed, warns that the system probably should not be booted. Default is N; note that this option applies only to a few machines and almost all available systems cannot use this facility. defbootstr=standalone arguments ... The standalone program to run (with optional arguments) when only a RETURN is entered or when AUTOBOOT=YES and nothing is entered within TIMEOUT seconds. standalone=definition boot checks to see if the entered standalone command is defined (or ``aliased'') in the defaults file; if it is, its definition is sub- stituted for the entered standalone command, with any entered argu- ments appended to the end. For example, if boot was loaded from the hard disk (hd(40)) and the entered command was: test mem=1m-12m and test is aliased as: test /etc/conf/cf.d/unix prompt="Ready? " then the result bootstring is: hd(40)/etc/conf/cf.d/unix prompt="Ready? " mem=1m-12m By convention, standalone aliases (including defbootstr) are lower- case and keywords are UPPER-CASE, but boot will recognize both aliases and keywords in either case. (However, the case of the values, such as YES and NO, must be UPPER-CASE as shown above.) Several other commands besides boot involved in the bootup procedure also use the /etc/default/boot file. init(M) recognizes the keywords: MAPKEY=YES or NO SERIAL8=YES or NO PANICBOOT=YES or NO Whether or not the system reboots after a panic; default is NO. MULTIUSER=YES or NO SLEEPTIME=n Seconds between sync(S); that is, seconds between periodically forc- ing all cached-but-unwritten dirty (new or changed) blocks to be written to the disk. Default is 60 seconds (one minute). SPAWNINTERVAL=n If an inittab entry is respawned SPAWNLIMIT times within this amount of time (seconds), init will not try to respawn that entry for INHIBIT seconds (unless a ``telinit q'' is done). The default value is 120 seconds. SPAWNLIMIT=n If an inittab entry is respawned this many times within SPAWNINTERVAL seconds, init will not try to respawn that entry for INHIBIT seconds (unless a ``telinit q'' is done). The default value is 10 attempts. INHIBIT=n If an inittab entry is respawned SPAWNLIMIT times within SPAWNINTERVAL seconds, init will not try to respawn that entry for this many seconds (unless a ``telinit q'' is done). The default value is 300 seconds (five minutes). DEFAULTLEVEL=n The run-level to enter when leaving single-user mode. Diagnostics If an error occurs, masterboot displays an error message, and locks the system. The following is a list of the most common messages and their meanings: IO ERR An error occurred when masterboot tried to read in the parti- tion boot of the active operating system. BAD TBL The bootable partition indicator of at least one of the operat- ing systems in the fdisk table contains an unrecognizable code. NO OS There was an unrecoverable error that prevented the active op- erating system's partition boot from executing, or there was no active partition. When boot displays error messages, it returns to the ``Boot'' prompt. The following is a list of the most common messages and their meanings: bad magic number The given file is not an executable program. can't open <pathname> The supplied pathname does not correspond to an existing file, or the device is unknown. Stage 1 boot failure The bootstrap loader cannot find or read the boot file. You must restart the computer and supply a filesystem disk with the boot file in the root directory. not a directory The specified area on the device does not contain a valid UNIX filesystem, or the given pathname tries to pass through a file (e.g. /bin/sh/foo). zero length directory Although an otherwise valid filesystem was found, it contains a directory of apparently zero length. This most often occurs when a pre- System V UNIX filesystem (with incorrect, or incom- patible word ordering) is in the specified area. fload:read(x)=y An attempted read of x bytes of the file returned only y bytes. This is probably due to a premature end-of-file. It could also be caused by a corrupted file, or incorrect word ordering in the header. Error: request outside range of BIOS (1023 cylinders) The low level hard disk transfer routine was unable to load a file because it lay on or beyond the 1024th cylinder of the boot device. This message is usually followed by another error message indicating the file which which was being read when the failure occurred. The boot prompt is then displayed. The prob- lem occurs when the kernel or /etc/default/boot are inaccessible to the BIOS disk transfer routine which is used to read the hard disk. This problem only occurs on large disk systems. The solution is to move the file so that it lies within the first 1024 cylinders on the boot device. Limitations The computer tries to boot off any diskette in the drive. If the diskette does not contain a valid bootstrap program, errors occur. The boot program cannot be used to load programs that have not been linked for standalone execution. To create standalone programs, the -A option of the UNIX linker and special standalone libraries must be used. Stand-alone programs can operate in real or protected mode, but they must not be large or huge models. Programs in real mode can use the input/output routines of the computer's startup ROM. Some of the UNIX kernel's bootstring arguments should not be using a module of kernel; these historical exceptions include kernel.ct. All new driver-specific keywords should use a module name of xnamex, where xnamex is the internal name of the driver. Older systems do not recognize module name prefixes, and so boot omits kernel from any keywords it automatically adds, such as auto and systty. The boot-linker cannot and does not detect all the errors detected by the ld(CP) linker and the idconfig and idbuild configuration tools (see idbuild(ADM)). It is possible to boot-link to a kernel a driver which could not otherwise exist in that kernel. This behavior should not be relied upon. Files /boot /etc/default/boot /etc/masterboot /etc/hdboot0 /etc/hdboot1 /etc/fd135ds18boot0 /etc/fd135ds9boot0 /etc/fd48ds9boot0 /etc/fd96ds15boot0 /etc/fd96ds18boot0 /etc/fd96ds9boot0 /dev/string/boot /dev/string/pkg /unix See also autoboot(ADM), badtrk(ADM), crash(ADM), fd(HW), fdisk(ADM), fsck(ADM), haltsys(ADM), hd(HW), idbuild(ADM), idconfig(ADM), init(M), ld(CP), screen(HW), serial(HW), shutdown(ADM), string(M), sulogin(ADM), systty(M), btld(F) Device Driver Writer's Guide Standards conformance boot is not part of any currently supported standard; it is an extension of AT&T System V provided by The Santa Cruz Operation, Inc.