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.
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> |
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> |
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> |
# 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
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> |
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> |
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*".
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.
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> |
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> |
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.
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
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)
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> |