Chapter 12 Booting a Solaris System (Tasks)

This chapter describes the procedures for booting the Solaris release on SPARC and x86 based systems.

The following is a list of information that is in this chapter:

• Booting a SPARC Based System (Task Map)

• Booting an x86 Based System by Using GRUB (Task Map)

• Using Fast Reboot on the x86 Platform (Task Map)

For overview information about the boot process, see Chapter 9, Shutting Down and Booting a System (Overview).

Booting a SPARC Based System (Task Map)

Booting a SPARC Based System

If a system is turned off, turning it on starts the multiuser boot sequence. The following procedures show how to boot to different run levels from the ok PROM prompt. These procedures assume that the system has been cleanly shut down, unless stated otherwise.

Use the who -r command to verify that the system is brought to the specified run level. For a description of run levels, see Chapter 16, Managing Services (Overview).

SPARC: How to Boot a System to Run Level 3 (Multiuser Level)

Use this procedure to boot a system that is currently at run level 0 to run level 3.

1. Boot the system to run level 3.

   ok boot

   The automatic boot procedure displays a series of startup messages, and brings the system to run level 3. For more information, see the boot(1M) man page.

2. Verify that the system has booted to run level 3.

   The login prompt is displayed when the boot process has finished successfully.

   hostname console login:

Example 12–1 SPARC: Booting a System to Run Level 3 (Multiuser Level)

The following example displays the messages from booting a system to run level 3.

ok boot
Resetting ...

Sun Ultra 2 UPA/SBus (2 X UltraSPARC-II 296MHz), No Keyboard
OpenBoot 3.25, 512 MB memory installed, Serial #10342381.
Ethernet address 8:0:20:xx:cf:ed, Host ID: 80xxcfed.


Rebooting with command: boot
Boot device: /sbus@1f,0/SUNW,fas@e,8800000/sd@a,0:a  File and args: kadb
Loading kmdb...
SunOS Release 5.10		64-bit
Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms
WARNING: consconfig: cannot find driver for screen device /SUNW,ffb@1e,0
Hostname: dancehallgirl
NIS domain name is boulder.Central.Sun.COM
/dev/rdsk/c0t10d0s7 is clean
Reading ZFS config: done.

dancehallgirl console login:

SPARC: How to Boot a System to Run Level S (Single-User Level)

Use this procedure to boot a system that is currently at run level 0 to run level S. This run level is used for system maintenance tasks, such as backing up a file system.

1. Boot the system to run level S.

   ok boot -s

2. Type the superuser password when the following message is displayed:

   SINGLE USER MODE Root password for system maintenance (control-d to bypass): xxxxxx

3. Verify that the system is at run level S.

   # who -r

4. Perform the maintenance task that required the run level change to S.

5. After you complete the system maintenance task, type Control-D to bring the system to the multiuser state.

Example 12–2 SPARC: Booting a System to Run Level S (Single-User Level)

The following example displays the messages from booting a system to run level S.

ok boot -s
Resetting ...

Sun Ultra 2 UPA/SBus (2 X UltraSPARC-II 296MHz), No Keyboard
OpenBoot 3.25, 512 MB memory installed, Serial #10342381.
Ethernet address 8:0:20:xx:cf:ed, Host ID: 80xxcfed.

Rebooting with command: boot -s
Boot device: /sbus@1f,0/SUNW,fas@e,8800000/sd@a,0:a  File and args: -s
SunOS Release 5.11
Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms
WARNING: consconfig: cannot find driver for screen device /SUNW,ffb@1e,0

Root password for system maintenance (control-d to bypass):
svc.startd: Returning to milestone all.
NIS domain name is boulder.Central.Sun.COM
/dev/rdsk/c0t10d0s7 is clean
Reading ZFS config: done.
dancehallgirl console login:

SPARC: How to Boot a System Interactively

Use this boot option when you need to specify an alternate kernel or /etc/system file.

Before You Begin

To specify an alternate /etc/system file when booting a SPARC based system interactively by using the boot -a command, you must perform the following steps before the system is booted.

• 1. Make backup copies of the /etc/system and boot/solaris/filelist.ramdisk files.

  # cp /etc/system /etc/system.bak # cp /boot/solaris/filelist.ramdisk /boot/solaris/filelist.ramdisk.orig

• 2. Add the etc/system.bak file name to the /boot/solaris/filelist.ramdisk file

  # echo "etc/system.bak" >> /boot/solaris/filelist.ramdisk

• 3. Update the boot archive.

  # bootadm update-archive -v

1. Boot the system interactively.

   ok boot -a

2. Answer the following system prompts:

   1. When prompted, enter the name of the kernel to use for booting.

      Press enter to use the default kernel file name. Otherwise, provide the name of an alternate kernel, press Enter.

   2. When prompted, provide an alternate path for the modules directories.

      Press enter to use the default module directories. Otherwise, provide the alternate paths to module directories, press Enter.

   3. When prompted, provide the name of an alternate system file.

      Type /dev/null if your /etc/system file has been damaged.

   4. When prompted, enter the root filesystem type.

      Press enter to select UFS for local disk booting, which is the default, or enter NFS for network booting.

   5. When prompted, enter the physical name of root device.

      Provide an alternate device name or press return to use the default.

3. If you are not prompted to answer these questions, verify that you typed the boot -a command correctly.

Example 12–3 SPARC: Booting a System Interactively

In this example, the default choices (shown in square brackets []) are accepted. For instructions and an example of booting an alternate file system by using the boot -a command, see SPARC: How to Boot a System Interactively.

ok boot -a
Resetting ...

Sun Ultra 2 UPA/SBus (2 X UltraSPARC-II 296MHz), No Keyboard
OpenBoot 3.25, 512 MB memory installed, Serial #10342381.
Ethernet address 8:0:20:9d:cf:ed, Host ID: 809dcfed.



Rebooting with command: boot -a
Boot device: /sbus@1f,0/SUNW,fas@e,8800000/sd@a,0:a  File and args: -a

Boot device: /sbus@1f,0/SUNW,fas@e,8800000/sd@a,0:a  File and args: -a
Name of system file [/etc/system]:
SunOS Release 5.11 Version zwicky:nbsclean-build:12/04/2007 64-bit
Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Retire store [/etc/devices/retire_store] (/dev/null to bypass):
root filesystem type [ufs]:
Enter physical name of root device
[/sbus@1f,0/SUNW,fas@e,8800000/sd@a,0:a]:
WARNING: consconfig: cannot find driver for screen device /SUNW,ffb@1e,0
Hostname: dancehallgirl
NIS domain name is boulder.Central.Sun.COM
/dev/rdsk/c0t10d0s7 is clean
Reading ZFS config: done.
dancehallgirl login:

SPARC: How to Boot a Solaris Kernel Other Than the Default Kernel

1. Become superuser or assume an equivalent role.

2. Obtain a copy of an existing Solaris kernel and rename it.

3. Add the kernel that you copied and renamed in Step 2 to the /etc/boot/solaris/filelist.ramdisk file.

   # echo "kernel.name" >> /boot/solaris/filelist.ramdisk

4. Verify that the alternate kernel has been added the /etc/boot/solaris/filelist.ramdisk file.

   # cat > /etc/boot/solaris/filelist.ramdisk

5. Update the boot archive by using the bootadm command.

   # bootadm update-archive

6. Change to run level 0.

   # init 0

   The ok PROM prompt is displayed.

7. Boot the alternate kernel.

   ok boot alternate-kernel

   For example:

   ok boot kernel.myname/sparcv9/unix

   • To boot the alternate kernel by default, follow these steps:

     1. Set the boot-file parameter to the new kernel.

        ok setenv boot-file kernel.name/sparc9/unix

     2. Verify that the boot-file property has been changed.

        ok printenv boot-file

     3. Reboot the system.

        ok boot

8. After the system has booted, verify that the alternate kernel that was booted.

   # prtconf -vp | grep whoami

Example 12–4 Booting an Alternate Solaris Kernel by Changing the Default Boot File

# cp -r /platform/sun4v/kernel /platform/sun4vu/kernel.caiobella
# echo "kernel.caiobela" >> /boot/solaris/filelist.ramdisk

# cat > /etc/boot/solaris/filelist.ramdisk
/platform/sun4v/kernel.caiobella
^D (control D)

ok setenv boot-file kernel.caiobells/sparcv9/unix
ok printenv boot-file
boot-file = kernel.caiobella/sparcv9/unix

ok boot

SC Alert: Host System has Reset

SC Alert: Host system has shut down.


Sun Fire T200, No KeyboardCopyright 2006 Sun Microsystems, Inc.  All rights reserved.
OpenBoot 4.25.0.build_01***PROTOTYPE BUILD***, 32760 MB memory available, Serial 
#69060038.
Ethernet address 0:x:4f:x:c5:c6, Host ID: 8xxc5c6.



Rebooting with command: boot
Boot device: /pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/disk@0,0:a  File and 
args: kernel.caiobella/sparcv9/unix
SunOS Release 5.10
Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
DEBUG enabled
misc/forthdebug (176650 bytes) loaded
Hostname: seasonz
NIS domain name is lab.domain.sun.com
Reading ZFS config: done.

seasonz console login:
Password:
Last login: Mon Nov 12 18:02:00 on console
Sun Microsystems Inc.   SunOS 5.11
.
.
.
You have new mail.
#
#
# prtconf -vp | grep whoami
        whoami:  '/platform/sun4v/kernel.caiobella/sparcv9/unix'

Booting From a ZFS Root File System on a SPARC Based System

To support booting from ZFS on the Solaris SPARC platform, two new boot options have been added:

-L

Displays a list of available bootable datasets within a ZFS pool.

---

Note –

The boot -L command is executed from the OBP, not from the command line.

---

-Z dataset

Boots the root file system for the specified ZFS bootable dataset.

If you are booting a system from a ZFS root file system, first use the boot command with the -L option from the OBP to print a list of the available BEs on the system. Then, use the -Z option to boot the specified BE.

For more information, see the boot(1M) man page.

SPARC: How to List Available Bootable Datasets Within a ZFS Root Pool

On SPARC based systems, the menu.lst file contains the following two GRUB commands:

• title – Provides a title for a boot environment

• bootfs – Specifies the full name of the bootable dataset

To display a list of bootable datasets within a ZFS pool, choose from the following methods:

• Use the lustatus command. This command lists all of the BEs in a given ZFS pool.

  Note that the lustatus command can also be used on x86 based systems.

• Use the boot -L command. This command displays a list of available BEs in a given ZFS pool and provides instructions for booting the system.

The following procedure shows how to use the boot -L command to list available BEs on a system. To boot a specified BE after running this command, follow the instructions that are printed on the screen.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Bring the system to the ok prompt.

   # init 0

3. List the available BEs in a ZFS pool:

   ok boot device-specifier -L

4. (Optional) To boot one of the entries that is displayed, type the number of the entry. To boot the specified BE, follow the directions that are printed to the screen.

   For instructions, see SPARC: How to Boot From a ZFS Root File System.

Example 12–5 SPARC: Displaying a List of Available BEs on a System by Using boot -L

# init 0
# svc.startd: The system is coming down. Please wait.
svc.startd: 94 system services are now being stopped.
svc.startd: The system is down.
syncing file systems... done
Program terminated
ok boot -L
.
.
.
Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0 File and args: -L
zfs-file-system
Loading: /platformsun4u/bootlst
1.s10s_nbu6wos
2 zfs2BE
Select environment to boot: [ 1 - 2 ]: 2

to boot the selected entry, invoke:
boot [<root-device] -Z rpool/ROOT/zfs2BE

See Also

For more information, see Chapter 4, Installing and Booting a ZFS Root File System, in Solaris ZFS Administration Guide.

SPARC: How to Boot From a ZFS Root File System

Booting from ZFS differs from booting from UFS. When booting from ZFS, a device specifier identifies a storage pool, not a single root file system. A storage pool can contain multiple bootable datasets, or root file systems. Therefore, when booting from ZFS, you must also identify a root file system within the pool that is identified by the boot device as the default. By default, the default boot device is identified by the pool's bootfs property. This procedure shows how to boot the system by specifying a ZFS bootable dataset. See the boot(1M) man page for a complete description of all the boot options that are available.

If the bootfs property was previously set up correctly, for example, if you used the luactivate command to activate a BE, the system boots a ZFS root automatically.

For more information, see zpool(1M) man page.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Bring the system to the ok prompt.

   # init 0

3. (Optional) To display a list of available BEs, use the boot command with the -L option.

   For instructions, see SPARC: How to List Available Bootable Datasets Within a ZFS Root Pool.

4. To boot a specified entry, type the number of the entry and press Return:

   Select environment to boot: [1 - 2]:

5. To boot the system, follow the instructions that are printed to the screen:

   To boot the selected entry, invoke:
   boot [<root-device>] -Z rpool/ROOT/dataset
   

   ok boot -Z rpool/ROOT/dataset

   For example:

   # boot -Z rpool/ROOT/zfs2BE

6. After the system has booted, type the following command to verify the active BE:

   # prtconf -vp | grep whoami

   • To display the boot path for the active BE, type:

     # prtconf -vp | grep bootpath

   • Alternately, you can type the following command to determine whether the corrected BE was booted:

     # df -lk

Example 12–6 SPARC: Booting From a ZFS Root File System

This example shows how to use the boot -Z command to boot a ZFS dataset on a SPARC based system.

# init 0
# svc.startd: The system is coming down. Please wait.
svc.startd: 79 system services are now being stopped.
svc.startd: The system is down.
syncing file systems... done
Program terminated
ok boot -Z rpool/ROOT/zfs2BEe
Resetting
LOM event: =44d+21h38m12s host reset
g ...

rProcessor Speed = 648 MHz
Baud rate is 9600
8 Data bits, 1 stop bits, no parity (configured from lom)

Firmware CORE Sun Microsystems, Inc.
@(#) core 1.0.12 2002/01/08 13:00
software Power ON
Verifying nVRAM...Done
Bootmode is 0
[New I2C DIMM address]
.
.
.
Environment monitoring: disabled
Executng last command: boot -Z rpool/ROOT/zfs2BE
Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0 File and args: -Z rpool/ROOT/zfs2Be
zfs-file-system
Loading: /platform/SUNW,UltraAX-i2/boot_archive
Loading: /platform/sun4u/boot_archive
ramdisk-root hsfs-file-system
Loading: /platform/SUNW,UltraAX-i2/kernel/sparcv9/unix
Loading: /platform/sun4u/kernel/sparcv9/unix
.
.
.
Hostname: mallory
NIS domainname is boulder.Central.Sun.COM
Reading ZFS config: done.
Mounting ZFS filesytems: (6/6)

mallory console login:

See Also

For information about booting the failsafe archive for a specified ZFS bootable dataset, see How to Boot the Failsafe Archive on a SPARC Based System.

Booting the Failsafe Archive on a SPARC Based System

Booting a system from a root (/) file system image that is a boot archive, and then remounting this file system on the actual root device can sometimes result in a boot archive and root file system that do not match, or are inconsistent. Under these conditions, the proper operation and integrity of the system is compromised. After the root (/) file system is mounted, and before relinquishing the in-memory file system, the system performs a consistency verification against the two files systems. If an inconsistency is detected, the normal boot sequence is suspended and the system reverts to failsafe mode.

Also, if a system failure, a power failure, or a kernel panic occurs immediately following a kernel file update, the boot archives and the root (/) file system might not be synchronized. Although the system might still boot with the inconsistent boot archives, it is recommended that you boot the failsafe archive to update the boot archives. You can also use the bootadm command to manually update the boot archives. For more information, see Using the bootadm Command to Manage the Boot Archives.

The failsafe archive can be booted for recovery purposes or to update the boot archive on both the SPARC and x86 platforms.

On the SPARC platform the failsafe archive is:

/platform/`uname -m`/failsafe

You would boot the failsafe archive by using the following syntax:

ok boot  -F failsafe

Failsafe booting is also supported on systems that are booted from ZFS. When booting from a ZFS-rooted BE, each BE has its own failsafe archive. The failsafe archive is located where the root (/) file system is located, as is the case with a UFS-rooted BE. The default failsafe archive is the archive that is in the default bootable file system. The default bootable file system (dataset) is indicated by the value of the pool's bootfs property.

For information about booting an x86 based failsafe archive, see Booting the Failsafe Archive on an x86 Based System.

Another method that can be used to update the boot archives is to clear the boot-archive service. However, the preferred methods for updating the boot archives are to boot the failsafe archive or use the bootadm command. For more information, see How to Update an Inconsistent Boot Archive by Clearing the boot-archive Service.

How to Boot the Failsafe Archive on a SPARC Based System

Use this procedure to boot the failsafe archive on a SPARC based system. If the system does not boot after the boot archive is updated, you might need to boot the system in single-user mode. For more information, see SPARC: How to Boot a System to Run Level S (Single-User Level).

This procedures also includes instructions for booting the failsafe archive for a specific ZFS dataset.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Bring the system to the ok prompt:

   # init 0

3. Boot the failsafe archive.

   • To boot the default failsafe archive, type:

     ok boot -F failsafe

   • To boot the failsafe archive of a specific ZFS dataset:

     ok boot -F failsafe -Z dataset

     For example:

     ok boot -F failsafe -Z rpool/ROOT/zfsBE2

     ---

     Note –

     To determine the name of the dataset to boot, first use the boot -L command to display a list of the available BEs on the system. For more information, see SPARC: How to List Available Bootable Datasets Within a ZFS Root Pool.

     ---

   If an inconsistent boot archive is detected a message is displayed.

4. To update the boot archive, type y and press Return.

   An out of sync boot archive was detected on rpool. The boot archive is a cache of files used during boot and should be kept in sync to ensure proper system operation. Do you wish to automatically update this boot archive? [y,n,?] y

   If the archive was updated successfully, a message is displayed:

   The boot archive on rpool was updated successfully.

Example 12–7 SPARC: Booting the Failsafe Archive

This example shows how to boot the failsafe archive on a SPARC based system. If no device is specified, the failsafe archive for the default boot device is booted.

ok boot -F failsafe
Resetting ...
screen not found.
Can't open input device. Keyboard not present.  Using ttya for input and output.

Sun Enterprise 220R (2 X UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.23, 1024 MB memory installed, Serial #13116682.
Ethernet address 8:0:20:c8:25:a, Host ID: 80c8250a.

Rebooting with command: boot -F failsafe
Boot device: /pci@1f,4000/scsi@3/disk@1,0:a  File and args: -F failsafe
SunOS Release 5.10t
Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Configuring /dev Searching for installed OS instances...

An out of sync boot archive was detected on /dev/dsk/c0t1d0s0.
The boot archive is a cache of files used during boot and
should be kept in syncto ensure proper system operation.

Do you wish to automatically update this boot archive? [y,n,?] y 
Updating boot archive on /dev/dsk/c0t1d0s0.
The boot archive on /dev/dsk/c0t1d0s0 was updated successfully.

Solaris 5.10 was found on /dev/dsk/c0t1d0s0.
Do you wish to have it mounted read-write on /a? [y,n,?] n
Starting shell.
#

Example 12–8 SPARC: Booting the Failsafe Archive for a Specified ZFS Dataset

This example shows how to boot the failsafe archive of a ZFS dataset. Note that the boot -L command is first used to display a list of available boot environments. This command must be run at the ok prompt.

ok boot -L
Rebooting with command: boot -L                                       
Boot device: /pci@1f,4000/scsi@3/disk@1,0  File and args: -L
1 zfsBE2
Select environment to boot: [ 1 - 1 ]: 1

To boot the selected entry, invoke:
boot [<root-device>] -Z rpool/ROOT/zfsBE2

Program terminated
{0} ok 





Resetting ... 

screen not found.
Can't open input device.
Keyboard not present.  Using ttya for input and output.

Sun Enterprise 220R (2 X UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.23, 1024 MB memory installed, Serial #13116682.
Ethernet address 8:0:20:c8:25:a, Host ID: 80c8250a.



                                                                      
{0} ok  boot -F failsafe -Z rpool/ROOT/zfsBE2
Boot device: /pci@1f,4000/scsi@3/disk@1,0  File and args: -F failsafe -Z 
rpool/ROOT/zfsBE2
SunOS Release 5.10
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Configuring /dev
Searching for installed OS instances...

ROOT/zfsBE2 was found on rpool.
Do you wish to have it mounted read-write on /a? [y,n,?] y
mounting rpool on /a

Starting shell.
# 
# 
# 
# zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool  16.8G  6.26G  10.5G    37%  ONLINE  /a
# 
# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c0t1d0s0  ONLINE       0     0     0

errors: No known data errors
# 
# df -h
Filesystem             size   used  avail capacity  Mounted on
/ramdisk-root:a        163M   153M     0K   100%    /
/devices                 0K     0K     0K     0%    /devices
/dev                     0K     0K     0K     0%    /dev
ctfs                     0K     0K     0K     0%    /system/contract
proc                     0K     0K     0K     0%    /proc
mnttab                   0K     0K     0K     0%    /etc/mnttab
swap                   601M   344K   601M     1%    /etc/svc/volatile
objfs                    0K     0K     0K     0%    /system/object
sharefs                  0K     0K     0K     0%    /etc/dfs/sharetab
swap                   602M   1.4M   601M     1%    /tmp
/tmp/root/etc          602M   1.4M   601M     1%    /.tmp_proto/root/etc
fd                       0K     0K     0K     0%    /dev/fd
rpool/ROOT/zfsBE2       16G   5.7G   9.8G    37%    /a
rpool/export            16G    20K   9.8G     1%    /a/export
rpool/export/home       16G    18K   9.8G     1%    /a/export/home
rpool                   16G    63K   9.8G     1%    /a/rpool

Booting a SPARC Based System From the Network

You might need to boot a system from the network under the following conditions:

• When the system is first installed

• If the system won't boot from the local disk

• If the system is a diskless client

Two network configuration boot strategies are available:

• Reverse Address Resolution Protocol (RARP) and ONC+^TM RPC Bootparams Protocol

• Dynamic Host Configuration Protocol (DHCP)

• For network devices, the process for booting over a local area network (LAN) and booting over a wide area network (WAN) is slightly different. In both network boot scenarios, the PROM downloads the booter from a boot server or an installation server, which is inetboot in this case.

  When booting over a (LAN), the firmware uses RARP and BOOTP or DHCP to discover the boot or installation server. TFTP is then used to download the booter, which is inetboot in this case.

  When booting over a WAN, the firmware uses either DHCP or NVRAM properties to discover the installation server, the router, and the proxies that are required for the system to boot from the network. The protocol that is used to download the booter is HTTP. In addition, the booter's signature might be checked with a predefined private key.

SPARC: How to Boot a System From the Network

Any system can boot from the network if a boot server is available. You might want to boot a stand-alone system from the network if the system cannot boot from the local disk. For information on changing or resetting the default boot device, see SPARC: How to Change the Default Boot Device by Using the Boot PROM.

Two network configuration boot strategies are available on sun–4u systems:

• RARP – Reverse Address Resolution Protocol and ONC+ RPC Bootparams Protocol

• DHCP – Dynamic Host Configuration Protocol

The default network boot strategy is set to RARP. You can use either protocol, depending on whether a RARP boot server or a DHCP boot server is available on your network.

Sun Ultra systems must have at least PROM version 3.25.nn to use the DHCP network boot strategy. For information on determining your PROM version, see SPARC: How to Find the PROM Revision Number for a System.

If both protocols are available, you can temporarily specify which protocol to use in the boot command. Or, you can save the network boot strategy across system reboots at the PROM level by setting up an NVRAM alias. The following example uses the nvalias command to set up a network device alias for booting DHCP by default on a Sun Ultra 10 system.

ok nvalias net	/pci@1f,4000/network@1,1:dhcp

As a result, when you type boot net, the system boots by using the DHCP network book strategy.

You should not use the nvalias command to modify the NVRAMRC file, unless you are very familiar with the syntax of this command and the nvunalias command. For information on using these commands, see the OpenBoot 3.x Command Reference Manual.

Before You Begin

You must have already set up a RARP or DHCP boot server in your network to use either protocol to boot successfully.

1. If necessary, shut down the system.

2. Determine the method for booting from the network, and select one of the following:

   1. Boot the system from the network by using the DHCP strategy.

      ok boot net[:dhcp]

      If you have changed the PROM setting to boot DHCP by default, as in the preceding nvalias example, you only have to specify boot net.

   2. Boot the system from the network by using the RARP strategy.

      ok boot net[:rarp]

      Because RARP is the default network boot strategy, you only have to specify boot net:rarp if you have changed the PROM value to boot DHCP.

Booting an x86 Based System by Using GRUB (Task Map)

x86: Error Messages Upon System Boot

The Solaris installation software and utilities, including the bootadm command, use the presence of the /boot/multiboot and /platform/i86pc/multiboot files to determine if the system's running OS or the Solaris installation software implements the GRUB boot method or the Solaris Device Configuration Assistant boot method.

If the multiboot module from the previous GRUB implementation is loaded by GRUB, the console displays an error message that says multiboot is no longer support and to manually update the entries in the menu.lst file to successfully boot the system. For more information, see http://www.sun.com/msg/SUNOS-8000-AK and the boot(1M) man page.

For instructions on booting a system interactively modifying the GRUB kernel line at boot time, see x86: How to Modify Boot Behavior by Editing the GRUB Menu at Boot Time. For instructions on modifying the menu.lst file permanently after the system has booted, see x86: How to Modify Boot Behavior by Editing the menu.lst File.

x86: How to Boot a System to Run Level 3 (Multiuser)

Use this procedure to boot a system that is currently at run level 0 to run level 3.

1. Reboot the system.

   # reboot

   If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt. If the system is shut down, turn the system on with the power switch.

   When the boot sequence begins, the GRUB menu is displayed.

2. When the GRUB menu is displayed, press Enter to boot the default OS instance.

   If you do not choose an entry within 10 seconds, the system automatically boots to run level 3.

   The login prompt is displayed when the boot process has finished successfully.

3. Log in to the system.

   hostname console login:

4. Verify that the system booted to run level 3.

   # who -r system% who -r . run-level 3 Mar 2 09:44 3 0 S

Example 12–9 x86: Booting a System To Run Level 3 (Multiuser Level)

# reboot

Jul 24 11:29:52 bearskin reboot: rebooted by root
syncing file systems... done
rebooting...

Adaptec AIC-7899 SCSI BIOS v2.57S4
(c) 2000 Adaptec, Inc. All Rights Reserved.

 Press <Ctrl><A> for SCSISelect(TM) Utility! 

Ch B,  SCSI ID: 0 SEAGATE  ST336607LSUN36G   160

GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)
==============================================================
Solaris 10 10/08 s10x_u6wos_03 X86
Solaris failsafe

==============================================================
		Use the  and  keys to select which entry is highlighted.
		Press enter to boot the selected OS, 'e' to edit the
		commands before booting, or 'c' for a command-line.


SunOS Release 5.10 Version Generic_137138-04 32-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: pups
NIS domain name is ....sfbay.sun.com
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)

pups console login:

# who -r
   .       run-level 3  Jul 24 11:31     3      0  S

x86: How to Boot a System to Run Level S (Single-User Level)

Use this procedure to boot a system that is at run level 0 to run level S. The single-user level is used for performing system maintenance.

This procedure can be used for all GRUB implementations. However, the boot entries in the GRUB main menu vary, depending on the Solaris release you are running.

For a description of all the kernel options that you can specify in the GRUB menu at boot time, see x86: Modifying Boot Behavior by Editing the GRUB Menu at Boot Time.

1. Reboot the system.

   # reboot

   If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt. If the system is shut down, turn the system on with the power switch.

   When the boot sequence begins, the GRUB menu is displayed.

2. When the GRUB main menu is displayed, type e to edit the GRUB menu.

3. Depending on the release you are running, use the arrow keys to choose the kernel or kernel$ line.

   If you cannot use the arrow keys, use the caret key (^) key to scroll up and the letter v key to scroll down.

4. Type e again to edit the boot entry.

   From here, you can add options and arguments to the kernel or kernel$ line.

5. To boot the system in single-user mode, type -s at the end of the boot entry line. Then, press Return to go back to the previous screen.

   • To specify other boot behaviors, replace the -s option with the appropriate boot option.

     The following alternate boot behaviors can be specified in this manner.

     • Perform a reconfiguration boot.

     • Boot a 64-bit capable system in 32-bit mode.

     • Boot the system with the kernel debugger.

     • Redirect the console.

     For more information, see the boot(1M)man page.

6. To boot the system in single-user mode, type b.

7. When prompted, type the root password.

   ---

   Note –

   If you are running the OpenSolaris 2008.11 release, you need to also enter an account name before entering the root password. The account name can be root or any other privileged account, such as “jack” on the Live CD, or an account that you created during the installation.

   ---

8. Verify that the system is at run level S.

   # who -r . run-level S Jun 13 11:07 S 0 0

9. Perform the system maintenance task that required the run level change to S.

10. After you complete the system maintenance task, reboot the system.

Example 12–10 x86: Booting a System in Single-User Mode

# reboot
Jul  2 14:30:01 pups reboot: initiated by root on /dev/console
syncing files...

Press <Ctrl><A> forPSCSISelect(TM) Utility!


GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)

===================================================
Solaris 10 10/08 s10x_u6wos_03 X86 
Solaris failsafe

=====================================================
		Use the  and  keys to select which entry is highlighted.
		Press enter to boot the selected OS, 'e' to edit the
		commands before booting, or 'c' for a command-line.
=====================================================

GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)

=====================================================
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS 
module /platform/i86pc/boot_archive
================================================
		Use the  and  keys to select which entry is highlighted.
		Press 'b' to boot, 'e' to edit the selected command in the
		boot sequence, 'c' for a command-line, 'o' to open a new line
		after ('O' for before) the selected line, 'd' to remove the
		selected line, or escape to go back to the main menu.

[ Minimal BASH-like line editing is supported.  For the first word, TAB
lists possible command completions.  Anywhere else TAB lists the possible
completions of a device/filename.  ESC at any time exits. ]

grub edit> kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS -s

 GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)

=======================================================
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS -s 
module /platform/i86pc/boot_archive
======================================
		Use the  and  keys to select which entry is highlighted.
		Press 'b' to boot, 'e' to edit the selected command in the
 	boot sequence, 'c' for a command-line, 'o' to open a new line
		after ('O' for before) the selected line, 'd' to remove the
   selected line, or escape to go back to the main menu.
.
.
.
SunOS Release 5.10
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Booting to milestone "milestone/single-user:default".
Hostname: pups Requesting System Maintenance Mode SINGLE USER MODE
Root password for system maintenance (control-d to bypass):
single-user privilege assigned to /dev/console.
Entering System Maintenance Mode
Jul  2 14:41:48 su: 'su root' succeeded for root on /dev/console Sun Microsystems Inc.
# who -r
who -r    .       run-level S  Jul  2 14:39     S      0  0 # 

x86: How to Boot a System Interactively

Use this procedure to boot a system if you need to specify an alternate kernel or an alternate /etc/system file.

Before You Begin

To specify an alternate /etc/system file when booting an x86 based system interactively by using the boot -a command, you must first perform the following steps:

• 1. Make backup copies of the /etc/system and the boot/solaris/filelist.ramdisk files.

  # cp /etc/system /etc/system.bak # cp /boot/solaris/filelist.ramdisk /boot/solaris/filelist.ramdisk.orig

• 2. Add the /etc/system.bak file name to the /boot/solaris/filelist.ramdisk file

  # echo "etc/system.bak" >> /boot/solaris/filelist.ramdisk

• 3. Update the boot archive.

  # bootadm update-archive -v

1. Reboot the system.

   # reboot

   If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt. If the system is shut down, turn the system on with the power switch.

   When the boot sequence begins, the GRUB main menu is displayed.

2. To access the GRUB edit menu, type e.

3. Use the arrow keys to select the kernel or kernel$ line.

4. Type e to edit the boot entry line.

5. Type -a to boot the system interactively. Then, press Enter to return to the GRUB main menu.

6. To boot the system interactively, type b.

7. Type a default directory for modules, or press Enter to accept the default.

   Enter default directory for modules [/platform/i86pc/kernel /kernel /usr/kernel]:

8. Type an alternate system file name, alternate-file.

   Name of system file [etc/system]: /etc/system.bak

   Pressing Enter without providing an alternate file accepts the default.

   Repair the damaged /etc/system file.

9. Reboot the system to run level 3.

Example 12–11 x86: Booting a System Interactively

# reboot
syncing file systems... done
rebooting...

 
GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)
===================================================
Solaris 10 10/08 s10x_u6wos_03 X86 
Solaris failsafe
=====================================================
		Use the  and  keys to select which entry is highlighted.
		Press enter to boot the selected OS, 'e' to edit the
		commands before booting, or 'c' for a command-line.
=====================================================


GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)
=====================================================
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS 
module /platform/i86pc/boot_archive
======================================================
		Use the  and  keys to select which entry is highlighted.
		Press 'b' to boot, 'e' to edit the selected command in the
		boot sequence, 'c' for a command-line, 'o' to open a new line
		after ('O' for before) the selected line, 'd' to remove the
		selected line, or escape to go back to the main menu.

[ Minimal BASH-like line editing is supported.  For the first word, TAB
lists possible command completions.  Anywhere else TAB lists the possible
completions of a device/filename.  ESC at any time exits. ]

grub edit> kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS -a
GNU GRUB  version 0.95  (637K lower / 2096064K upper memory)

===================================================
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS -a 
module /platform/i86pc/boot_archive
====================================================
.
.
.
Enter default directory for modules [/platform/i86pc/kernel /kernel /usr/kernel]:
Name of system file [/etc/system]:  /etc/system.bak
SunOS Release 5.10 Version Generic_137138-04 32-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: pups
NIS domain name is ....sfbay.sun.com
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
pups console login:

Booting From a ZFS Root File System on an x86 Based System

To support booting a ZFS root file system on the x86 platform, a new GRUB keyword, $ZFS-BOOTFS, has been introduced. If a root device contains a ZFS pool, this keyword is assigned a value, which is then passed to the kernel by using the -B option to identify the dataset to boot. If you install or upgrade your system with a Solaris release that supports a ZFS boot loader, the GRUB menu.lst file, as well as the GRUB boot menu, contains this information by default.

How to Display a List of the Available ZFS Boot Environments on an x86 Based System

1. Become superuser or assume an equivalent role.

2. To display a list of available BEs on the system, type the following command:

   # lustatus

   Note that the lustatus command can also be used on SPARC based systems.

   ---

   Note –

   If the following error is displayed when you run the lustatus command, it is an indication that a new installation was performed and that Solaris Live Upgrade was not used. Before any BEs can be acknowledged in the lustatus output, a new BE must be first created on the system.

   # lustatus ERROR: No boot environments are configured on this system ERROR: cannot determine list of all boot environment names

   ---

   For more information about using Solaris Live Upgrade to migrate a UFS root file system to a ZFS root file system, see Migrating a UFS Root File System to a ZFS Root File System (Solaris Live Upgrade) in Solaris ZFS Administration Guide.

Example 12–12 Displaying a List of Available ZFS Bootable Datasets by Using the lustatus Command

In this example, the output of the lustatus command shows the status of three ZFS bootable datasets. The default boot environment is be1 and therefore cannot be deleted.

# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
s10s_nbu6wos               yes      no     no        yes    -
zfs2BE                     yes      yes    yes       no     -
zfsbe3                     no       no     no        yes    -
#

If the BE has been created and is bootable, a “yes” appears in the Is Complete column. If a BE has been created, but is not yet activated, a 'no” appears in this column. To activate a BE, use the luactivate command. Run the lustatus command afterwards to verify that the BE was successfully activated.

For more information see the lustatus(1M) and the luactivate(1M)man pages.

How to Boot From a ZFS Root File System on an x86 Based System

This procedure describes how to boot from a ZFS root file system on an x86 system that supports a ZFS boot loader.

Note that if you install or upgrade your system to a Solaris release that supports a ZFS boot loader, the GRUB menu entry contains the -B $ZFS-BOOTFS boot argument by default, so the system boots from ZFS without requiring any additional boot arguments.

1. Reboot the system.

   # reboot

   If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt. If the system is shut down, turn the system on with the power switch.

   When the boot sequence begins, the GRUB main menu is displayed. If the default boot entry is a ZFS file system menu is similar to the following:

   GNU GRUB version 0.95 (637K lower / 3144640K upper memory) +----------------------------------------------------------------+ | be1 | be1 failsafe | be3 | be3 failsafe | be2 | be2 failfafe +---------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.

2. When the GRUB menu is displayed, press Enter to boot the default OS instance.

   If you do not choose an entry within 10 seconds, the system automatically boots to run level 3.

3. To boot another BE, use the arrow keys to highlight the specified boot entry.

4. Type b to boot this entry or e to edit the entry.

   If you type e to edit the entry, the default menu for booting a system with a ZFS root would appear as follows:

   findroot (BE_be10,0,a) kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot-archive

   For more information about GRUB menu entries at boot time, seex86: How to Modify Boot Behavior by Editing the GRUB Menu at Boot Time.

Example 12–13 x86: Activating a New Boot Environment on an x86 Based System

This example shows the steps that are followed to activate a boot environment, be10, on a system. Note that the lustatus command is run first, to determine which BEs on the system are active and which BEs require activation.

# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                      Complete Now    On Reboot Delete Status
-----------------------------------------------------------------
be1                        yes      yes    yes       no     
be10                       yes      no     no        yes



# luactivate be10
System has findroot enabled GRUB Generating boot-sign, partition and slice
information for PBE <be1>
WARNING: The following file s have change on both the current boot environment
<be1> zone <global> and the boot environment to be activitate <be10>
		/etc/zfs/zpool.cache
INFORMATION: The files listed above are in conflict between the current
boot environment <be1> zone <global> and the boot environment to be
activated <be10>. These files will not be automatically synchronized from
the current boot environment <be1> when boot environment <be10> is activated.

Setting failsafe console to <ttyb>
Generating boot-sign for ABE <be10>
Generating partition and slice information for ABE <be10>
Copied boot menu from top level dataset.
Generating direct boot menu entries for PBE.
Generating direct boot menu entries for ABE.
Disabling splashimage
Current GRUB menu default setting is not valid
title Solaris bootenv rc
No more bootadm entries. Deletion of bootadm entries is complete.
GRUB menu default setting is unchanged
Done eliding bootadm entries.
**************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
***************************************************************
,,,


# reboot
May 30 09:52:32 pups reboot: initiated by root on /dev/console
syncing file systems... done
rebooting...

CE SDRAM BIOS P/N GR-xlint.007-4.330
*

BIOS Lan-Console 2.0
Copyright (C) 1999-2001 Intel Corporation
.
.
.
GNU GRUB  version 0.95  (637K lower / 3144640K upper memory)
 +-------------------------------------------------------------------+
| be1
| be1 failsafe
| be10
| be10 failsafe
+------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the
      commands before booting, or 'c' for a command-line.

SunOS Release 5.10 32-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

Hostname: pups
NIS domain name is sunsoft.eng.sun.com
Reading ZFS config: done.
Mounting ZFS filesystems: (8/8)

pups console login:
# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                      Complete Now    On Reboot Delete Status
-----------------------------------------------------------------
be1                        yes      yes    yes       no     
be10                       yes      yes    yes       no
# 

Booting the Failsafe Archive on an x86 Based System

To boot the failsafe archive on a x86 based system, select the failsafe boot entry when the GRUB menu is displayed during a system boot. During the failsafe boot procedure, when prompted by the system, type y to update the primary boot archive.

Failsafe booting is also supported on systems that are booted from ZFS. When booting from a UFS-rooted BE, each BE has its own failsafe archive. The failsafe archive is located where the root file system is located, as is the case with a ZFS-rooted BE. On x86 based systems, each failsafe archive has an entry in the pool-wide GRUB menu. The default failsafe archive is the archive that is in the default bootable file system. The default bootable file system (dataset) is indicated by the value of the pool's bootfs property.

Another method that can be used to update the boot archives is to clear the boot-archive service. See How to Update an Inconsistent Boot Archive by Clearing the boot-archive Service. However, the preferred methods for updating the boot archives are to boot the failsafe archive or use the bootadm command. For more information, see the Chapter 14, Managing the Solaris Boot Archives (Tasks).

How to Boot the Failsafe Archive on an x86 Based System by Using GRUB

The GRUB failsafe interaction in some Solaris releases prompts you to update the boot archives, regardless of whether any inconsistent boot archive are detected. In this Solaris release, the system only prompts you to update the boot archives if an inconsistent boot archive is detected.

1. Stop the system by using one of the methods described in the procedure, x86: How to Stop a System for Recovery Purposes.

2. If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt. Or, you can use the power switch to reboot the system.

   When the boot sequence begins, the GRUB menu is displayed.

   GNU GRUB version 0.95 (637K lower / 3144640K upper memory) +-------------------------------------------------------------------+ | be1 | be1 failsafe | be3 | be3 failsafe | be2 | be2 failfafe +------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.

   ---

   Note –

   The GRUB menu that is displayed may vary, depending on the Solaris release you are running.

   ---

3. Use the arrow keys to navigate the GRUB menu to select a failsafe entry.

4. Press Return to boot the failsafe archive.

   The system searches for installed OS instances. If an inconsistent boot archive is detected, a message similar to the following is displayed:

   Searching for installed OS instances... An out of sync boot archive was detected on /dev/dsk/c0t0d0s0. The boot archive is a cache of files used during boot and should be kept in sync to ensure proper system operation. Do you wish to automatically update this boot archive? [y,n,?]

5. Type y to update the boot archive.

   If multiple inconsistent boot archives are detected, the system will prompt you to type y to update each inconsistent boot archive.

   For each archive that is updated successfully, the following message is displayed:

   Updating boot archive on /dev/dsk/c0t0d0s0. The boot archive on /dev/dsk/c0t0d0s0 was updated successfully.

   After the boot archive is updated, the system searches again for all installed OS instances, then prompts you to select a device to mount on /a. Note that this same message is displayed when the system first boots if no inconsistent boot archives are detected.

   Searching for installed OS instances... Multiple OS instances were found. To check and mount one of them read-write under /a, select it from the following list. To not mount any, select 'q'. 1 pool10:13292304648356142148 ROOT/be10 2 rpool:14465159259155950256 ROOT/be01 Please select a device to be mounted (q for none) [?,??,q]:

   • If you choose not to mount a device, type q to continue to boot process.

   • If you choose to mount a device, follow these steps:

     1. Type the number of the device and press Return.

        The system mounts the device on /a, and returns you to a shell prompt.

     2. Repair the critical system resource.

     3. When you are done repairing the critical system resource, unmount the device.

        # umount /a

     4. Reboot the system.

        # reboot

x86: How to Boot the Failsafe Archive to Forcibly Update a Corrupt Boot Archive

This procedure shows how to rebuild an inconsistent or corrupt boot archive in the event you are not prompted by the system to update the boot archive the system, or in the event of a system hang or looping sequence occurs.

1. Stop the system by using one of the methods that are described in the procedure, x86: How to Stop a System for Recovery Purposes.

2. Reboot the system.

   # reboot

   If the system displays the Press any key to reboot prompt, press any key to reboot the system.

   You can also use the Reset button at this prompt.

   When the boot sequence begins, the GRUB menu is displayed.

   +---------------------------------------------------------------------+ | Solaris 10.1... X86 | | Solaris failsafe | | | | | +-------------------------------------------------------------------------+ Use the and keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.

   ---

   Note –

   The contents of the GRUB menus vary, depending on the Solaris release you are running.

   ---

3. Use the arrow keys to navigate the GRUB menu, then select the failsafe entry. Press Return to boot the failsafe archive.

   If any boot archives are out of date, a message that is similar to the following is displayed:

   Searching for installed OS instances... An out of sync boot archive was detected on /dev/dsk/c0t0d0s0. The boot archive is a cache of files used during boot and should be kept in sync to ensure proper system operation. Do you wish to automatically update this boot archive? [y,n,?]

4. Type y, then press Enter to update the inconsistent boot archive.

   The system displays the following message:

   Updating boot archive on /dev/dsk/c0t0d0s0. The boot archive on /dev/dsk/c0t0d0s0 was updated successfully.

   If no inconsistent boot archives are found, a message that is similar to the following is displayed:

   Searching for installed OS instances... Solaris 10.1... X86 was found on /dev/dsk/c0t0d0s0. Do you wish to have it mounted read-write on /a? [y,n,?]

   This message is also displayed after any inconsistent boot archives are updated successfully.

5. Mount the device that contains the corrupt boot archive on /a by typing the corresponding number of the device, then press Enter.

   ---

   Note –

   If any inconsistent boot archives were updated in the previous step, the device is already mounted on /a. Proceed to Step 6.

   ---

6. To forcibly update the corrupt boot archive, type:

   # bootadm update-archive -f -R /a

7. Unmount the device.

   # umount /a

8. Reboot the system.

   # reboot

Using Fast Reboot on the x86 Platform (Task Map)

x86: Fast Reboot Implementation

The following are key components of the Fast Reboot implementation:

• Two new options for the reboot command

  -f

  Initiates the fast reboot process, when used with the reboot command.

  -e

  Reboots the system to an alternate BE, when used in conjunction with the rebootcommand and the -f option.

  ---

  Note –

  The -e option cannot be used to fast reboot to an alternate BE in the OpenSolaris 2008.11 release. For instructions on rebooting to an alternate BE in this release, see x86: Initiating a Fast Reboot to an Alternate Boot Environment in the OpenSolaris 2008.11 OS.

  ---

• New quiesce Function

  The drivers' implementation of this function enables the driver to quiesce a device, so that at completion of the function, the driver no longer generates interrupts or access memory.

  See the quiesce(9E) and dev_ops(9S) man pages.

• New uadmin Function

  Fast Reboot also includes support for a new uadmin function, AD_FASTREBOOT. This function resets the system, enabling the reboot command to bypass both the BIOS and boot loader phases.

  For more information, see the uadmin(2)man page.

The following procedures and examples describe how to use the fast reboot capability on an x86 based system. For overview information, see the section, x86: Introducing Fast Reboot.

x86: How to Initiate a Fast Reboot of the System

This procedure describes how to use the reboot command with -f option to initiate a fast reboot of an x86 based system.

1. Become superuser or assume an equivalent role.

2. Initiate a fast reboot of the system:

   • To reboot to a new kernel, you would type:

     # reboot -f -- '/platform/i86pc/new-kernel-name/amd64/unix -k'

   • To initiate a fast reboot using boot arguments from the previous boot, you would type:

     # reboot -f

   ---

   Note –

   The boot archive is derived from the kernel argument. In the event of a failure in the fast reboot path, such as insufficient memory, the normal reset path is used.

   ---

Example 12–14 x86: Using Fast Reboot to Reboot a 64-Bit Kernel

# reboot -f -- '/platform/i86pc/kernel/amd64/unix'
Oct 21 15:06:35 tonyspizza reboot: initiated by ... on /dev/console
Oct 21 15:06:36 /usr/lib/snmp/snmpdx: received signal 15
Fast reboot.
syncing file systems... done
SunOS Release 5.11 Version onnv-gate:2008-10-20 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
DEBUG enabled
Hostname: tonyspizza
NIS domain name is lab.sfbay.sun.com
/dev/rdsk/c1d0s7 is clean
Reading ZFS config: done.

Example 12–15 x86: Using Fast Reboot Without Additional Boot Arguments

This example fast reboots a system using the boot arguments that were used for the previous boot.

# reboot -f
Oct 21 15:02:38 tonyspizza reboot: initiated by ... on /dev/console
Oct 21 15:02:38 tonyspizza rpcbind: rpcbind terminating on signal.
Oct 21 15:02:38 tonyspizza syslogd: going down on signal 15
Fast reboot.
syncing file systems... done
Loading kmdb...
SunOS Release 5.11 Version onnv-gate:2008-10-20 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
DEBUG enabled
Hostname: tonyspizza
NIS domain name is mpklab.sfbay.sun.com
/dev/rdsk/c1d0s7 is clean
Reading ZFS config: done.

x86: Initiating a Fast Reboot to a Specific UFS Boot Disk or a ZFS Root Pool

You can specify an alternate UFS boot disk in any of the following ways:

# reboot -f -- '/dev/dsk/c0t0s3'
# reboot -f -- '/dev/dsk/c0t0s3 -k'
# reboot -f -- '/dev/dsk/c0t0s3
# /platform/i86pc/mykernel/amd64/unix -k'

You can specify a ZFS root dataset in any of the following ways:

# reboot -f -- 'rpool/zfsbe1'
# reboot -f -- 'rpool/zfsbe2 -k'
# reboot -f -- 'rpool/zfsbe3 /platform/i86pc/mykernel/amd64/unix -k'

When rebooting to a different root (/) disk or root dataset by using a mount point or a boot environment, be aware that no transient menu entry is added to the menu.lst file.

x86: How to Initiate a Fast Reboot of a Directly Mounted Root Disk or Root Dataset

You can use Fast Reboot to directly mount a root (/) disk or root dataset, then reboot to it:

1. Become superuser or assume an equivalent role.

2. Mount the root (/) disk.

   For example:

   # mount /dev/dsk/c1d0s0 /mnt

   • To mount a root dataset, type:

     # zfs mount rpool/dataset

3. Reboot the mounted disk or mounted dataset.

   For example:

   # reboot -f -- '/mnt/platform/i86pc/kernel/amd64/unix'

x86: Initiating a Fast Reboot to an Alternate Boot Environment

You can optionally use the reboot command with the -f and -e options to specify an alternate BE.

# reboot -f -e alternate-be-name

The -e option has dependencies on Solaris Live upgrade packages, in particular the lumount and luumount commands. Because Solaris Live Upgrade is not supported in the OpenSolaris release, you cannot use this option to specify an alternate BE. Instead, use the -f option by itself to directly specifying the alternate dataset. See x86: Initiating a Fast Reboot to an Alternate Boot Environment in the OpenSolaris 2008.11 OS.

Example 12–16 x86: Using Fast Reboot to Reboot to an Alternate Boot Environment

This example shows how to fast reboot to an alternate BE by using the reboot command with the -f and the-e options. Note that in this example, the bootadm list-menu command is used to display a list of the bootable environments that are available on a system. A fast reboot of the s3 BE is then initiated.

# bootadm list-menu
The location for the active GRUB menu is: /boot/grub/menu.lst
default 0
timeout 10
0 Solaris Express Community Edition snv_82 X86
1 Solaris xVM
2 Solaris failsafe
3 s0
4 s0 Solaris xVM
5 s0 failsafe
6 s4
7 s4 Solaris xVM
8 s4 failsafe
9 s3
10 s3 Solaris xVM
11 s3 failsafe

# reboot -f -e s3

reboot: Halting 1 zone.
Oct 21 15:16:51 tonyspizza reboot: initiated by ... on /dev/console
reboot: Completing system halt.
Oct 21 15:16:57 tonyspizza syslogd: going down on signal 15
Fast reboot.
syncing file systems... done
SunOS Release 5.11 Version snv_99 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
DEBUG enabled
Configuring devices.
Hostname: tonyspizza
NIS domain name is lab.sfbay.sun.com
Loading smf(5) service descriptions: 2/2
/dev/rdsk/c1d0s7 is clean
Reading ZFS config: done.

x86: Initiating a Fast Reboot to an Alternate Boot Environment in the OpenSolaris 2008.11 OS

The -e option of the reboot command is not supported in the OpenSolaris 2008.11 release. To fast reboot to an alternate BE in this release, use the reboot -f command, directly specifying which dataset to boot. The following examples show how to fast reboot to an alternate BE by using this method.

For example to fast reboot to the zfsbe1 boot environment, you would type:

# reboot -f -- 'rpool/zfsbe1'

To fast reboot to the zfsbe3 boot environment, in 64-bit mode, with the kernel debugger enabled, you would type:

# reboot -f -- 'rpool/zfsbe3 /platform/i86pc/kernel/amd64/unix -k'

x86: Facilitating a Fast Reboot by Using the uadmin Command

To facilitate the use of the new -f option of the reboot command, the AD_FASTREBOOT function has been added to the current function list for the uadmin command. This function is recognized by commands that utilize these function numbers.

For example, to reset the system using the current boot arguments by using the fast reboot path, you would type:

# uadmin 2 8

Using the uadmin command to fast reboot a system does not update the boot archive or the menu.lst file.

For more information about this function, see the uadmin(1M) man page.

x86: Making Fast Reboot the Default Behavior of the reboot Command

To make a fast reboot the default behavior on your system, create a fastreboot file in the /etc directory.

# touch /etc/fastreboot

The addition of the fastreboot file on the system changes the default behavior of the reboot command, thereby eliminating the need to use the -f option to initiate a fast reboot.

To revert to the original behavior of the reboot command, remove the file.

# rm /etc/fastreboot

Note that removing this file does not remove fast reboot capability from the system.

x86: Troubleshooting Conditions That Might Prevent Fast Reboot From Working

The following are possible conditions under which the Fast Reboot feature might not work:

• Driver does not implement the quiesce function

  If you attempt a fast reboot of a system with an unsupported driver, a message similar to the following is displayed:

  Sep 18 13:19:12 too-cool genunix: WARNING: nvidia has no quiesce()
  reboot: not all drivers have implemented quiesce(9E)

  If the graphics drivers are the only drivers that do not support the quiesce function, you can attempt to force a fast reboot by running the following commands:

  # echo "force_fastreboot/W 1" | mdb -kw # echo "set force_fastreboot = 1" >> /etc/system

  If the driver for the Network Interface Card (NIC) does not implement the quiesce function, you can try to unplumb the interface first, then attempt a fast reboot of the system.

  # ifconfig your-nic-interface unplumb # reboot -f

• Insufficient memory

  If there is not enough memory on the system, below 1G (0x40000000) for building the page tables, or not enough free memory to load the new kernel and the boot archive, the fast reboot attempt fails with the following messages, then falls back to a regular reboot.

  Fastboot: Couldn't allocate size below PA 1G to do fast reboot Fastboot: Couldn't allocate size below PA 64G to do fast reboot

• Unsupported environment

  Fast reboot functionality is not currently supported in the following environments:

  • Solaris xVM dom0 domains

  • Solaris xVM PV domU domains

  • Non-global zones

Booting an x86 Based System from the Network

This section describes the requirements and warnings for performing a GRUB based boot from the network.

Any system can boot from the network, if a boot server is available. You might need to boot a stand-alone system from the network for recovery purposes if the system cannot boot from the local disk. You can boot a Solaris OS x86 based system directly from a network that supports the PXE network boot protocol.

The PXE network boot is available only for devices that implement the Intel Preboot Execution Environment specification.

The default network boot strategy that is used for a GRUB based PXE network boot is DHCP. For non-PXE devices, you can use either the DHCP or the RARP boot strategy. The strategy that you use depends on which type of boot server is available on your network. If no PXE or DHCP server is available, you can load GRUB from a diskette, a CD-ROM, or a local disk.

To perform a GRUB based network boot, a DHCP server that is configured for PXE clients is required. A boot server that provides tftp service is also required. The DHCP server supplies the information that the client needs to configure its network interface.

The DHCP server must be able to respond to the DHCP classes, PXEClient and GRUBClient with the following information:

• IP address of the file server

• Name of the boot file (pxegrub)

The sequence for performing a PXE network boot of the Solaris OS is as follows:

1. The BIOS is configured to boot from a network interface.

2. The BIOS sends a DHCP request.

3. The DHCP server replies with the server address and the name of the boot file.

4. The BIOS downloads pxegrub by using tftp and executes pxegrub.

5. The system downloads a GRUB menu file by using tftp.

   This file displays the boot menu entries that are available.

6. After you select a menu entry, the system begins to load the Solaris OS.

See How to Set Up a Network Configuration Server in System Administration Guide: IP Services for more information.

Running the add_install_client command creates the /tftpboot_01ethernet-address file. This file is linked to pxegrub and the/tftpboot/menu.lst.01ethernet-address file. The /tftpboot/menu.lst.01ethernet-address file is the GRUB menu file. If this file does not exist, then pxegrub reverts to using DHCP Option 150, if this option is specified, or the /tftpboot/boot/grub/menu.lst file. Typically, a single system is set up to serve both functions. In this instance, the add_install_client command sets up the /tftpboot file with the correct pxegrub menu file and the Solaris files. DHCP service is handled separately by using the add_install_client command. The setup only needs to be completed once per client. See x86: About DHCP Macros and x86: How to Perform a GRUB Based Boot From the Network for more information.

x86: About DHCP Macros

When you add clients with the add_install_client -d script on the install server, the script reports DHCP configuration information to standard output. You can use this information when you create the options and macros that are needed to pass network installation information to clients.

To install DHCP clients with a DHCP server over the network, you must create DHCP options. This information is needed to install the Solaris OS.

When a client sends a DHCP request, the server must have the following client information:

• Client's ID, which is typically the Ethernet address

• Class of the client request

• Subnet the client resides on

The Solaris DHCP server forms a response. This response is based on the following macros, which matches the client request:

class macro

The class macro is based on a class string that is contained in the DHCP request. On x86 based systems, the BIOS already makes a DHCP request with the class PXEClient:Arch:00000:UNDI:002001. If a macro by this name is defined in the DHCP server configuration, then the macro content is sent to the x86 based clients.

network macro

The network macro is named by the IP address of the subnet that the client resides on. If the macro 129.146.87.0 is defined on the DHPC server, the macro content is sent to all clients on that subnet. The macro content is sent, regardless of the class of the request. If an option is defined in both the class macro and the network macro, the network macro takes precedence.

IP macro

The IP macro is named by an IP address. This macro is rarely used

client macro

The client macro is named by the client type (01 for Ethernet) and the mac address of the client, in uppercase letters. For a client with the Ethernet address 0:0:39:fc:f2:ef, the corresponding macro name is 01000039FCEF. Note the absence of colons in the client macro.

For example, for a client on the subnet 192.168.100.0, with the Ethernet address 0:0:39:fc:f2:ef, making a DHCP request of class PXEClient, the DHCP server has the following matching macro:

PXEClient
	BootSrvA:  192.168.100.0
	BootFile:  pxegrub
  129.146.87.0
	Router:    129.146.87.1
	NISdmain:  sunsoft.eng.sun.com
  01000039FCEF
	BootFile:  01000039FCEF
The actual DHCP response will be
	BootSrvA:  192.168.100.0
	BootFile:  01000039FCEF
	Router:    129.146.87.1
	NISdmain:  sunsoft.eng.sun.com

Note that the BootFile in the client macro overrides the BootFile in the class macro.

For more detailed information, see Preconfiguring System Configuration Information With the DHCP Service (Tasks) in Solaris Express Installation Guide: Network-Based Installations.

x86: How to Perform a GRUB Based Boot From the Network

To perform a GRUB based network boot a DHCP server that is configured for PXE clients is required. A boot server that provides tftp service is also required. The DHCP server must be able respond to the DHCP classes, PXEClient and GRUBClient to obtain the IP address of the file server and the boot file (pxegrub). By default, the menu file is /tftpboot/menu.lst.01ethernet-address. If this file does not exist, then pxegrub reverts to DHCP Option 150, if this option is specified, or the /tftpboot/boot/grub/menu.lst file.

If you are booting the system from the Solaris Software 1 CD or DVD, the system boots automatically.

Before You Begin

Before performing a network boot on an x86 based system with GRUB, do the following:

• Run the appropriate commands on the installation server to enable the system to boot from the network.

• Add the client system as an install client.

See Chapter 4, Installing From the Network (Overview), in Solaris Express Installation Guide: Network-Based Installations for more information.

1. On the DHCP server, create a client macro for the DHCP service with the following two options:

   • BootSrvA: svr-addr

   • BootFile: client-macro

     Note that you must have superuser privileges on the DHCP server to run the dhtadm command.

     where svr-addr is the IP address of the server, and client-macro is named by the client's Ethernet type (01) and the mac address, in uppercase letters. This number is also the name of the file that is used in the /tftpboot directory on the installation server.

     ---

     Note –

     The notation for the client-macro should not contain any colons.

     ---

     You can create the client macro from the DHCP GUI or from command-line interface.

     To create the client macro from the command-line, type:

     # dhtadm -[MA] -m client macro -d ":BootFile=client-macro:BootSrvA=svr-addr:"

2. Reboot the system.

3. Instruct the BIOS to boot from the network.

   • If your system uses a specific keystroke sequence to boot from the network, type the keystrokes when the BIOS screen is displayed.

   • If you need to manually modify the BIOS settings to boot from the network, type the keystroke sequence to access the BIOS setup utility. Then, modify the boot priority to boot from the network.

4. When the GRUB menu is displayed, select the network installation image that you want to install.