News | About | Get Frugalware | Packages | Documentation | Discussion Forums | Bug Tracker | Wiki | Community | Development

Aix001

From FrugalWiki

Jump to: navigation, search

Contents

Updating AIX with cloned rootvg as a fallback option

@Frugalware Project members and users: Sorry for the inconvenience, I know this is off-topic here. I will remove the page soon.

1.) Know what you will do

WRITE DOWN and LOG EVERYTHING!! USE THE screen UTILITY!!

  • remove a disk from the rootvg (effectively destroying its content)
  • clone the content of remaining disk to the freed disk
  • reboot to the newly cloned disk
  • do the upgrade on this side
  • after you tested all functions in production, you mirror the VG again (overwriting the old disk)
  • in case of a failure, you reboot to the old system.

2.) Check current volume group setup

List the disks in your 'system VG', you will touch only these

lsvg -p rootvg 
lspv -l hdiskX
lspv -l hdiskY

You should see more or less equal distribution of PPs ('blocks')

If there are LVs only on one of the disks, it can mean several things.
- They can be removed if you can mirror them to the other (if there is enough free space) with 'mklvcopy -k LVname 2 hdiskY' - YOU CAN MOVE CONTENT ONLY BETWEEN THE ROOTVG DISKS!
- They can be removed if the LV type is sysdump, but you MUST recreate them later.
- They cannot be removed if some of them extends on both disks and the free place doesn't allow for complete removal from one of the disks.

3.) Action - Unmirror the VG

3a.) Remove the system dump devices from the target disk

List current settings:

sysdumpdev -l

Remove any dumpLVs sitting in the target disk:
For primary, use -p, for secondary, use -s.

sysdumpdev -P [-p|-s] /dev/sysdumpnull
rmlv $your_dumplv

YOU MUST CONFIGURE SYSTEM DUMP AGAIN LATER!

3b.) Now if you find that one of the disks can be unmirrored, unmirror it!

unmirrorvg rootvg hdiskY

Check:

lspv -l hdiskY

You should receive no output.
If there is something remaining, you must migrate it to the other disk.

4.) Remove the free disk from the rootvg

reducevg rootvg hdiskY

If you issue an 'lspv', you will find that hdiskY does not belong to any VG now.

5.) Clone the existing system disk to the free one

alt_disk_install -C hdiskY

You will see a lot of output. basically, it creates a similar LVM structure on the other disk, generates a listing of all files found on the current disk, then copies them one by one with the 'backup' and 'restore' commands.
There is a log for this operation under /var/adm/ras/alt_*
When finished, the boot list will be set to the cloned disk. The operation typically takes 1-2 hours when there is a moderate system load. It is not advised to run this command while there is a significant I/O load (for example, excessive paging) in the rootvg.

Check:

bootlist -n mormal -o

It should list the new disk.

6.) Reboot to the cloned disk

reboot and see if the stuff is working:

shutdown -Fr # no, NOT 'reboot' !!

7.) Do the upgrade

mount -v cdrfs -o ro /dev/cd0 /mnt
cd /mnt/path/to/bffs
smitty update_all
# preview first; check 'Accept license agreements', Commit: No

8.) Decide if the system can be kept after the upgrade

...

9.) Mirror the rootvg again

...

Personal tools
Namespaces
Variants
Actions