|
|
|
|
|
To upgrade a Veritas Storage Foundation product on a standalone system
The root disk is under VxVM control if /dev/vx/dsk/bootdg/rootvol is listed as being mounted as the root (/) file system. If so, unmirror and unencapsulate the root disk as described in the following steps:
vxplex command to remove all the plexes of the volumes rootvol, swapvol, usr, var, opt and home that are on disks other than the root disk.
For example, the following command removes the plexes mirrootvol-01, and mirswapvol-01 that are configured on a disk other than the root disk:
# vxplex -o rm dis mirrootvol-01 mirswapvol-01
Note
Do not remove the plexes on the root disk that correspond to the original disk partitions.
rootdg disk group in addition to the root disk for vxunroot to succeed.
Following the removal of encapsulation, the system is rebooted from the unencapsulated root disk.
If your system is running VxVM 4.1 MP2, the following remnants of encapsulation will still be present:
If you are upgrading from 4.1 MP2, also perform step c through step g to correct these entries. Otherwise, proceed to step 4.
fdisk command on the root disk, as shown in this example:
Disk /dev/sda: 36.3 GB, 36398825472 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 13 104391 83 Linux
/dev/sda2 14 2001 15968610 83 Linux
/dev/sda3 1 4425 35543781 7e Unknown
/dev/sda4 2002 4425 19470780 5 Extended
/dev/sda5 2002 3001 8032468+ 83 Linux
/dev/sda6 3002 3003 16033+ 82 Linux swap
/dev/sda7 4425 4425 1024 7f Unknown
Partitions /dev/sda3 and /dev/sda7 with identifiers 7f and 7e correspond to the private and public regions respectively.
fdisk command again to remove the private and public partitions, /dev/sda3 and /dev/sda7.
The number of cylinders for this disk is set to 4425.
There is nothing wrong with that, but this is larger than
1024,and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with
error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
/etc/fstab file, and ensure that the entries for the root file system (/) and for other file systems on the root disk correspond to the correct disk partitions. If they do not, make any necessary changes to allow the system to boot correctly. For the example layout, no update is necessary. However, if the VxVM private region had been /dev/sda6, and other logical partitions followed it in the listing, the numbers of these partitions would decrease by 1. For example, /dev/sda7 would become/dev/sda6 , /dev/sda8 would become /dev/sda7, and so on.
Alternatively, you can copy /etc/fstab.b4vxvm back to /etc/fstab if you are certain that the entries are still valid.
/boot/grub/menu.lst file.
Remove all entries between and including the vxvm_root_default_START and vxvm_root_default_END comment markers, as shown in this example:
#vxvm_root_default_START ( do not remove)
# Default menu entry number has been set to vxvm_root.
# - the vxvm_root default entry number is: 3
# - the original default entry number is: 0
# - the selected default entry number is: 0
Remove all entries between and including the vxvm_root_START and vxvm_root_END comment markers, as shown in this example:
#vxvm_root_START ( do not remove)
kernel /vmlinuz root=/dev/sda2 vga=0x314 console=tty0 \
console=ttyS0 selinux=0 resume=/dev/sda6 elevator=cfq \
showopts initrd /VxVM_initrd.img
#vxvm_root_END ( do not remove)
Change to the original boot kernel that was used before the root disk was encapsulated by uncommenting the line that starts #default, as shown in this example:
color white/blue black/light-gray
color white/blue black/light-gray
Save the changes to the /boot/grub/menu.lst file.
Alternatively, you can copy /boot/grub/menu.lst.b4vxvm back to /boot/grub/menu.lst if you are certain that the entries are still valid.
Remove all entries between and including the vxvm_rootgeom_START and vxvm_rootgeom_END comment markers, as shown in this example:
#vxvm_rootgeom_START ( do not remove )
#NOTE: Only vxvm_root entry will be able to boot the
# system, while your root disk is under Volume Manager.
# Also, running -R/lock/fallback options of LILO may
# render your system unbootable.
disk=/dev/vx/dsk/bootdg/rootvol
partition=/dev/vx/dsk/bootdg/bootvol
#vxvm_rootgeom_END ( do not remove )
Remove all entries between and including the vxvm_root_START and vxvm_root_END comment markers, as shown in this example:
#vxvm_root_START ( do not remove)
append="root=/dev/sda2 vga=0x314 console=tty0 \
console=ttyS0 selinux=0 resume=/dev/sda6 elevator=cfq \
#vxvm_root_END ( do not remove)
Change to the argument to the default= attribute from vxvm_root to Linux, as shown in this example:
Save the changes to the /etc/lilo.conf file.
Alternatively, you can copy /etc/lilo.conf.b4vxvm back to /etc/lilo.conf if you are certain that the entries are still valid.
Run the following command after updating the /etc/lilo.conf file:
# echo "8192B.p S" | fsdb -t vxfs filesystem | grep clean
flags 0 mod 0 clean clean_value
A clean_value value of 0x5a indicates the file system is clean, 0x3c incidates the file system is dirty, and 0x69 indicates the file system is dusty. A dusty file system has pending extended operations.
# mount -t vxfs filesystem mountpoint
This should complete any extended operations that were outstanding on the file system and unmount the file system cleanly.
There may be a pending large fileset clone removal extended operation if the umount command fails with the following error:
You know for certain that an extended operation is pending if the following message is generated on the console:
Storage Checkpoint asynchronous operation on file_system
file system still in progress.
To verify that no volumes remain open, use the following command:
/etc/fstab file. You will need to recreate these entries in the /etc/fstab file on the freshly installed system.
Caution
This is likely to destroy any existing data on any disks that are touched by the installation procedure. During installation, do not reconfigure any disks other than the root disk or those disks that were previously in the rootdg disk group. To ensure the integrity of your data, it is recommended that you back it up before starting the upgrade.
installer script as described in Installing the Veritas Storage Foundation software.
/etc/fstab file that you recorded in step 9.
There are several optional configuration steps that you may want to perform:
vxlicinst command to add it to your system.