IRIX Bare Metal Recovery

From Backup Central


Some chapters from Unix Backup & Recovery did not make it into Backup and Recovery. We have added these original chapters to the Wiki in hopes that some of you will help us maintain it.

This chapter explains the procedure that you would use to recover your SGI IRIX operat­ing system disk in case of a complete system failure—when you are left with nothing but bare metal. For suggestions on how to avoid this situation, please read the first section of Chapter 7, SunOS/Solaris.

Before discussing bare-metal recovery of an IRIX system, it is important to discuss the layout of an IRIX system, since it is a little different from most other flavors of Unix that use Berkeley (BSD) style partitioning. At a minimum, an IRIX system disk contains four partitions. The first partition that contains data is partition 0, the root partition, and parti­tion 1 is the first swap partition. Partition 10, the volume, is the whole disk, overlapping all the other partitions. The very first partition physically on a system disk is partition 8, the volume header. It starts at block 0 and contains the system disk parameters, partition table, and volume directory as well as any programs that are necessary for booting, such as sash, the standalone shell. sash is required to be in the volume header of the system disk; we talk more about sash later in this section. Some system disks will have an addi­tional partition for /usr, which is partition 6. System disks that have XFS filesystems with external XLV log partitions also have an additional partition, number 15, called the xfs­log partition. This could be used with a separate /usr partition since the root partition can­not have an external XLV log.

When you install IRIX or are going to be performing a bare-metal recovery, it is impor­tant to note that the miniroot, which contains the installation tools, is copied to partition 1 (swap) of the system disk; any data that the miniroot contains will be trashed. It is there­fore advantageous to follow the IRIX standard partitioning scheme described in the pre­ceding paragraph. Any nonstandard partitioning and disk schemes aren’t discussed here; if you’ve done any customization like that, it is hoped that you know what you’re doing already.

All of the bare-metal recoveries discussed in this chapter assume that the boot PROM has not been corrupted or changed from a default IRIX installation. In other words, the boot device and boot filename have not been changed or customized.

This chapter describes two backup/recovery tools: the one that SGI provides for the IRIX operating system and the IRIX version of the homegrown procedure introduced in Chapter 7.

This chapter was written by Blayne Puklich. Blayne works on as many Unix platforms as he can get his hands on. He likes to mountain bike and listen to extremely loud music in his spare time.

Contents

SGI’s Backup and Restore Utilities

SGI’s IRIX operating system has two built-in bare-metal recovery commands, surpris­ingly enough called Backup and Restore. Backup is a shell script that performs full and incremental system backups. The Backup commands under IRIX 5.3, 6.1, and 6.2 all use the Bru command, IRIX 6.3 and 6.4 use tar, and IRIX 6.5 uses cpio. Only a full Backup can be read by the Recover System Maintenance Menu choice; no other backup method is supported. A full Backup contains sash as well as the contents of every local filesys­tem on the system.

Restore is also a shell script that can recover files from a Backup tape. (sash cannot be recovered this way.) The command is backward compatible; the Restore command from IRIX 6.5 can read cpio, tar, and Bru backups. Restore is not used for bare-metal recov­ery. The Recover System Maintenance Menu choice is used for that.

The value provided by IRIX’s built-in bare-metal recovery tools is significantly reduced once you deviate from the standard disk-partitioning scheme.

Standard Backup Commands

SGI recommends unmounting and running fsck against each filesystem that you want to back up. It is probably sufficient, however, just to make sure the system is fairly quiet. You also can perform a backup while in single-user mode for some added security.

You can run Backup either graphically, using the Toolchest, or from the command line; both methods will create a tape that can be used by the Recover command. Make sure that you do not have any CD-ROMs mounted, because Backup will happily back them up for you.

To use the graphical version, choose the System Manager menu choice from the System Toolchest. From the menu on the left side of the System Manager, choose Files & Data, and then choose either Backup Files or the Backup and Restore Manager. Starting the backup from either choice is straightforward; just perform a full system backup to an attached tape drive or to a drive attached to another SGI system that you have permission to use.

To create a recoverable system backup from the command line, place a blank tape in the tape drive and invoke the Backup command, specifying that you want to back up from root:

# Backup /

The default tape drive to write to is /dev/nrtape. If this is not the tape drive you wish to use, you must specify a different tape drive. The full command with options, from the Backup manpage, is the following:

# Backup [-h hostname] [-i] [-t tapedevice] [directory_name | file_name]

To back up your system to the tape drive /dev/rmt/tps0d3nr (a tape drive set to SCSI ID 3 attached to SCSI controller 0), you would use this command:

# Backup –t /dev/rmt/tps0d3nr /

An example command for backing your system up to a tape drive attached to another SGI system is:

# Backup –h tapehostt /dev/rmt/tps0d3nr /

This would back up your system to the tape drive /dev/rmt/tps0d3nr attached to the sys­tem called tapehost, assuming you have permission to do so. All that is required is that root on the system you are going to back up can start a remote shell as the user guest on tapehost.

Keep in mind that only a full Backup can be restored from the Recover System System Maintenance Menu choice, so you cannot specify -i to the Backup command if you expect to be able to use that tape for bare-metal recovery.

You can use the List_tape command to list the contents of a Backup tape that was previ­ously created:

# List_tape

This command also defaults to the tape drive /dev/nrtape. The options for List_tape are quite like Backup; listing the contents of a Backup tape in the tape drive /dev/rmt/tps0d3 can be accomplished by using this command:

# List_tape –t /dev/rmt/tps0d3nr

To list the contents of a tape in the tape drive /dev/rmt/tps0d3nr attached to tapehost, we would just add the -h option:

# List_tape –h tapehostt /dev/rmt/tps0d3nr

To do this, you also need the correct permission to use the tape drive on tapehost. You can read more about List_tape in its manpage.

Making Bootable Tapes

In order to make bootable tapes, you need your original IRIX installation media, which can be either a tape or a CD-ROM, and a blank tape. These tapes are useful if you prefer not to use your original installation media for recovery purposes or do not always have bootable installation media available.

Bootable tapes are supported only by IRIX 5.3 and 6.1. None of the newer versions of IRIX can boot from tape; they must be booted from CD-ROM.
You can copy an installation tape and make a bootable tape if you have two tape drives or one tape drive and sufficient disk space. Creating a bootable tape from a CD-ROM requires a CD-ROM drive, a tape drive, and a blank tape. Bootable tapes are just tapes that have the sa (standalone) image as well as possibly an IRIX installation image on them. These tapes are created using the distcp command; refer to the distcp manpage for more information.

Two tape drives

If you have two tape drives and your installation media is also a tape, you can make a bootable tape from your installation tape and also make a complete copy of the installa­tion tape at the same time. Write-protect and insert your installation tape into one of your tape drives and the blank tape into the other, and issue a command like the following:

# distcp device1 device2

Replace device1 with the name of the tape drive containing the installation tape, and device2 with the name of the tape drive that has the blank tape. You must specify a no- rewind tape drive name for the source drive device1, such as /dev/nrtape.

One tape drive

To copy from tape to tape with only one tape drive, follow these steps. Note that you must have sufficient disk space in order to copy your entire installation tape.

  1. Insert your IRIX installation tape into your tape drive. Issue these commands:

# mkdir /usr/tmp/dist
# distcp /dev/nrtape /usr/tmp/dist
# mt -f /dev/nrtape rewind

  1. Eject the IRIX installation tape and insert the blank tape for copying.

Use either of the following two versions of the distcp command. This first version copies just the standalone image to the blank tape to make it bootable:

# distcp /usr/tmp/dist/sa /dev/tape

This second version makes a copy of the entire distribution, as well as the standal­one image:

# distcp /usr/tmp/dist/* /dev/tape

  1. Finally, rewind and clean up any temporary files:

# mt -f /dev/tape rewind
# rm -rf /usr/tmp/dist

  1. Eject the new bootable tape. Make sure to write-protect and label the tape!

CD-ROM and tape drive

You can make a bootable tape from an installation CD-ROM by just copying the standal­one image to a blank tape. Put your installation CD-ROM into the CD-ROM drive and the blank tape into your tape drive, and issue this command:

# distcp CD-ROMhost:/CD-ROM/dist/sa /dev/tape

In this example, we have specified that we want to use a CD-ROM drive attached to the SGI system called CD-ROMhost; as with Backup and List_tape, you need the correct guest permissions in order for this to succeed.

System Recovery with Backup Tape

Bare-metal recovery on an SGI system can be performed by the Recover System Mainte­nance Menu choice as long as you have a full backup tape made with the Backup com­mand. When an SGI system boots, you are given a chance to stop the boot process by pressing the Escape key, which will present the System Maintenance Menu. If the SGI system has a graphics capability, you can either press Escape or click on the Stop for Maintenance button. Note that some SGI systems are configured to always stop at the System Maintenance Menu, so this step may not be necessary (the menu just appears).

Starting up the system...

To perform system maintenance instead, press Esc

Your system should stop and print out the following System Maintenance Menu, or dis­play it graphically.

System Maintenance Menu
(1) Start System
(2) Install System Software
(3) Run Diagnostics
(4) Recover System
(5) Enter Command Monitor

To start bare-metal recovery, you first should boot the standalone version of fx to ensure that the system disk partition table is intact. You can do this from either a local CD-ROM drive or a remote directory. To boot the standalone fx from a local CD-ROM drive, first choose option 5, enter Command Monitor. At the command monitor, you first should make sure that all the hardware you expect to be available is shown by the hinv com­mand:

>> hinv
System: IP22
Processor: 250 Mhz R4400, with FPU
Primary I-cache size: 16 Kbytes
Primary D-cache size: 16 Kbytes
Secondary cache size: 2048 Kbytes
Memory size: 256 Mbytes
Graphics: GR3-XZ
SCSI Disk: scsi(0)disk(1)
SCSI CD-ROM: scsi(1)CD-ROM(3)
SCSI Tape: scsi(1)tape(4)
Audio: Iris Audio Processor: version A2 revision 0.1.0

Next, boot the standalone fx program. The filenames of the sash and fx programs for the various SGI processor types are included in Table 11‑1.

Table 11‑2: sash and fx Programs for Different Architectures (continued)

CPU Architecture

sash

fx

IP17

sashIP17

fx.IP17

IP19, IP20, IP22, IP32

sashARCS

fx.ARCS

IP21, IP25, IP26, IP27, IP30

sash64

fx.64

To boot from a local CD-ROM drive, use a command like this:

>> boot –f dksc(1,3,8)sashARCS dksc(1,3,7)stand/fx.ARCS --x

Replace dksc(1,3,8) and dksc(1,3,7) with the appropriate CD-ROM drive from the hinv output of the system being recovered, and sashARCS and fx.ARCS with the appropriate standalone program names from the table. Some of the sash and fx filenames have the processor type as a suffix, such as sashIP17 and fx.IP17. To boot fx from a remote machine, check to make sure the boot PROM variable netaddr is set to the sys­tem’s IP address, then issue the boot command:

>> printenv netaddr
netaddr=192.0.2.1
>> boot –f bootp()remote:/CD-ROM/stand/fx.ARCS –x

The fx program will prompt you for the device name of the disk, the controller number, and the drive number; the default values are what most systems would use:

fx: "device-name" = (dksc)
fx: ctrl# = (0)
fx: drive# = (1)

You should check for any existing partition information using the /show/label/partition command. If the partition information appears to be correct, you can exit fx to return to the System Maintenance Menu; if not, you have to correct the partition information. Most standard SGI system disks use either the rootdrive or usrrootdrive partition template, which can be found in the repartition submenu of fx. Make sure to use the /label/sync command to ensure that the system disk partition table is written out, and then use the exit command to leave fx and return to the System Maintenance Menu.

Now we can start the system recovery by choosing menu option 4, Recover System. The system may display the following, or an equivalent if graphics are available:

System Recovery...

Press Esc to return to the menu.

From this point on, the prompts and your responses will differ depending on the age of the system.

Older SGI Systems

Some older SGI systems present you with the following prompt after a short time:

Insert the installation tape, then press <enter>:

At this point you would make sure that either a bootable tape (your IRIX installation tape will work) is loaded into a local tape drive or that an IRIX installation CD-ROM is in a local CD-ROM drive. You then would press Enter to start loading the miniroot onto par­tition 1 of the system disk. Note that this procedure requires that the installation device be physically attached; booting from a remote system is described later. After a few min­utes, the system prompts you for the type of restore:

CRASH RECOVERY
You may type sh to get a shell prompt at most questions.
Remote or local restore: ([r]emote, [l]ocal): [l]

Choose the appropriate type of restore, either remote or local. If you choose remote, the system prompts you for the name of the remote host and the tape drive name on the remote host. Make sure that your Backup tape is in the remote tape drive, and enter the IP address for the remote host as well as the name of the tape drive. If you choose to per­form a local restore, the system prompts you only for the name of the local tape drive. Make sure that the Backup tape is in your local tape drive, and enter the full name of the tape drive rather than /dev/tape. As an example, if you want to use a tape drive that is set to SCSI ID 3 and is attached to SCSI controller 0, you would use /dev/rmt/tps0d3nr.
If you do not have a tape or CD-ROM locally attached to the system you are recovering, you will need to enable tftp on a remote system and configure the boot PROM to enable booting across the network. On the remote system, edit the file /usr/etc/inetd.conf. Find the line that contains tftp and change it to be the following:

tftp dgram udp wait guest /usr/etc/tftpd tftpd

This allows tftp full access to the filesystems on the remote system; make sure to either change this line back to what it was before or comment it out completely once the recov­ery is completed. Also, make sure that you use Tabs for the whitespace separating the individual words. Next, signal inetd on the remote system by sending it a HUP signal. On some older versions of IRIX, inetd is broken, requiring you to issue a killall -9 inetd and restart it by hand.
Now you need to configure the system you are recovering to boot from the remote sys­tem. Rather than choosing menu item 4 from the System Maintenance Menu, choose item 5, Enter Command Monitor. Issue the following PROM commands:

>> setenv netaddr ip-address
>> init
>> exit

Replace ip-address with the IP address of the system you are recovering, not the remote system. When the system returns to the System Maintenance Menu, choose item 4, Recover System, and follow the preceding steps for recovering.

Newer SGI systems

Newer systems will present you with this short menu, or something much like it if graph­ics are available, for specifying where the installation media is:

1) Remote Tape 2) Remote Directory 3) Local CD-ROM 4) Local Tape

Enter 1-4 to select source type, Esc to quit,
or Enter to start:

Choices 1 (Remote Tape) and 4 (Local Tape) are not supported as bootable as of IRIX 6. 2. To start recovery using a local CD-ROM, put your installation CD-ROM into the CD- ROM drive and choose item 3. Choose item 2 for either a remote CD-ROM or a remote software distribution directory. The system prompts you for the local system’s IP address, if not set by the boot PROM, and the remote hostname and directory. The format should be remotehost:/'directory/dist, where remotehost is the name of the remote host, and directory the name of the remote directory. If you want to use a remote CD-ROM drive, the remote host name might look much like:

remotehost:/CD-ROM/dist

When using a remote software distribution directory, the remote hostname contains just the full pathname to the directory, like:

remotehost:/directory/dist/6.3

The system returns to the Source Type menu; press Enter to begin reading the installa­tion tools to partition 1 of the system disk. After a few minutes, the following is dis­played:

************************************************************
* *
* CRASH RECOVERY *
* *
************************************************************

You may type sh to get a shell prompt at most questions

Please enter your hostname (system name) : muddy
Please enter the IP address for muddy's
Integral Ethernet interface (ec0): 172.16.0.1

Starting networking with primary hostname muddy

Checking for tape devices

If the system you are recovering has a locally attached tape drive, you will see the follow­ing:

Restore will be from /dev/tape. OK? ([y]es, [n]o): [y]

If this is correct, press Enter. If not (and you answer no to the prompt) or if a local tape drive cannot be found, then the following is displayed:

Remote or local restore ([r]emote, [l]ocal): [l]

At this point, choosing [l]ocal allows you to specify a different local tape drive if the pre­vious message was incorrect. Choosing [r]emote asks you for the remote hostname and the remote tape drive name. The system then prints out tape drive status information and prompts you for the first tape:

Insert the first Backup tape in the drive, then
press (<enter>, [q]uit (from recovery) ,[r]estart):

Insert the first full Backup tape and press Enter. After a few minutes, messages like the following will be shown:

Backup is a cpio archive
label: Full system backup from /
Thu Feb 25 17:25:47 PST 1999
user: root
group: sys
IRIX muddy 6.5 05190003 IP22
IRIX 6.5:1274627333 built 4/29/98 at zebub:/xlv55/kudzu-apr12/root $
options: /sbin/cpio -KWovO /dev/tape
Do you want to proceed ([y]es, [r]etry, [q]uit): [y]

If this is the correct tape information, press Enter and the system configuration files will be read. Next, you will have the opportunity to re-create the filesystems on the system disk:

Erase all old filesystems and make new ones (y, n, sh): [n]

Choosing y will destroy any data remaining on your system, while choosing n will allow you to preserve the old filesystems. You also can choose sh for a shell, which will let you use the miniroot commands to poke around your old filesystems to see if anything can be salvaged.

If you choose y, the system asks you for confirmation when rebuilding each filesystem. If you choose n, or when you finish rebuilding the filesystems, a table of the currently mounted filesystems will be displayed. If everything is there, press Enter to start recov­ery from the Backup tape. Once that has completed, it will ask if you want to read any incremental Backup tapes, at which point you can choose to do so. The very last step allows you to read the first Backup tape again, start over from the beginning, or reboot the recovered system:

Reboot, start over, or first tape again? ([r]eboot, [s]tart, [f]irst) [r]

If you haven’t made any mistakes, you should choose to reboot. Congratulations! Your SGI system should be in the same state that it was when the Backup tape used for recov­ery was created.

Homegrown Bare-Metal Recovery

This procedure for recovering a failed SGI IRIX system takes a few shortcuts from what SGI would have you do. Their recommendation is to perform an IRIX installation, fol­lowed by the use of restore (or xfsrestore for restoring XFS dumps). We will bypass the IRIX installation and instead use the miniroot to perform the bare-metal recovery.

In order to perform this type of bare-metal recovery you will need the correct IRIX instal­lation tape or CD-ROM or a bootable IRIX tape (only for IRIX 5.3 and 6.1). You also will need your current dump volumes, along with a listing of which partitions are on what volumes and in what order, and printed copies of the output of the hinv command, the system’s partition and volume header information, and the /etc/fstab file. You might guess that it is a little difficult to keep track of how many tape files a dump is made up of and much easier to recover a system during a panic situation if you keep your dump vol­umes simple.

The installation media and configuration information needs to be gathered before disas­ter strikes. You should periodically print out all of the system configuration information. It is very difficult, if not impossible, to return a failed system to its original state without these things.

Finding the partition information for each drive can be accomplished using the prtvtoc command. You would run the command once for each disk drive attached to the system and print the results:

# prtvtoc /dev/rdsk/dks0d1vh

This command would print the volume table of contents, or partition information, for the SCSI drive on controller 0 with SCSI ID 1, which is typically the system disk. Another way to gather this information is by using fx:

# echo "/label/show/partition" | fx 'dksc(0,1)'

This shows the same information for the SCSI drive on controller 0 with SCSI ID 1 but in a format that might be easier to use, since we will be using fx during system recovery. You can use the dvhtool command to list the contents of the system disk volume header:

# dvhtool –v list /dev/rvh

We need this list to know what standalone files to put into the volume header if the header becomes damaged. Usually, the only standalone files that might have to be rein­stalled are sash and possibly ide. If the system has any LV logical volumes, you will need a printed copy of /etc/lvtab. Note that the system’s actual root and swap partitions cannot be LV volumes, but if /usr is separate, it is conceivable that it may have been grown by making it into an LV vol­ume and adding an additional partition; recovering this case is beyond the scope of this book. You also will need a printed copy of the XLV configuration if it is using any XLV vol­umes, as well as a printed listing of the contents of the /dev/dsk/xlv directory. The root filesystem can be an XLV mirror (also called a plex), and /usr may have also been grown on the fly by making it an XLV volume and adding an additional partition. Recovering a / usr filesystem that has been changed in this way is beyond the scope of this book.
To create a file that contains a script that will duplicate your XLV configuration, you can use the xlv_mgr command. This is the same way that the IRIX Backup script extracts the configuration:

# echo "script all\nquit\n" | xlv_mgr > /tmp/xlv_config_script

To begin a bare-metal recovery, we will start out as if we are performing recovery with a Backup tape. We need to get the SGI system to the System Maintenance Menu. If your system prints messages like the following, either press Escape or click on the Stop for Maintenance button, if available:

Starting up the system...

To perform system maintenance instead, press Esc

Your system should then stop and print out the System Maintenance Menu:

System Maintenance Menu
(1) Start System
(2) Install System Software
(3) Run Diagnostics
(4) Recover System
(5) Enter Command Monitor

This is where we deviate from the steps for bare-metal recovery using a Backup tape. Our methods will now be more down and dirty.
First, we enter the Command Monitor to make sure all of our hardware is visible. Use the hinv command, paying special attention to the type of processor the system has and the SCSI disk, CD-ROM, and tape drives. We also will set the PROM variable AutoLoad:

Command Monitor. Type "exit" to return to the menu.
>> hinv
System SGI-IP27
2 180 MHz IP27 Processors
Main memory size: 640 Mbytes
Integral SCSI controller 0
Integral SCSI controller 1
Integral Fast Ethernet
IOC3 serial port
Integral SCSI controller 2
Integral SCSI controller 3
Disk drive: unit 1 on SCSI Controller 0, (dksc(0,1,0))
Disk drive: unit 4 on SCSI Controller 0, (dksc(0,4,0))
Disk drive: unit 6 on SCSI Controller 0, (dksc(0,6,0))
CD-ROM: unit 6 on SCSI Controller 1, (CD-ROM(1,6,7))
Tape drive: unit 3 on SCSI Controller 2
>> setenv AutoLoad No

Write down the processor type, the disk drive names (dksc(0,1,0)), the CD-ROM drive names (CD-ROM(1,6,7)), and the tape drive information (controller 2, SCSI ID 3). (This information may already be in the printed hinv output gathered while the system was alive.) Setting AutoLoad prevents the system from booting, stopping it at the System Maintenance Menu. If the system does not have an ARCS PROM, the older bootmode variable has to be set instead:

>> setenv bootmode m

(You will know if the system has an ARCS PROM based on the name of the sash and fx programs from the previous table.)

The next step is to boot the standalone fx program from the Command Monitor prompt to repair the system disk partitioning. You can boot either from a locally attached CD-ROM drive or from a CD-ROM drive on a remote system. The filenames of the sash and fx pro­grams for the various SGI processor types are included in the previous table.

To boot fx from a local CD-ROM drive, use a command like this:

>> boot –f dksc(1,6,8)sashARCS dksc(1,6,7)stand/fx.ARCS --x

Replace dksc(1,6,8) and dksc(1,6,7) with the appropriate CD-ROM drive from the hinv output of the system being recovered, and sashARCS and fx.ARCS with the appropriate standalone program names from the table. To boot fx from a remote machine, check to make sure the boot PROM variable netaddr is set to the system’s IP address, then issue the boot command:

>> printenv netaddr
netaddr=172.16.0.1
>> boot –f bootp()remote:/CD-ROM/stand/fx.ARCS –x

The fx program will prompt you for the device name of the disk, the controller number, and drive number; the default values are what most systems would use:

fx: "device-name" = (dksc)
fx: ctrl# = (0)
fx: drive# = (1)

Before making any changes, it may be valuable to check for any existing partition infor­mation using the /show/label/partition command. If the partition information appears to be correct, you can exit fx to return to the System Maintenance Menu; if it is not correct, you will have to duplicate the partition information previously gathered. Most system disks have either the rootdrive or usrrootdrive partition scheme. If the partitioning is not standard, it may speed things up to start with a rootdrive template and modify it. Make sure to use the /label/sync command to make sure that any changes to the partitioning are written to the volume header.
Once we have partitioned our system drive, we will boot the miniroot as if we were going to perform an IRIX installation. Choose menu item number 2, Install System Software. The system will then ask you for the source of the installation media. Select either the locally attached CD-ROM or a remote tape or directory.

To boot from a remote system, you will need to perform some of the same steps that were necessary for recovery using a Backup tape. You need to enable tftp on the remote sys­tem by editing the file /usr/etc/inetd.conf and changing the tftp line to the following:

tftp dgram udp wait guest /usr/etc/tftpd tftpd

This allows full access to the filesystems on the remote system. You should change this back to its previous value when you are finished with the recovery. Then, signal inetd by sending it a HUP signal.

Back on the system you are recovering, it will ask you for the local system’s IP address (if not set by the boot PROM), the remote system name, and the path to the installation directory. On older SGI systems, you may have to set the boot PROM variable netaddr to the local system’s IP address.

Once you tell the system where to install from, the system begins to load the installation tools to the swap partition. It prints out some messages and possibly shows a status bar as the installation tools are copied and the IRIX kernel boots. If the filesystems were com­pletely destroyed, the system will ask you to make new ones as necessary. When creat­ing a new XFS filesystem, it may ask you for a block size; just use 4096 unless there are some special requirements. There also may be partitions that the system is able to mount but that are, in fact, very corrupted. If this happens, the system will print out messages to that effect, then stop and prompt you with:

Press Enter to invoke C shell csh:

You should choose to launch the shell at this time. From the shell, you can use the mount command to see what mounted. You can run mkfs for each filesystem from the shell, but the quickest way to correct any corrupted filesystems may be to umount all of the system disk filesystems, exit the shell, and run the inst command admin mkfs. This will prompt you to rebuild each filesystem, and remount everything once it’s complete. To do this, launch the shell, and immediately exit. The system will attempt to mount the remaining partitions, fail and launch the inst program. Sometimes you will need to run admin mkfs twice because of problems with unmounting filesystems. If all of the system disk partitions are mounted and correct, the system just loads the inst program. After inst loads, you should check and reset the system date if necessary:

Inst> admin date
Sat Jan 16 21:36:01 CST 1999
Inst> admin date mmddhhmm[cc]yy

Once you have checked the system date, you can launch a shell using the inst command admin sh and begin to recover the system disk filesystems. You should first unmount all of the disk filesystems except for /root:

# mount
/dev/miniroot on / type xfs (rw)
/proc on /proc type proc (rw)
/hw on /hw type hwgfs (rw)
/dev/dsk/dks0d1s0 on /root type xfs (rw)
/hw on /root/hw type hwgfs (rw)
/dev/dsk/dks0d1s6 on /root/usr type xfs (rw)
# umount /root/usr

If the root filesystem was an XLV plex, you should force the plex to be re-created from the restored root filesystem by using the xlv_set_primary command:

# xlv_set_primary /dev/dsk/dks0d1s0
# rm –rf /dev/dsk/xlv /dev/rdsk/xlv
# xlv_assemble –Pq –h muddy

Replace /dev/dsk/dks0d1s0 with the name of the root partition on the system disk, and muddy with the system’s hostname. You then may want to compare the contents on / dev/dsk/xlv with the printed copy you made while the system was alive, and repair any­thing that is missing using commands from the script created by running the xlv_mgr script all command.

If your system was dumped using xfsdump, recovering the root filesystem can be done with a command like the following, after you place the level-0 dump tape for root into the tape drive:

# xfsrestore –r –f /dev/nrtape /root

You should replace /dev/nrtape with the appropriate tape drive name, derived from the output of hinv, if /dev/nrtape is not the correct tape drive. Using the -r flag tells xfsre­store that you will potentially be restoring not only a level-0 xfsdump, but some higher incremental levels as well. If you used dump to back up your filesystems, you could recover your root filesystem with commands like this:

# cd /root
# restore rf /dev/nrtape

If necessary, recover the /usr filesystem by mounting it on /root/usr, putting the correct dump tape into the tape drive, and using either xfsrestore or restore:

# For xfsdump
# mount /root/usr
# xfsrestore –r –f /dev/nrtape /root/usr
# For dump
# mount /root/usr
# cd /root/usr
# restore rf /dev/nrtape

Use the same procedure for recovering any additional filesystems as required and for recovering any higher-level dumps for the system disk filesystems.
Once you have recovered all of the filesystems on the system disk, you need to use dvh­tool to copy sash and any other necessary files from the installation CD-ROM to the vol­ume header to make the system disk bootable. Mount the CD-ROM if it’s not already mounted, run dvhtool, and create the volume header files:

# mkdir /CD-ROM
# mount -t efs -o ro /dev/dsk/dksld3s7 /CD-ROM
# cd /CD-ROM/stand
# dvhtool /dev/rdsk/dks0d1vh

Command? (read, vd, write, or quit): vd
(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
l

Current contents:
File name Length Block #
sgilabel 512 2

(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
c sashARCS ide
(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
c sashARCS sash
(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
l

Current contents:
File name Length Block #
sgilabel 512 2
ide 316416 3
sash 316416 621

(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? <Return>

Command? (read, vd, write, or quit): write

Command? (read, vd, write, or quit): quit

Replace /dev/dsk/dks1d3s7 with the correct CD-ROM device name and /dev/ rdsk/dks0d1vh with the name of the volume header for the system disk.
You now should have a bootable system disk with everything restored. Exit from the shell and issue the inst the exit commands; do not use the quit command because inst will try to rebuild the kernel, and that can cause problems. The system then will prompt you for rebooting:

Ready to restart the system. Restart? { (y)es, (n)o, (sh)ell, (h)elp) }:

Restarting the system will bring it up into multiuser state, which you probably should not do until you check the rest of the filesystems. You can force the system to halt by launch­ing a shell from the prompt and using the uadmin command:

# uadmin 2 0

Then you can reboot to single-user mode by going to the command monitor from the Sys­tem Maintenance Menu and typing single at the command monitor prompt. When the system is up, recover the remaining drives and rebuild any LV or XLV volumes as neces­sary. Check the partition tables using fx -x, build filesystems using mkfs, mount and restore the filesystems using either xfsrestore or restore depending on the type of dump used. If only the system disk was lost, more than likely the rest of the data on the system is still intact, so you may not need to do any of these steps.
At this point, you should have a fully recovered system. You now can check and reset the AutoLoad PROM variable back to Yes and halt the system:

# nvram AutoLoad
N
# nvram AutoLoad Y
# halt

Finally, you can remove the xfsrestorehousekeepingdir directories from any filesystems that you recovered using xfsrestore. You now should be able to boot your system into multiuser mode.