setboot(1M)setboot(1M)NAMEsetboot - display and modify boot variables in stable storage
SYNOPSIS
primary-path] HA_alternate-path] alternate-path]
DESCRIPTION
The command displays and sets boot variables in stable storage (also
known as nonvolatile memory). Any user can display the values; only a
superuser can change them.
On all systems, the variables are: primary path, alternate path, HA
alternate path (if applicable; see option), flag, and flag. If Speedy‐
Boot is installed, the variables expand to include: early CPU tests,
late CPU tests, memory initialization (on Integrity systems), full mem‐
ory tests, processor hardware tests (on PA-RISC), platform dependent
tests (on Integrity systems), IO Hardware tests (on Integrity systems),
chipset tests (on Integrity systems), and central electronic complex
tests (on PA-RISC), hyperthreading (on some Integrity systems).
With no options, displays the current values for the primary boot path,
alternate boot path, HA alternate boot path, and the and flags. If
SpeedyBoot is installed, also displays the status of the CPU, memory,
hardware, and electronics tests. If the platform supports hyperthread‐
ing, displays whether processor hyperthreading is enabled/disabled for
current and subsequent system boots.
SpeedyBoot
The SpeedyBoot firmware and software extensions allows a superuser to
control which firmware tests are executed by the system during the boot
process. The tests settings can be specified both for all subsequent
boots and for the next one only. They are described in the section
below.
The and options of the command provide the user interface to the
firmware tests. Currently options is not supported on Integrity system
architecture.
SpeedyBoot augments the test control that is available on systems that
have the Boot Console Handler (BCH). By turning off some or all of the
boot tests, you can shorten boot time appreciably. However, in the
event of a system panic or boot failure, all tests are executed on the
subsequent boot.
SpeedyBoot Tests
The SpeedyBoot tests and the possible display values on a PA-RISC plat‐
form are summarized in the following table:
Test Current Supported Default NEXT BOOT
────────────────────────────────────────────────────────────────────────────────
all on|off|partial yes|no|partial on|off|partial on|off|partial
SELFTESTS on|off|partial yes|no|partial on|off|partial on|off|partial
early_cpu on|off yes|no on|off on|off
late_cpu on|off yes|no on|off on|off
FASTBOOT on|off|partial yes|no|partial on|off|partial on|off|partial
full_memory on|off yes|no on|off on|off
PDH on|off yes|no on|off on|off
CEC on|off yes|no on|off on|off
────────────────────────────────────────────────────────────────────────────────
The SpeedyBoot tests and the possible display values on an Integrity
platform are summarized in the following table:
Test Current Default
──────────────────────────────────────────────────────
all on|off|partial on|off|partial
SELFTESTS on|off|partial on|off|partial
early_cpu on|off on|off
late_cpu on|off on|off
FASTBOOT on|off|partial on|off|partial
Platform on|off on|off
Full_memory on|off on|off
Memory_init on|off on|off
IO_HW on|off on|off
Chipset on|off on|off
──────────────────────────────────────────────────────
Test The keyword names of the tests that can be
controlled by SpeedyBoot. See section below.
Current The current enablement of each test. means
the test is normally executed on each boot.
means the test is normally omitted on each
boot. means some of the subtests are normally
executed on each boot. On Integrity platform
any test modified using the option will be
reflected in Current.
Supported Whether the test is supported by the system
firmware. means the test is supported. means
the test is not supported. means some of the
subtests are supported. On Integrity plat‐
form, this Column is not supported.
Default The default values for each test. and are the
same as for Current.
NEXT BOOT The values for each test that will be used on
the next boot. If they are different from
Current, the Current values will be reestab‐
lished after the next boot. and are the same
as for Current. On Integrity platform, this
Column is same as that of Current and hence
not displayed separately.
These are keywords for the hardware tests that are executed by proces‐
sor-dependent code (PDC) or firmware upon a boot or reboot of the sys‐
tem.
All the listed tests.
Includes the and tests. This is equivalent to the option
in the boot console handler (BCH) service
menu. The difference is that can control the
subtests separately, while BCH cannot.
When on, run firmware, cache, and CPU-specific tests.
Performed out of firmware. When off, skip the
tests.
When on, run firmware, cache, and CPU-specific tests.
Performed out of memory and therefore faster
than the tests. When off, skip the tests.
Includes the and tests on PA-RISC Platform. Includes the
and tests on Integrity platform. This is
equivalent to the option in the boot console
handler (BCH) service menu. The difference is
that can control the subtests separately,
while BCH cannot.
Note: When is on, the tests performed, and
vice versa.
When on, run write/read-write/read tests on all memory loca‐
tions.
When off, only initialize memory. Supported
only on PA-RISC Platform.
When on, enables general platform hardware tests.
When off, do not. Supported only on Integrity
platform.
When on, enables full destructive memory tests.
When off, do not. Supported only on Integrity
platform.
Processor-dependent hardware.
When on, test a checksum of read-only memory
(ROM). When off, do not. Supported only on
PA-RISC Platform.
Central electronic complex.
When on, test low-level bus converters and I/O
chips. When off, do not. is not available on
all systems. Supported only on PA-RISC Plat‐
form.
When on, enables full destructive memory tests.
When off, do not. Supported only on Integrity
platform.
IO Hardware. When on, enables system firmware, or EFI driv‐
ers to perform all the tests of IO hardware
(boot devices only). When off, do not. Sup‐
ported only on Integrity platform.
When on, enables Chipset tests.
When off, does not enable Chipset tests. Sup‐
ported only on Integrity platform.
Hyperthreading
Some Integrity processors support chip level multiprocessing which is a
physical core presenting itself as two (or possibly more) logical CPUs
(or hardware threads). Hyperthreading increases the instruction
throughput by making use of the idle cycles and idle functional units
that occur due to stalls.
Supported on some Integrity platform.
Failover
will support boot path failover irrespective of whether a persistent
device special file, lunpath hardware path, or legacy hardware path is
given as input.
A persistent device special file is associated with a device based on
its worldwide identifier, rather than its physical hardware path. When
a persistent device special file is given as input, writes an available
lunpath hardware path to the LUN into stable storage.
Note: There is no order in which the available lunpath hardware paths
get selected. Also, when the same persistent device special file is
given as input for more than one boot path, will avoid setting the same
lunpath for the concerned boot paths.
When a lunpath hardware path is given as input, writes that path into
stable storage.
When a legacy hardware path is given as input, writes the corresponding
lunpath hardware path into stable storage. For more information on
legacy hardware path and lunpath hardware path mapping, see ioscan(1M).
For more information on Hardware Paths and Device File Naming Conven‐
tions, including persistent device special file names, see intro(7).
If the hardware path written into stable storage goes offline,
retrieves an alternate available hardware path to the LUN and writes
that path into stable storage. supports failover by subscribing to the
health of the hardware path that it writes to stable storage using EVM
(see EVM(5)).
Options
The command supports the following options:
(none) Display the current values for the primary, HA alternate
(if applicable) and alternate boot paths and the and
flags. See example 2 in the section.
Set the primary boot path variable to
primary-path. setboot will accept legacy hardware paths,
lunpath hardware paths, and persistent device special
files as valid input (see intro(7)).
Set the High Availability alternate boot path variable to
HA_alternate-path. setboot will accept legacy hardware
paths, lunpath hardware paths, and persistent device spe‐
cial files as valid input (see intro(7)).
High Availability alternate boot path is supported only
on Integrity system architecture and for PA-RISC systems
that support hardware partitions.
Set the alternate boot path variable to
alternate-path. setboot will accept legacy hardware
paths, lunpath hardware paths, and persistent device spe‐
cial files as valid input (see intro(7)).
Reinitialize the EVM subscription for boot paths currently set
in stable storage.
This option is useful when the boot path health event
subscriptions are not updated after a change in boot
paths. For example, when the boot paths are updated
between an stop and restart. See evmd(1M). Refer to the
section for more information.
Enable or disable the autosearch sequence.
The interpretation of Autoboot and Autosearch has changed
for PA-RISC systems that support hardware partitions.
Refer to the section. The option is not supported on
Integrity system architecture.
Enable or disable the autoboot sequence.
The interpretation of Autoboot and Autosearch has changed
for PA-RISC systems that support hardware partitions.
Refer to the section.
Enable or disable hyperthreading.
option is supported only on Integrity system architec‐
ture.
Display the current values for the primary and alternate boot
paths
and the and flags and a status table of the SpeedyBoot
tests. See example 1 in the section.
Change the value for the test
testname in stable storage to value for all following
boots. option is not supported on Integrity system
architecture. The changes are reflected in the Current"
and NEXT BOOT columns of the display.
testname can be one of the following keywords, as
described above in the section.
value can be one of:
Enable the test.
Disable the test.
Reset the test to the system default,
which is shown in the Defaults column of
the display.
Change the value for the test
testname to value for the next system boot only. The
change does not modify stable storage, so the permanent
values are restored after the boot.
testname can be one of the keywords described above in
the section. and value are the same as for the option.
RETURN VALUE
The command returns one of:
Successful completion
Failure
DIAGNOSTICS
The command returns the following error messages:
bootpath
The boot path, bootpath, should be one of the following: persis‐
tent LUN dsf, lunpath hardware path or legacy hardware path.
See ioscan(1M) and intro(7) for more information on hardware
path and persistent dsf format.
cannot open the kernel pseudo driver file The message explains
why.
The or flag could not be set.
can't set the specified boot path. type may be or
The message explains why. For example, you may not have permis‐
sion (not be superuser) to change parameters.
The firmware could not be read or written. The message explains
why.
An error occurs when one of the boot paths is invalid (when run‐
ning or This kind of error occurs when there is no valid LUN
entry corresponding to the boot path or lunpath.
An error occurs while displaying boot paths when there is no
valid LUN entry corresponding to the boot path. For example,
one or more of these situations has occurred regarding the per‐
sistent LUN dsf entry:
· The persistent LUN dsf corresponding to the boot path (lun‐
path in stable storage) has been removed (most likely with
the command).
· The boot path is set to a lunpath, but the associated HBA
to that lunpath has been removed or disabled.
· The boot path is set to a non-existent or invalid boot
device in the I/O system.
· The session is run by non-privileged user, while some driv‐
ers require superuser privileges.
This is an internal error.
The test you specified is not defined for your system.
(On PA-RISC Platform only.)
(On Integrity platform only.)
You have specified a SpeedyBoot option or and your system does
not have the firmware to support SpeedyBoot. Currently, the
Integrity platform does not support options.
An unexpected error, number errno, was encountered while was
updating boot variable.
If the flag is off, automatic searching for a bootable system
cannot occur, even if the autosearch flag is on.
The file contains tests that are not supported by on your sys‐
tem. Do not modify this file.
EXAMPLES
General
1. Set the primary path to and enable the autoboot sequence:
2. Set the alternate path (using a persistent device special file)
to and enable the autoboot sequence:
displays:
Alternate boot path set to 0/0/0/3/0.0x6.0x0 (/dev/disk/disk2)
3. Display the boot paths, auto flags and hyperthreading:
on PA-RISC and Integrity system architecture displays:
Primary bootpath : 0/0/0/3/0.0x5.0x0 (/dev/rdisk/disk3)
HA Alternate bootpath : 0/0/0/3/0.0x6.0x0 (/dev/rdisk/disk2)
Alternate bootpath : 0/0/0/3/0.0x6.0x0 (/dev/rdisk/disk2)
Autoboot is ON (enabled)
Autosearch is ON (enabled)
on Integrity system architecture which support hardware threads
displays:
Primary bootpath : 0/3/2/0.0x50001fe15002c7f9.0x4001000000000000
(/dev/rdisk/disk7)
HA Alternate bootpath : 0/1/1/1.0x0.0x0 (/dev/rdisk/disk10)
Alternate bootpath : 0/1/1/0.0x1.0x0 (/dev/rdisk/disk9)
Autoboot is ON (enabled)
Hyperthreading : ON
: ON (next boot)
SpeedyBoot
1. Display all current stable storage values.
on PA-RISC architecture displays:
Primary bootpath : 0/0/0/3/0.0x5.0x0 (/dev/rdisk/disk3)
HA Alternate bootpath : 0/0/0/3/0.0x6.0x0 (/dev/rdisk/disk2)
Alternate bootpath : 0/0/0/3/0.0x6.0x0 (/dev/rdisk/disk2)
Autoboot is ON (enabled)
Autosearch is OFF (disabled)
TEST CURRENT SUPPORTED DEFAULT NEXT BOOT
-------------------- ------- ---------
all partial partial partial partial
SELFTESTS partial yes on partial
early_cpu off yes on off
late_cpu on yes on on
FASTBOOT partial yes on partial
full_memory off yes on off
PDH on yes on on
CEC off no off off
on Integrity system architecture displays:
Primary bootpath : 0/1/1/0.0x1.0x0 (/dev/rdisk/disk9)
HA Alternate bootpath : 0/1/1/1.0x0.0x0 (/dev/rdisk/disk10)
Alternate bootpath : 0/1/1/1.0x0.0x0 (/dev/rdisk/disk10)
Autoboot is ON (enabled)
TEST CURRENT DEFAULT
------------------
all partial partial
SELFTESTS off on
early_cpu off on
late_cpu off on
FASTBOOT on on
Platform on on
Full_memory on on
Memory_init on on
IO_HW off off
Chipset on on
2. Enable and tests and have those tests executed on all subsequent
reboots.
3. Disable the late processor tests and have those tests skipped on
all subsequent reboots. If early CPU tests are when this com‐
mand is executed, the state in BCH stays while shows the state
as
4. Reset all tests to the machine-shipped default values.
5. Reset only the (and tests to their default values.
6. Cause the early and late CPU tests to be executed on the next
system boot. The previously set test values take effect again
after the single boot.
7. Cause all tests to be skipped on the next reboot. The previ‐
ously set test values will take effect for subsequent reboots.
8. Enable hyperthreading for next system boot.
WARNINGS
The command fails under the following circumstances:
· On Integrity systems, a device cannot be set as a boot path if the
device does not have an EFI partition.
· The number of writes to the stable storage exceeds the number
allowed by the architecture implementation.
· Hardware failure.
· The implementation does not have memory for the alternate boot
path, in which case, this variable is neither readable nor
writable.
Autoboot and Autosearch on PA-RISC Systems
The interpretation of Autoboot and Autosearch has changed for PA-RISC
systems that support hardware partitions. The firmware interprets the
bits in combination and not individually as done before. In order to
approximate the traditional behavior of the user input for the and
flags is internally mapped to the right combination to achieve the
desired behavior. This mapping should be transparent to the user of
but might show up when accessing the firmware using means other than
For the primary path, the boot action corresponds to the Autoboot and
Autosearch flags in the following manner:
Additionally, systems with hardware partitions support a boot action
for each path. However the boot action for the paths other than the
primary path cannot be set using setboot. Instead, these must be set
through the Boot Console Handler using the (path flags) command of the
BCH Configuration menu. The default boot action for the hardware par‐
titions is to "skip this device and try next path". The case where
both the and flags are on, will not work as expected until the path
flags for the alternate paths are set appropriately through the BCH.
In the default case, specifying will not cause an alternate path to be
automatically booted when the primary path fails, instead the user will
be prompted.
DEPENDENCIES
If SpeedyBoot is not installed on a system, options and will produce a
diagnostic error. Currently option is not supported on Integrity sys‐
tem architecture.
If the platform does not support hyperthreading, then the option will
produce a diagnostic error.
AUTHOR
was developed by HP.
FILES
Special device file used by the command.
Secondary EVM logger configuration files for
Definitions of tests which can be viewed or controlled with the
and options.
SEE ALSOevmlogger(1M), evmreload(1M), hpux(1M), ioscan(1M), isl(1M),
mkboot(1M), EVM(5), intro(7), errno(2).
setboot(1M)