BOOT(8) | System Manager's Manual (alpha) | BOOT(8) |
boot
—
SRM can bootstrap from supported local storage devices, e.g., IDE disks or CD-ROM drives, SCSI disks or CD-ROM drives, and floppy drives. SRM can also network bootstrap via supported Ethernet interfaces, using BOOTP or MOP. The particular capabilities of SRM will vary from system to system.
When SRM boots the system, it performs a Power On Self Test (POST), probes the system busses to identify devices, and initializes them. SRM includes an x86 instruction emulator in order to run the BIOS initialization routines found in the PROM of any video cards found. In this way, most generic PCI video cards can work in Alpha systems that have PCI bus slots.
SRM then examines the state of one of several variables:
auto_action
. If the value of
auto_action
is “halt” then SRM will
stop, print its prompt: “>>>” and wait for commands
to be entered on the console. If the value of
auto_action
is “boot” then SRM will
automatically bootstrap the operating system specified by various
non-volatile environment variables.
SRM device names are not the same as in
NetBSD, e.g., ewa0 is a DEC
“tulip” Ethernet interface, dka0 is a SCSI
disk on a recognized controller, dqa0 is an IDE disk on a
recognized controller. The show device
command will
list all the devices that SRM can bootstrap from.
show config | more show * | more
An essential but incomplete list of SRM commands follows:
boot
[-file
filename] [-flags
value] [device]
Boot an operating system. The default arguments for this command are taken from the SRM environment variables:
boot_file
boot_osflags
bootdef_dev
help
[command]
Invoke the SRM help system.
init
Reset the SRM console, and take actions as specified by SRM variables.
set
variable
value [-default
]
Set an SRM variable, e.g.,
set auto_action boot set bootdef_dev dka0 set ewa0_mode auto
If the -default
flag is used, the variable
will be set to its default value.
show
variable or
subsystem
Show SRM variables and values, or show system state or configuration. If a wildcard is used, then all matching SRM variables are shown, e.g.,
show
*
show
b*
show
config
show
device
show
memory
auto_action
Some Alpha systems (e.g., AlphaServer 800) have a “halt” switch, which if set, will override the action of this variable, and cause SRM to stop after POST and prompt the user for commands to execute.
bootdef_dev
show
device
command will list the available and recognized bootable
devices.boot_file
boot_osflags
DEBUG
; See
options(4).DDB
or
KGDB
; See
options(4).These may be used in combinations that are not mutually exclusive. These options are case-insensitive to be compatible with DEC operating systems.
console
Just as with Sun systems, Alpha systems will use the first
serial port as a console if there is no keyboard plugged into the
keyboard port, even if console
is set to
“graphics”.
ew*0_mode
auto
(IEEE 802.3u “Nway”
negotiation), BNC
, AUI
,
Twisted-Pair
, FastFD
(Fast
Full Duplex).ew*0_protocols
The Alpha SRM firmware is picky about BOOTP responses; the dhcpd.conf(5) on the server needs the
always-reply-rfc1048 on;
directive in the section for netbooting Alpha systems.
os_type
The proper way to shut the system down is with the shutdown(8) command.
If the system crashes, it will enter the kernel debugger, ddb(4), if it is configured in the kernel. If the crash occurred during initialization and the debugger is not present or is exited, the kernel will halt the system.
If the crash occurred during normal operation and the debugger is not present or is exited, the system will attempt a dump to the configured dump device (which will be automatically recovered with savecore(8) during the next bootstrap cycle), and after the dump is complete (successful or not) the kernel will attempt a reboot.
Alpha Architecture Reference Manual Third Edition, Digital Press, Alpha Architecture Committee, 1998.
February 17, 2017 | NetBSD 9.4 |