After you install Windows 2000,
a small, hidden, read-only text file—boot.ini—exists in the boot partition's
root directory. This file is an important component in the machinery that
controls the OS startup processes. The installation process creates the file's
contents, so boot.ini is specific to the computer. Understanding boot.ini's format, its likely content, the conventions that
its content follows, and your options for manipulating the file gives you two
important elements of control over a system. First, you can change the file's
contents to modify the startup process. Second, you can create a boot.ini file
to repair a computer that won't boot.
You can edit boot.ini in any
text editor. Before you do so, I suggest you copy the original file to a
3.5" disk
in case your changes wreak havoc. Boot.ini is read-only, so you must change
that attribute before you can save your edits. (Of course, don't forget to
restore the read-only attribute when you've finished editing.)
Content: Boot.ini's Sections
All .ini files follow the same format rules. The
contents are arranged in sections, and each section has a title enclosed in
square brackets. As the figure below
shows, boot.ini has two sections: [boot loader] and [operating systems].
The [boot loader] section
contains a timeout specification and a pointer to the default OS's location. The timeout specification is the amount of
time, in seconds, during which users can make a selection from the onscreen
menu that appears when users have a choice of startup options. By default, the
timeout duration is 30 seconds, and the default OS loads if users fail to make
a choice within that time.
Typically, a choice of startup
options occurs when more than one OS exists on the system (e.g., you updated a
previous OS to Win2K and kept the previous OS, you installed two versions of
Windows).
A choice also exists when you've
installed the Recovery
Console (RC), which automatically adds the Microsoft Windows 2000 Recovery
Console option to the onscreen menu. (The RC is an advanced feature that you
can use to repair a broken installation. For information about this feature,
see Sean Daily, "Mastering the Recovery Console," July 2000.)
When users have no choices, no
onscreen menu appears. The system ignores the timeout specification and
immediately begins the OS startup.
Boot.ini's [operating systems] section contains the
path or paths to the OS or OSs on the computer. As
Figure 1 shows, text strings enclosed in quotation marks represent the text
lines that the onscreen menu displays. You can edit the onscreen text to
provide special instructions. For example, if you install a beta version of the
next Windows version, you can edit the text to say Not for production.
Conventions: ARC Path Statements
The [boot loader] section's OS location information and the [operating systems]
section's OS path information both follow the conventions in the Advanced RISC
Computing (ARC) specifications. Win2K recognizes three ARC path structures:
multi syntax, SCSI syntax, and signature syntax.
Multi syntax. Systems that utilize IDE hard disks
commonly use the multi syntax in boot.ini. Using the multi syntax tells Win2K
to depend on the computer BIOS to load the system files. The OS uses INT 13
BIOS calls to find the disk that holds ntoskrnl.exe and the other files the
system needs to boot the OS. You can also use the multi syntax for SCSI drives
if the SCSI device is configured to use INT 13 calls instead of the device's
BIOS settings.
In theory, the multi syntax can
identify any drive that the standard INT 13 interface identifies. In reality,
most system BIOS structures can identify only one disk
controller through INT 13, so you can usually use the multi syntax to launch
Win2K from one of only the first two drives attached to the primary disk
controller. (If you have a cooperative BIOS, you can use the multi syntax for
as many as four drives across two controllers.) A multi syntax line reads as
follows:
multi(<A>)disk(<B>)rdisk(<C>)partition(<D>)
A is the ordinal number for the boot
adapter. The first adapter, which is usually the boot adapter, is 0. B
provides disk-parameter information. In a multi syntax line, this variable is
always 0 because the multi syntax uses the INT 13 call instead of a
self-discovery method.
C is an ordinal number that specifies the
disk attached to the adapter; the number can range from 0 to 3, depending on
the number of drives on the adapter. D specifies the partition number;
the first possible number is 1 (as opposed to adapters and drives, which begin
numbering with 0).
SCSI syntax. Your computer probably uses the SCSI
syntax if you boot Win2K from a SCSI device. The SCSI syntax tells Win2K to use
a device driver for the controller, rather than depend on the system BIOS and
INT 13 calls, to access the boot partition. The device driver is always named ntbootdd.sys and resides on the system partition's root. To
create ntbootdd.sys, Win2K Setup copies the specific
driver for the SCSI drive to the hard disk. Win2K then renames the file ntbootdd.sys. Usually, Win2K copies the driver from the
Win2K CD-ROM (which contains drivers for the vast majority of SCSI adapters),
but if you use a manufacturer-supplied driver, Win2K copies and renames that
file. The SCSI syntax line is as follows:
scsi(<A>)disk(<B>)rdisk(<C>)
partition(<D>)
A is the ordinal number for the adapter
linked to the ntbootdd.sys driver. B is the
SCSI ID for the target disk on that adapter. C is the SCSI LUN that contains
the boot partition. (Although this LUN could be a separate disk, most SCSI
setups have only one LUN per SCSI ID.) D specifies the partition number.
If you have multiple SCSI
controllers, each of which uses a different device driver, A specifies
the controller linked to ntbootdd.sys. During setup,
Win2K determines—usually as the result of your specification for the
installation partition—which controller to use. Even if your SCSI drive can
work with INT 13 calls, using the SCSI syntax is preferable (and usually less
error-prone) because it forces the OS to use the ntbootdd.sys
data during startup.
Signature syntax. The signature syntax is technically the
same as the SCSI syntax, but the installation program uses the signature syntax
to support Win2K's Plug and Play (PnP) architecture. The signature syntax line
is as follows:
signature(<A>)disk(<B>) rdisk(<C>)partition(<D>)
A is the disk signature (e.g., 6c156c97);
the other variables are the same as for the SCSI syntax. A is a unique
hexadecimal number that Win2K Setup writes to the Master Boot Record (MBR)
during the Setup process's text-mode portion.
Using the signature syntax
forces NT Loader (NTLDR)—the first file that Win2K launches to start the OS—to
locate whichever drive has a disk signature that matches the A value
during OS startup. Keep in mind that this drive might connect to a different
SCSI controller number than when you first installed Win2K if you've added SCSI
controllers to the machine. As with the SCSI syntax, the signature syntax requires
a copy of the specific SCSI driver, renamed ntbootdd.sys,
on the drive's root.
Win2K Setup determines that it
should use the signature syntax under certain conditions. The most common
conditions are when the drive has more than 1024 cylinders (which creates a
problem if any cylinder number greater than 1024 is in the system partition) or
when the SCSI controller's BIOS is disabled.
Tweaking Boot.ini
You can edit boot.ini to change or enhance the startup process. You can also
edit the file to troubleshoot a computer that's having problems.
Changing the default OS. You can change a system's default OS and
the length of the timeout that boot.ini offers users. You can make these
modifications without editing the boot.ini file; simply use the System Properties
dialog box. (To quickly access this dialog box, right-click My Computer and
choose Properties from the shortcut menu.) Move to the Advanced tab, and click Startup
and Recovery to open the Startup and Recovery dialog box, which the picture
below shows. Select the desired OS from the Default operating system
drop-down list in the System startup section.
Figure 12
Use the section's Display
list of operating systems for x seconds option to change the timeout
specification. Don't shorten the time to less than 10 seconds or users won't
have time to read the options and select one. (Although you can clear the box
to prevent display of the onscreen menu, I recommend against it. If you have to
perform some administrative task that involves another OS, you'll need to go
through all these steps again to redisplay the menu and gain access.)
In Win2K, you can't specify 1
as the timeout duration to leave the menu on the screen until the user makes a
choice, as you can in Windows NT. Win2K's Startup and Recovery dialog box
doesn't accept a negative number. If you manually edit boot.ini and change the
timeout duration to 1, Win2K ignores the entry and resets the timeout to the
previous specification during the next boot.
To keep the menu onscreen, a
user can press any key except the Enter key (e.g., users can click an arrow key
to highlight a different choice). Of course, this trick requires user intervention,
so it is of no help unless the user is available to press a key. The user can't
turn on the computer and head for the coffee machine and expect the menu to
still be onscreen when he or she returns.
Troubleshooting. Boot.ini takes a substantial number of
parameters, most of which are useful under specific conditions—usually when
you're troubleshooting a serious problem. The file also requires certain
switches to support specific hardware configurations. Table 1 lists several
common boot.ini switches and their functions.
Creating an emergency boot
disk. If one of the
Win2K startup files is missing or corrupt and the Windows File Protection (WFP)
feature fails to correct the problem automatically, you can usually boot with a
Win2K boot disk to replace the file. Because OS startup is totally dependent on
the information in boot.ini, you must provide a boot.ini file on the boot disk,
even if boot.ini isn't the corrupted or missing file.
To create a boot disk, format a
3.5" disk on another Win2K computer. Copy NTLDR and ntdetect.com from that
computer's root to the 3.5" disk. These files aren't version specific, so
the source computer can be running any version of Win2K Server or Win2K
Professional.
If the source computer has
exactly the same hard disk setup (i.e., same drive type, same drive, and same
partition for the OS installation) as the computer you're troubleshooting, you
can copy and use the source computer's boot.ini file as is. Otherwise, copy the
boot.ini file onto the 3.5" disk, gather the necessary information about
the destination computer's physical drive type, and edit the file's [operating
systems] section information to create a viable boot.ini. Use the boot disk to
boot the destination computer, and overwrite the corrupted file or files from
the 3.5" disk.
Understanding what boot.ini
does, and how it does it, gives you the power to control the OS startup
process. This capability is especially important if you need to troubleshoot a
computer that's producing blue screens of death because Microsoft Product
Support Services (PSS) might ask you to edit boot.ini and add switches that
help the debugging effort.
|
||||||||||||||||||||||||||