PC Bios is actually a multi-level “monitor” Each device may have it’s own BIOS that is run by the master BIOS. The device BIOS initializes the individual device, and reports the status to the master. The master collects the results and tabulates this information for the OS.
The Apple Monitors Due to this limited functionality, many sysadmins do not consider that the Apple machines contain a viable a PROM monitor. In fact, there is a PROM monitor in the new Apple systems, albeit the user interface is still extremely limited! None of this mattered too much in the past, as the only OS that would run on an Apple computer was MacOS. Current- generation Apple computers can boot and run legacy MacOS, MacOS X (a UNIX-like OS), and Linux. In order to boot these alternate OS’s on an Apple required some form of a boot PROM. RS6000, SGI, and HP PROM monitors are functionally similar to the Sun monitor, but the user interface is very different. Refer to chapter 4 for more information on these monitors.
The boot block is often contained in the system PROM. This program knows how to find the primary storage interface. It looks in a specific location on the storage media, and loads the next “N” blocks of data into the system memory. Once the data is loaded into memory, the system attempts to “run” the data as though it were a program. If things went well, the data is a program, the secondary boot loader.
The secondary boot loader is usually tailored to specific operating systems. The boot loader knows how to find/load/start a specific OS kernel. Recently, secondary boot loaders have become more intelligent, and many now know how to locate/load/start several Operating System kernels. These loaders are possible, because the OS vendors have published information telling how their boot loaders work, and where they expect to find the information required to load the kernel, and boot the system. A good example of this type of boot loader is the GRand Unified Boot loader (GRUB).
WARNING: Early versions of MacOS X contain a nasty security hole.; if a user holds down the Command and “s” keys during a reboot, the system will come up in single- user mode, without prompting the user for the root password.
The easiest way to “add” a new service to a BSD box is to develop a rc.servicename script, and test it manually. Once the script seems to work manually, edit the master /etc/rc script, add the lines required to make the master script call the new script. Then reboot the system (when convenient) to test that the script works in automatic mode. At this point you may want to roll the new script into one of the existing scripts, but that will require further testing, and another downtime (or two) in order to ensure that things work the way that you expect them to.
Sometimes OS level commands just won’t help. If thte system is completely hung, and ignoring keyboard input, sometimes you have to take drastic steps. SPARC hardware includes a special key sequence that is processed by the PROM monitor. If you hold down the STOP key, and press the A key at the same time, the system will revert to the control of the PROM monitor. At this point, you can use the “sync” command to cause the sytem to sync all memory to disk, and perform a controlled “crash and burn” reboot of the system. On PC systems, the CONTROL-ALT-DELETE will often accomplish the same result as the STOP-A will on a Sun.
The boot block’s job is to initialize some of the system’s peripherals and memory, and to load yet another program, the secondary boot loader , (sometimes known as the boot manager ) that will load the OS kernel.
A boot block is typically placed on the disk as part of the OS installation process. The sysadmin should be familiar with the similarities and differences between the following boot blocks:
One of the benefits of using init directory scripts is that they are easily tested.
The scripts may be manually invoked with the stop and start arguments as a check to determine whether they function correctly before creating the links to the rc directories, and trying them under actual system boot conditions.
This procedure is recommended because it can help you catch mistakes that might interrupt the boot process and leave the system unusable.