 |
» |
|
|
|
Booting When LVM Data Structures Are Lost | |
When critical LVM data structures have been lost, you will
need to use the recovery portion of the Support Media included in
the HP-UX product kit to restore the corrupted disk image from your
backup tape. For more information, see the Support Media
User's Manual. After you have made the LVM disk minimally bootable, the system
can be booted in maintenance mode using the -lm
option of the hpux
command at the ISL>
prompt. This causes the system to boot to single-user state without
primary swap, dump, or LVM to access the root file system. See "Booting
in Maintenance Mode" in Chapter 2 for more information. (The information
is identical for Series 700 or 800 systems.) When a Volume Group Will Not
Activate | |
Normally, volume groups are automatically activated during
system startup. Unless you intentionally deactivate a volume group
using vgchange,
you will probably not need to reactivate a volume group. However, LVM does require that a "quorum" of disks in a volume
group be available. During normal system operation, LVM needs a
quorum of more than half of the disks in a volume group for activation.
If, during run time, a disk fails and causes quorum to be lost,
LVM alerts you with a message to the console, but keeps the volume
group active. When booting the system, LVM also will require a quorum of
one more than half of the disks in the root volume group. This means,
for example, that LVM cannot activate a two-disk root volume group
with one of the disks offline. As a result, if this happens, you
will have a problem booting. Another possible problem pertaining to activation of a volume
group is a missing or corrupted /etc/lvmtab
file. You can use the vgscan(1M) command
to re-create the /etc/lvmtab
file. Quorum Problems with a Non-Root Volume Group If you attempt to activate a non-root volume group when not
enough disks are present to establish a quorum, you will see error
messages similar to those in this example: vgchange: Warning: Couldn't attach to the volume group
physical volume "/dev/dsk/c1t0d2":
The path of the physical volume refers to a device that does not
exist, or is not configured into the kernel. |
vgchange: Couldn't activate volume group "/dev/vg01":
Either no physical volumes are attached or no valid VGDAs were found
on the physical volumes. |
If a non-root volume group does not get activated because
of a failure to meet quorum, try the following: Check the power and data connections
of all the disks that are part of the volume group that you cannot
activate. Return all disks (or, at least enough to make a quorum)
to service. Then, use the vgchange
command to try to activate the volume group again. If there is no other way to make a quorum available,
the -q option
to the vgchange
command will override the quorum check. EXAMPLE: vgchange -a y -q n /dev/vg01 |
You should attempt to return the disabled disks to the volume
group as soon as possible. When you return a disk to service that
was not online when you originally activated the volume group, use
the activation command again to attach the now accessible disks
to the volume group. EXAMPLE:
Quorum Problems with Your Root Volume Group Your root volume group might also have a quorum problem. This
might occur if you have physically removed a disk from your system
because you no longer intended to use it with the system, but did
not remove the physical volume from the volume group using vgreduce.
Although you should never remove an LVM disk
from a system without first removing it from its volume group, you
can probably recover from this situation by booting your system
with the quorum override option, hpux -lq. Problems After Reducing the Size
of a Logical Volume | |
When a file system is first created within a logical volume
as described in Chapter 4, it is made as large as the logical volume
will permit. If you extend the logical volume without
extending its file system, you can subsequently safely reduce the
logical volume's size as long as it remains as big as its file system.
(Use bdf(1) to determine the size of your
file system.) Once you use the extendfs
command to expand the file system, you can no longer safely reduce
the size of the associated logical volume. (See "Extending the Size
of a File System Within a Logical Volume" in Chapter 4 for more
information.)
If you reduce the size of a logical volume containing a file
system to a size smaller than that of a file system within it using
the lvreduce
command without subsequently creating a new smaller file system,
you may crash your system. (See "Replacing an Existing File System
with a Smaller One" in Chapter 4 for more information.) If this
occurs: Reboot your system in single-user state. If you have already have a good current backup of
the data in the now corrupt file system, skip this step. Only if you do not have such backup data
and if that data is critical, you may want
to try to recover whatever part of the data
that may remain intact by attempting to back up the files on that
file system in your usual way. Immediately unmount the corrupted file system, if
it is mounted. You can now use the logical volume for swap space
or raw data storage, or use SAM or the newfs
command to create a new file system in the
logical volume. (See Chapter 4.) This new file system will now match
the current reduced size of the logical volume. If you have created a new file system on the logical
volume, you can now do one of the following: If you have a good prior backup (NOT
the backup from step 2), restore its contents. Since the new file
system in the smaller logical volume will be smaller than the original
file system, you may not have enough space to restore all your original
files. Use the new file system for creating and storing
a new set of files (not for trying to restore the original files). If you do not have a good prior backup, attempt
to restore as many files as possible from any backup you made in
step 2. Again, there is no guarantee that complete data will be
recoverable from this backup.
No Response or Program Output from an Inaccessible
Disk | |
You might occasionally see long periods of apparent inactivity
by programs that are accessing disks. Such programs may be "hung",
waiting for access to a currently inaccessible disk. Messages indicating
the disk is offline will also appear on your system console. If the logical volume is mirrored onto another disk, the hang
will only last until the disk driver returns (about a minute or
perhaps a little longer). LVM then marks the disk as offline and
continues the operation on any remaining mirror disk. LVM will only
write to or access the mirror copy until the offline disk is returned
to service. See Chapter 7 for more information on mirroring. If the logical volume is not mirrored, or if the mirror copies
of the logical volume are also not available, the program will remain
hung until a disk becomes accessible. Therefore, if your program
hangs, you should check for problems with your disk drives and,
if necessary, restore them to service as soon as possible. Troubleshooting an Existing SDS Disk | |
This section applies only if you have the Software Disk Striping
(SDS) capability on Series 700 systems. SDS disks are defined under
"Disk Management Prior to 10.0 HP-UX" at the beginning of this chapter. Using SDS to create new disk arrays is not supported beginning
at 10.0, nor is creating SDS single disks. If, however, an existing
SDS single disk needs replacement due to disk failure, including
head crashes, a different disk must be substituted and you must
use pvcreate
and vgcreate
to convert to logical volumes prior to restoring the files using
frecover. If the LABEL file from the migrated SDS single disk is inadvertently
removed from the LIF area, you will likewise need to replace the
disk by converting to logical volumes prior to restoring your data
from backup. |
Printable version
