Disaster recovery for Digital Unix

{short description of image}

This document describes disaster recovery procedures for Digital Unix in the event that a boot disk must be restored from backup tape.  This can happen either due to hardware failure, or due to software corruption.  There are two cases that differ in important ways.  One assumes that the recovery is occuring on the same system that the backups were done on, or that the system hardware configuration is substantially the same.  The other case is that they restoration is being done on different hardware.

Key hardware differences that matter would be the model of the system, the bus and target number of disk drives, the cards in the system and the exact slot that they were in.  This information is "hardwired" into the kernel or is contained in the system configuration files such as /etc/fstab or the /etc/fdmns directory tree.  Other items such as memory size and disk sizes are usually only critical if the newly restored system has smaller disks or less memory.  This could cause problems if new file systems were too small for the restored files, or if the amount of memory was too small to support parameters used in database startup.

The first case is the easier one to deal with.  It is also the one that is more likely to occur.  It may happen due to a patch installation that goes wrong, or if there is a disk hardware problem that is not recovered by disk mirroring.  The other case could occur if there was a true disaster recovery situation.  In this case, you may be restoring a system image onto a different model of system.  You are likely to at least have your adaptor cards or available disks be different than your original system.
 

Document Sections:


Information to know before hand:

Proper preparation is the key to being able to recover a system in a timely manner.  This information needs to be available if the system is down and the old boot disks are inaccessable.  This information can be difficult to pry out of a dead system.  This information can be documented on hard copy, or archived on other systems unlikely to be affected by the problem involving the first system.  You can also record this information to a specific directory on the system in question as long as this information is easily recovered from backup tape before the rest of the system recovery procedes.  Information to recorded includes:

And of course, you will need a current system backup.

Digital's "sys_check" facillity can be used to automatically document most of the information you need for disaster recovery.

<top> <table of contents> <Digital Unix overview>

Starting Point / Common procedures:

These procedures are the same regardless of what kind of file system and disk subsystem you have in use on the system in question.

# cd /dev

# ./MAKEDEV rz0 

# ./MAKEDEV tz5 
# disklabel rz0 > /tmp/saved.label 

# disklabel -e rz0


 

<top> <table of contents> <Digital Unix overview>

UFS Recovery:

NOTE: As of Digital  Unix 4.0D, "vrestore" is capable of backing up and restoring both UFS and ADVFS file systems.  If you used "vrestore" to back up your UFS file systems, substitute "vrestore" for "restore" in these instructions. NOTE: These instructions assume that you will be using the rewinding device name and then fast forwarding to the proper file mark for each restore. This is because it can sometimes be awkward to position to the proper proper tape mark using "restore" and "vrestore". It is possible to avoid this extra tape movement, but I find it easier to reposition the tape, especially when you need to use the interactive mode to determine the order of the file marks on the tape.

# newfs /dev/rrz0a (for root)

# newfs /dev/rrz0g (for /usr)
# mount /dev/rz0a /mnt

# cd /mnt

# mt rewind

# restore -xv
(The "v" option tells restore to echo the name of each  file
as it is restored)
# mount /dev/rz0g /mnt/usr

# cd /mnt/usr
(position tape at the next file mark, the /usr  backup)
# mt -f /dev/nrmt0 fsf 1 

# restore -xv
# disklabel -r rz0a > /tmp/label

(disk type is rz1cb as obtained from disk label output)
# disklabel -t ufs -r -R rz0a /tmp/label rz1cb


 

<top> <table of contents> <Digital Unix overview>

AdvFS Recovery

# mkfdmn -r /dev/rz0a root_domain
# mkfset root_domain root 
# mkfdmn /dev/rz0g usr_domain
# mkfset usr_domain usr
# mount -t advfs root_domain#root /mnt
# cd /mnt
# mt -f /dev/nrmt0 rewind
# vrestore -xv
(the "v" option tells vrestore to echo the name of  each
file as it is restored)
# mount -t adfvs usr_domain#usr /mnt/usr
# cd /mnt/usr
(Position tape to the next file mart, the /usr  backup)
# mt -f /dev/nrmt0 fsf 1 
# vrestore -xv
# disklabel -r rz0a > /tmp/label 
(disk type is rz1cb as obtained from disk label output) 
# disklabel -t advfs -r -R rz0a /tmp/label rz1cb

Different hardware issues:

If you are installing on a system with different disk numbering, you will need to modify the ADVFS file structures on the restored /etc file system.  This information is kept under /etc/fdmns, and is a directory tree of symbolic links that contain the mapping between file domains and actual hardware.   Remember, if you are renumbering scsi buses, use the device names that you will actually be using with your new real kernel not what the names are are while booted off of CD-ROM.  If you are changing the device targets for all ADVFS file systems, you will clear out the entire fdmns structure.  If you are only changing the boot disk targets, you only have to clear out those fdmns entries.

# cd /mnt/etc/fdmns
# cd root_domain
# rm *
# ln -s /dev/rz0a rz0a
# cd ../usr_domain
# ln -s /dev/rz0g rz0g
(repeat for other boot disk ADVFS file systems.)

If the system uses pre-allocated swap, controlled by the /sbin/swapdefault link, you will need to change the link. Remove /sbin/swapdefault which is a link to the LSM swap volume, and replace it with a link to the device file for the default swap volume.
# cd /mnt/sbin
# rm swapdefault
# ln -s /dev/rz0b swapdefault
 

<top> <table of contents> <Digital Unix overview>

LSM Cleanup:

This is tricky, and is not documented in any Digital documentation I have seen yet. The documentation instructs you to re-install the OS from scratch, and to configure in the LSM from scratch in the OS installation process. However, this other method has worked well for me.

You basically want to unconfigure LSM so that the system uses plain disk paritions rather than the extra layer of abstraction used by LSM. When you are done, the root disk will be bootable, but you will have to re-encapsulate and remirror the boot disk if you wish it to be an LSM volume again. Much of these tasks are duplicated in the "Recovering onto differnet hardware" section. If to perform these tasks now, you do not need to duplicate them in the next section.
 

# cd /mnt/etc/fdmns/root_domain  # rm rootvol  # ln -s /dev/rz0a rz0a
# cd ../usr_domain
# rm vol_rz0g
# ln -s /dev/rz0g rz0g

If the system uses pre-allocated swap, controlled by the /sbin/swapdefault link, you will need to change the link. Remove /sbin/swapdefault which is a link to the LSM swap volume, and replace it with a link to the device file for the default swap volume.

# cd /mnt/sbin
# rm swapdefault
# ln -s /dev/rz0b swapdefault
rm /mnt/etc/vol/volboot
lsmr:s:sysinit:/sbin/lsmbstartup -b /console >/dev/console 2>&1
lsm:23:wait:/sbin/lsmbstartup -n /console >/dev/console 2>&1
vol:23:wait:/sbin/vol-reconfig /console >/dev/console 2>&1
lsm:
lsm_rootdev_is_volume = 1
lsm_swapdev_is_volume = 1

Need to be changed... instead of = 1, set them to = 0.


 

<top> <table of contents> <Digital Unix overview>

Finishing Up:

Now that all the file systems have been restored and LSM has been disabled (if applicable) you are entering the home stretch, and if you are restoring onto the same hardware, you are just about done.

Before rebooting on your restored system image, you will may want to disable some of the processes that normally start up upon system boot up.  This will include things such as databases and web servers.  This will allow you to test out the restored system in a more controlled manner when it first boots up. This includes things such as the cron daemon. You will likely not want backups or other batch processes to start tying to kick off while you are still in recovery mode.

ASE TruCluster NOTE: If you are restoring an ASE TruCluster system, you will want to ensure that the ASE daemons do NOT start up initially just to be sure that the system does not try to take back any services before you are ready.

These services are usually started via the startup scripts in /sbin/init.d.  You will need to look at each of the /sbin/rc*.d directories and rename the appropriate "S*" scripts to something like "nostart.S*".

Finishing up on the same hardware:

If you are restoring onto your original (or identical) hardware, you can now boot up the system.   Booting it in single user mode may also help diagnose the health of the system in a more systematic and controlled manner than would booting it multi-user.  Halt the system and then issue the boot command at the boot / eeprom prompt.

The boot prompt command for single user boot and the OS command for mounting all file systems are:

# halt
(now at the boot prompt)
>> boot -fl s

(after system boots up, mount all file systems.)
# bcheckrc
 
Now you can go to the end of system restore section.

Finishing up on different hardware:

When booting up on new hardware, your restored kernel file will not work properly due to the changes in hardware configuration.  You will need to boot off of the "/genvmunix" generic kernel file, and then produce a new customized kernel file for your new hardware configuration.  Your restored system may also have device files to non-existant devices if you have changed your scsi bus numbering or number of disk drives on the system.

To clean up the device files, remove the old files, and use the /mnt/dev/MADEDEV script to create the disk and tape devices on the system.  The rest will be automatically created when the system boots up.  When you create the SCSI devices, remember to use the bus numbering that you will be using with your new kernel.  This can be different from what you see while booted from CD-ROM if you plan to renumber scsi buses in your kernel config file.  Manually recreating the disk and tape devices may be optional... You may be able to let the system recreate all of them for you.  Most disk drives are named "rz*" but some older devices  and hardware raid devices have a name of "re*".

# cd /mnt/dev
# rm rmt*
# rm nrmt*
# rm re*
# rm rre*
# rm rrz*
# rm rz*
# rm ty*

(create the device files for the disks, tape drives, and the CDROM drive.  Remember, the formula for device number is SCSIBUS*8 + TARGETID, and LUN letters are not used for LUN0,  and letters a=1 -> g=7)

(NOTE: You are still in the /mnt/dev directory)

# ./MAKEDEV rz<lun><disk devnumber>
(if you have "re" devices)
# ./MAKEDEV re<lun><disk devnumber>
# ./MAKEDEV tz<tape devnumber>
# ./MAKEDEV rz<cdrom devnumber>

If you are restoring the system at a disaster recovery site, you will probably want to modify the networking configuration of the system. You are on a different numbered network, so you will need to change the system's IP address, and may need to change it's netmask, add default routes, and change it's /etc/resolv.conf DNS or NIS client configuration. Most networking parameters are set in the file /etc/rc.config. Once this is complete, you are ready to halt the system and boot from the generic "genvmunix" kernel:

# halt 
(now at boot prompt) 
>> boot -fl s -fi genvmunix

After the system boots up, you will want to mount the remaining file systems, and build the new kernel file.  When you run "doconfig", it should automatically run the "sizer" command. This command will autosense the hardware installed on the system and produce a new custom kernel config file. If you have problems using this technique, you can try running the sizer command manually as described in Appendix D. But the automatic technique seems to work better.  You may want to back up the old kernel config file and old kernel prior to performing these steps.  Don't forget to make sure your root file system has enough room for the new and backed up kernel files.   Finally, move the new kernel into place, and reboot the system. The kernel config file is typically the system name, in all capital letters. In this example, the system name is "mysystem".

# bcheckrc
# cd /sys
# cp MYSYSTEM MYSYSTEM.bak

# doconfig
# mv /sys/MYSYSTEM/vmunix /vmunix

(You may want to run a "diff" between the existing kernel config file and the one produced by sizer, especially if you have added kernel tuning parameters to your previous kernel.  You will have to manually enter these parameters to the new file, and run "doconfig" again.


# reboot

Now you can go to the end of system restore section.
 

<top> <table of contents> <Digital Unix overview>

End of system restoration:

Now that your OS has been restored, you will want to test out the system and make sure that it is basically operating correctly.  This will include things such as:

If your system crash was due to the failure of an un-mirrored boot disk, now is a good time to build a cost justification for adding LSM or hardware based disk mirroring to your system.  If your system crash was due to total site disaster, you may be at a DR site, and next you will have to go back home and run through this whole operation again, only back in your own data center.  I hope you took good notes.

 

<top> <table of contents> <Digital Unix overview>


Appendicies - related information:

Appendix A - How to access AdvFS volumes when booted off of CD-ROM.

If you are booted off of CD-ROM and have just created new AdvFS file systems, you will be able to access them without a problem... The Kernel already knows about them. But if you are booting off of CD-ROM and want to access volumes that you had previously created, this is a different matter.

You need to run the "/sbin/advfs/advscan -r rz0" command. (replace rz0 with the disk you actually want to scan). This will scan the indicated disk for AdvFS file systems, and will configure them into the kernel. The domain names will be constructed based on the disk partition names, but the filesets will retain their original names.

You will then be able to mount the file systems normally.

NOTE: If the file systems that you are mounting are LSM mirrored volumes, this might corrupt the heck out of the data!!!!! You will only be mounting a single Plex, not both mirrors. This means that the plexes could become inconsistant from each other. I don't know how you handle this at this time. You may have to disable LSM if you do this, and then re-enable LSM after the system is up.

This may be handled by the "bcheckrc" program.

Appendix B - Disklabel command examples

Here is a summary of the different versions of "disklabel" you are likely to use during recovery. These examples assume the disk name is rz0

Appendix C - Disklabel man page

NAME  disklabel - Reads and writes disk pack label

SYNOPSIS

  /sbin/disklabel [-r] disk

  /sbin/disklabel -p disk [disk_type]

  /sbin/disklabel -w [-r] [-t ufs | advfs] disk disktype [packid] [primary-
  boot secondary-boot]

  /sbin/disklabel -wrn disk disktype [packid]

  /sbin/disklabel -e [-r] disk

  /sbin/disklabel -R [-r] [-t ufs | advfs] disk protofile [disktype |
  primary-boot secondary-boot]

  /sbin/disklabel [-N | -W] disk

  /sbin/disklabel -z disk

  /sbin/disklabel -s partition fstype

FLAGS

  -e    Edits an existing label.

  -n    Writes an initial label to a disk which will then be labeled, but
        non-bootable.

  -N    Disallows writing of the pack label area on the specified disk.  (See
        -W.)

  -p    Prints label parameters for the specified disk to stdout.

  -r    Reads or writes the label directly to or from the disk, rather than
        operating on the in-memory copy of the label.

  -R    Restores a disk label that was formatted in a prior operation and
        saved in an ASCII file.

  -s    Sets the file system type (fstype) field in the disk label.

  -t ufs | advfs
        Specifies which type of the local file system the boot blocks
        describe, UFS or AdvFS.

  -w    Writes a standard label on the designated drive.
  -W    Allows writing of the pack label area on the specified disk. (See
        -N.)

  -z    Zeros (clears) the disk label.


DESCRIPTION

  The disklabel command can be used to install, examine, or modify the label
  on a disk drive or pack. The disk label contains information about the
  disk, such as type, physical parameters, and partitioning.

  The disklabel command can be used to change the drive identification or the
  disk partitions on the drive, or to replace a damaged label or bootstrap.
  The disk label is located on one of the first sectors of each disk (usually
  block 0).  On machines that require a block-0 bootstrap, the label is
  inserted into the bootstrap program.

  The disk argument specifies the disk (for example, rz0 or /dev/rrz0a).  If
  you do not specify the disk partition, disklabel uses the first partition
  that has a zero offset. Typically, this is the a or c partition.

  The disktype argument specifies the type of disk.  The /etc/disktab file
  contains a list of disk types and their parameters and partitions.  If you
  want disks that are the same type to have different partition parameters,
  you must have separate /etc/disktab file entries describing each disk, or
  you must edit the disks' labels after installation with the -e flag.  If
  your disk type is not specified in the /etc/disktab file, disklabel uses
  the default partition information in the driver.

  There are two copies of a disk label, one located on the disk and one
  located in system memory. Because it is faster to access system memory than
  to perform I/O, when a system recognizes a disk, it copies the disk label
  into memory.

  The -r option causes the label to be read from or written to the disk
  directly, instead of reading the system's in-memory copy of the label.
  When writing, the in-memory copy is also updated if the parameters are
  valid.  The -r option must be used if there is no label already on the
  disk.  This option may allow a label to be installed on a disk without ker-
  nel support for a label, such as when labels are first installed on a sys-
  tem.

  The first form of the command is used to examine the label on the specified
  disk drive.  It displays all of the parameters associated with the drive
  and its partition layout.  If the disk has no label or if the partition
  types on the disk are incorrect, the kernel may have constructed or modi-
  fied the label.  If you specify the -r flag, the label from the raw disk is
  displayed instead of the in-memory label.

  The -p option prints the disklabel parameters from /etc/disktab for a
  specified disk to stdout.  The type of disk is obtained directly by query-
  ing the disk special file.  If there is no matching entry in /etc/disktab
  for the obtained type, disklabel uses the default partition information in
  the driver.  If the optional disktype parameter is specified, it takes pre-
  cedence over the disk special file, and the information will be obtained
  from /etc/disktab if a matching entry is found for the specified type.  If
  no matching entry is found, the default partition information from the
  driver will be used as described above.

  The second form of the command, with the -w flag, writes a standard label
  on the designated drive.  You must specify the disk and the disk type as
  described in the /etc/disktab file.  The optional packid argument specifies
  a pack identification string that contains up to 16 characters.  Use quotes
  around the packid argument if it contains blanks.  If you specify the -r
  flag with the -w flag, the disk sectors that contain the label and
  bootstrap are written directly; otherwise the existing label is updated in
  place without modifying the bootstrap.  In either case, the kernel's in-
  memory label is replaced.  You can specify alternate versions of the
  bootstrap files, using the primary-boot and secondary-boot arguments.  If
  an alternate bootstrap is not specified, the standard bootstrap is used.

  The bootstrap programs are located in /mdec.  The names of the bootstrap
  programs can be specified in the /etc/disktab file, but if they are not
  specified, the default names use either the basenameboot syntax for the
  primary (block 0) bootstrap or the bootbasename syntax for the secondary
  (blocks 1-15 for UFS and blocks 64-95 for AdvFS) bootstrap, where the
  basename is the type of disk, such as, rz or re.  For example, the names
  are /mdec/rzboot and /mdec/bootrz for a UFS rz-type disk.  If you specify
  the -t advfs option, the default names use either the basenameboot.advfs
  syntax for the primary bootstrap or the bootbasename.advfs syntax for the
  secondary bootstrap (blocks 64-95), for example, /mdec/rzboot.advfs and
  /mdec/bootrz.advfs.

  To write an initial label to a non-bootable disk, use the -n option with
  the -wr options. When using this form of the command, specify the disk and
  disktype. You can also specify the optional packid.

  You can edit an existing disk label, using the -e flag.  The label is read
  from the in-memory kernel copy, or directly from the disk if the -r flag is
  specified.  The label is formatted and then sent to an editor.  If no edi-
  tor is specified with the EDITOR environment variable, the vi editor is
  used.  If vi is not available, the ed editor is used.

  Note that if an unexpected error occurs during the ed editing session, the
  following message will appear:

       Warning, edit session exited abnormally!

  You should re-edit the disk label to ensure that you made the modifica-
  tions.

  When the editor terminates, the formatted label is reread and used to
  rewrite the disk label.

  If you specify the -R flag, disklabel restores a disk label that was previ-
  ously formatted and saved in an ASCII file.  The protofile argument speci-
  fies the prototype file that is used to create the label.  This file should
  be in the same format that is produced when reading or editing a label.
  Comments are indicated with number signs (#) and newline.  If you also
  specify the -r option, a block-0 bootstrap is installed on the machines
  that use that type of bootstrap; either the disk type or the names of the
  bootstrap files must be specified on such machines.
  The -N flag does not allow you to write to the disk pack label area.  The
  -W flag allows you to write to the disk pack label area.  The label sector
  is always write-protected when the drive is first opened; the write-enable
  flag set by -W persists only until all partitions on the drive are closed.

  Note that if you replace an existing label with a new label, the existing
  partition information will be copied to the new label if the new label's
  partition is marked unused.  This may cause disklabel to fail and can be
  avoided by first using the -z option to clear the disk label.

  You can use the -s option to change the file system type (fstype) in the
  disk label. Specify the partition whose type you are changing and the new
  fstype. If a partition no longer contains valid file system data, use the
  -s option to set the fstype to unused. Or, if the fstype is unused, but the
  partition does contain valid data, use the -s option to set a valid fstype.
  This prevents inadvertent loss of data, as applications like newfs, mkfdmn,
  voldisk, and swapon check the fstype field in the disk label for the parti-
  tion usage.

  You can set the fstype field to be any of the following:

  unused    Available for use.

  swap      Used as swap space.

  4.2BSD, ufs, or UFS
            Use by a UNIX file system.

  AdvFS     Used by an AdvFS file system.

  LSMnopriv Used by an LSM nopriv disk.

  LSMpriv   Used for an LSM private region.

  LSMpubl   Used for an LSM public region.

  LSMsimp   Used by an LSM simple disk.

  database  Used by a database.

  raw       Used for raw data.

NOTES

    +  The kernel device drivers do not allow the size of a disk partition to
       be decreased or the offset of a partition to be changed while it is
       open.  Some device drivers create a label containing only a single
       large partition if a disk is unlabeled; thus the label must be written
       to the a or c partition of the disk while it is open.  This sometimes
       requires the desired label to be set in two steps, the first one
       creating at least one other partition, and the second setting the
       label on the new partition while shrinking the a partition.

       The kernel does not allow file system information to be set unused for
       open partitions.  For example, if you want to set the a partition to
       unused, you must write the label using a different partition (such as
       the c partition).  For example:
            # disklabel -w /dev/rrz0c rz56
       If a file system exists for an open partition, the existing file sys-
       tem information is copied to the new label.  This preserves the exist-
       ing information without returning an error.

    +  When using LSM, if you try to recover a replaced mirror disk and the
       disk has been replaced with a new disk, disklabel fails with the fol-
       lowing error, when attempting to write the new label:
             disklabel: ioctl DIOCSDINFO: open partition would move or shrink

       Remove the disk from LSM before attempting to write the new disklabel:
            # voldisk rm rz8
            # disklabel -wr rz8 rz28

EXAMPLES

    +  The following example clears the existing label, writes a new label,
       and then displays the current label:
            # disklabel -z rz6
            # disklabel -rw rz6 rzw7s
            # disklabel -r rz6
            # /dev/rrz6a:
            type: SCSI
            disk: rzw7s
            label:
            flags:
            bytes/sector: 512
            sectors/track: 71
            tracks/cylinder: 15
            sectors/cylinder: 1065
            cylinders: 1900
            sectors/unit: 2023500
            rpm: 3600
            interleave: 1
            trackskew: 0
            cylinderskew: 0
            headswitch: 0           # milliseconds
            track-to-track seek: 0  # milliseconds
            drivedata: 0

            8 partitions:
        #        size   offset   fstype  [fsize bsize  cpg]
        a:   131072        0   unused    1024  8192   # (Cyl.    0 - 123*)
        b:   262144   131072   unused    1024  8192   # (Cyl.  123*- 369*)
        c:  2023500        0   unused    1024  8192   # (Cyl.    0 - 1899)
        d:   163840  1703936   unused    1024  8192   # (Cyl. 1599*- 1753*)
        e:    32768  1867776   unused    1024  8192   # (Cyl. 1753*- 1784*)
        f:   122956  1900544   unused    1024  8192   # (Cyl. 1784*- 1899*)
        g:  1310720   393216   unused    1024  8192   # (Cyl.  369*- 1599*)
        h:   319564  1703936   unused    1024  8192   # (Cyl. 1599*- 1899*)
       Note that the asterisks in the cpg column indicate that the beginning
       or ending cylinders do not fall exactly on a block boundary.

    +  The following example marks partition rz4c for use by a database:
            # disklabel -s rz4c database

    +  The following example marks partition rz4c as unused, which means it
       is available for use.

       If a file system exists for an open partition, the existing file sys-
       tem information is copied to the new label.  This preserves the exist-
       ing information without returning an error.

    +  When using LSM, if you try to recover a replaced mirror disk and the
       disk has been replaced with a new disk, disklabel fails with the fol-
       lowing error, when attempting to write the new label:
             disklabel: ioctl DIOCSDINFO: open partition would move or shrink

       Remove the disk from LSM before attempting to write the new disklabel:
            # voldisk rm rz8
            # disklabel -wr rz8 rz28

EXAMPLES

    +  The following example clears the existing label, writes a new label,
       and then displays the current label:
            # disklabel -z rz6
            # disklabel -rw rz6 rzw7s
            # disklabel -r rz6
            # /dev/rrz6a:
            type: SCSI
            disk: rzw7s
            label:
            flags:
            bytes/sector: 512
            sectors/track: 71
            tracks/cylinder: 15
            sectors/cylinder: 1065
            cylinders: 1900
            sectors/unit: 2023500
            rpm: 3600
            interleave: 1
            trackskew: 0
            cylinderskew: 0
            headswitch: 0           # milliseconds
            track-to-track seek: 0  # milliseconds
            drivedata: 0

            8 partitions:
      #        size   offset   fstype  [fsize bsize  cpg]
        a:   131072        0   unused    1024  8192   # (Cyl.    0 - 123*)
        b:   262144   131072   unused    1024  8192   # (Cyl.  123*- 369*)
        c:  2023500        0   unused    1024  8192   # (Cyl.    0 - 1899)
        d:   163840  1703936   unused    1024  8192   # (Cyl. 1599*- 1753*)
        e:    32768  1867776   unused    1024  8192   # (Cyl. 1753*- 1784*)
        f:   122956  1900544   unused    1024  8192   # (Cyl. 1784*- 1899*)
        g:  1310720   393216   unused    1024  8192   # (Cyl.  369*- 1599*)
        h:   319564  1703936   unused    1024  8192   # (Cyl. 1599*- 1899*)
       Note that the asterisks in the cpg column indicate that the beginning
       or ending cylinders do not fall exactly on a block boundary.

    +  The following example marks partition rz4c for use by a database:
            # disklabel -s rz4c database

    +  The following example marks partition rz4c as unused, which means it
       is available for use.
           8 partitions:
      #        size   offset   fstype  [fsize bsize  cpg]
        a:   131072        0   unused    1024  8192   # (Cyl.    0 - 123*)
        b:   262144   131072   unused    1024  8192   # (Cyl.  123*- 369*)
        c:  2023500        0   unused    1024  8192   # (Cyl.    0 - 1899)
        d:   163840  1703936   unused    1024  8192   # (Cyl. 1599*- 1753*)
        e:    32768  1867776   unused    1024  8192   # (Cyl. 1753*- 1784*)
        f:   122956  1900544   unused    1024  8192   # (Cyl. 1784*- 1899*)
        g:  1310720   393216   unused    1024  8192   # (Cyl.  369*- 1599*)
        h:   319564  1703936   unused    1024  8192   # (Cyl. 1599*- 1899*)
       Note that the asterisks in the cpg column indicate that the beginning
       or ending cylinders do not fall exactly on a block boundary.

    +  The following example marks partition rz4c for use by a database:
            # disklabel -s rz4c database

    +  The following example marks partition rz4c as unused, which means it
       is available for use.
            # disklabel -s rz4c unused

FILES

  /etc/disktab Contains information about disks and drives.

  /mdec/xxboot Primary bootstrap programs.

  /mdec/bootxx Secondary bootstrap programs.

RELATED INFORMATION

  Files: disklabel(4), disktab(4), rz(7), ra(7)

  Functions: check_usage(3), set_usage(3)


Appendix D - Alternate kernel build instructions

There seem to be two ways to build the kernel for the system in order to recognize new hardware. The method used earlier in the doucment seems to be the best. But if you need more manual control over the process, you may want to try the following procedures:

# halt 
(now at boot prompt) 
>> boot -fl s -fi genvmunix

After the system boots up, you will want to mount the remaining file systems, and build the new kernel file. Then the "sizer" command is used to produce a new custom kernel config file, and the "doconfig" command is used to compile the new kernel. You may want to back up the old kernel config file and old kernel prior to performing these steps. Don't forget to make sure your root file system has enough room for the new and backed up kernel files. Finally, move the new kernel into place, and reboot the system.

# bcheckrc 
# sizer -n NEWCFG
# cp /tmp/NEWCFG /sys/conf 

(You may want to run a "diff" between the existing kernel config file and the one produced by sizer, especially if you have added kernel tuning parameters to your previous kernel.  You will have to manually enter these parameters to the new file.)

# doconfig -c NEWCFG
# mv /sys/NEWCFG/vmunix /vmunix
# reboot

<top> <table of contents> <Digital Unix overview>