Here are my notes on how to remove and replace a dead mirrored drive on HP-UX 11i v3:

Remove bad mirrored boot disk HP-UX:

Check for stale LEs:

lvdisplay -v -k /dev/vg00/lvol# (1-7 is normal, however your system might have more) (to get key for the next command)

Next we need to remove the bad drive from the LVM, so let’s reduce the lvols (the last integer is the key from the last lvdisplay command):

lvreduce -m 0 -A n -k /dev/vg00/lvol1 0 lvreduce -m 0 -A n -k /dev/vg00/lvol2 0 lvreduce -m 0 -A n -k /dev/vg00/lvol3 0 lvreduce -m 0 -A n -k /dev/vg00/lvol4 0 lvreduce -m 0 -A n -k /dev/vg00/lvol5 0 lvreduce -m 0 -A n -k /dev/vg00/lvol6 0 lvreduce -m 0 -A n -k /dev/vg00/lvol7 0

Now that we’ve reduced the mirror, let’s remove partition 2 from the volgroup:

vgreduce /dev/vg00 /dev/disk/disk62_p2

If we can’t reduce because it’s critically failed, then we need to do this:

vgreduce –f /dev/vg00 /dev/disk/disk62_p2 vgscan –f /dev/vg00

Then confirm:

vgdisplay -v vg00

Here’s an example of a DEAD drive from ioscan:

disk 62 64000/0xfa00/0xd esdisk NO_HW DEVICE offline HP 36.4GST336753LC 2/0/0/2/0.0x6.0x0 /dev/disk/disk62 /dev/disk/disk62_p2 /dev/rdisk/disk62 /dev/rdisk/disk62_p2 /dev/disk/disk62_p1 /dev/disk/disk62_p3 /dev/rdisk/disk62_p1 /dev/rdisk/disk62_p3

Example of REPLACED drive with the old DEAD DSF – Map DSF then Re-add to VG:

STEP1: In order to see the new drive, you need to do this first (AFTER NEW DRIVE IS INSERTED): scsimgr replace_wwid –D /dev/rdisk/disk62

... disk 62 64000/0xfa00/0xd esdisk NO_HW DEVICE offline HP 36.4GST336753LC /dev/disk/disk62 /dev/disk/disk62_p2 /dev/rdisk/disk62 /dev/rdisk/disk62_p2 /dev/disk/disk62_p1 /dev/disk/disk62_p3 /dev/rdisk/disk62_p1 /dev/rdisk/disk62_p3 disk 219 64000/0xfa00/0x20 esdisk CLAIMED DEVICE online HP 36.4GST336753LC 2/0/0/2/0.0x6.0x0 /dev/disk/disk219 /dev/rdisk/disk219 ...

STEP2: Formart disk219

echo "3" > /tmp/partitionfile echo "EFI 500MB" >> /tmp/partitionfile echo "HPUX 100%" >> /tmp/partitionfile echo "HPSP 400MB" >> /tmp/partitionfile idisk -wf /tmp/partitionfile /dev/rdisk/disk219 ioscan -fnNC disk insf -e -C disk

STEP3: Then you can map the new DSF to the old one:

io_redirect_dsf -d /dev/disk/disk62 -n /dev/disk/disk219

STEP4: Make Bootable and fix EFI partitions:

mkboot -e -l /dev/rdisk/disk62 efi_ls -d /dev/rdisk/disk62_p1 lifls -l /dev/rdisk/disk62_p2 mkboot -a "boot vmunix -lq" /dev/disk/disk62 efi_cp -d /dev/rdisk/disk62_p1 -u /EFI/HPUX/AUTO /tmp/x; cat /tmp/x;rm /tmp/x

STEP5: Create PV, Extend VG, and Extend LVs:

pvcreate -f -B /dev/rdisk/disk62_p2 vgextend /dev/vg00 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol1 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol2 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol3 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol4 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol5 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol6 /dev/disk/disk62_p2 lvextend -m 1 /dev/vg00/lvol7 /dev/disk/disk62_p2 lvlnboot -r /dev/vg00/lvol3 lvlnboot -b /dev/vg00/lvol1 lvlnboot -s /dev/vg00/lvol2 lvlnboot -d /dev/vg00/lvol2 lvlnboot -R lvlnboot -v

STEP6: Verify VG and boot paths

vgdisplay -v vg00 setboot -v

If the mirrored disk fails to boot from EFI, boot off the alternate working one, and re-execute setboot -v with the device path (even though it might already be set, set it again since the wwid change).

Extend an LVM volume in Linux

April 24th, 2012 | Posted by spritian in Linux | LVM - (3 Comments)

One of my clients needed to expand their DB since it was at 96% utilization. Thankfully, it was already in a volume group. Here are the steps I took to add a new LUN to the VG and expand it.

First, use fdisk to find the new LUN that doesn’t have a partition table and then use fdisk to create a new partition on it as Linux LVM:

[root@redhat ~]# fdisk -l [trimmed] Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdf doesn't contain a valid partition table [root@redhat ~]# fdisk /dev/sdf Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 52216. 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 LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): p Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-52216, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-52216, default 52216): Using default value 52216 Command (m for help): t Selected partition 1 Hex code (type L to list codes): 8e Changed system type of partition 1 to 8e (Linux LVM) Command (m for help): p Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdf1 1 52216 419424988+ 8e Linux LVM Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. [root@redhat ~]# fdisk -l [trimmed] Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdf1 1 52216 419424988+ 8e Linux LVM

Now that the partition table is setup correctly, let’s create a new LVM on the drive, and extend our existing volume group using the new physical LUN.

[root@redhat ~]# pvcreate /dev/sdf1 Physical volume "/dev/sdf1" successfully created [root@redhat ~]# vgextend ora_vg1 /dev/sdf1 Volume group "ora_vg1" successfully extended

Here you can see our physical extents has increased due to the addition of the new physical drive to the volume group:

[root@redhat ~]# vgdisplay --- Volume group --- VG Name ora_vg1 System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 9 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 5 Act PV 5 VG Size 1.18 TB PE Size 32.00 MB Total PE 38555 Alloc PE / Size 25728 / 804.00 GB Free PE / Size 12827 / 400.84 GB VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY [root@redhat ~]# lvdisplay --- Logical volume --- LV Name /dev/ora_vg1/lvol_d03 VG Name ora_vg1 LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar LV Write Access read/write LV Status available # open 1 LV Size 749.00 GB Current LE 23968 Segments 4 Allocation inherit Read ahead sectors 0 Block device 253:4

I only wanted to allocated ~75% of the new LUN to lvol_d03, so I took the Current LE 23968 from the previous lvdisplay. I prefer to actually distribute via Extents, rather than the easy way of +G, etc. So I added 9827 extents (from a total of 12827 free) to the existing 23968, totaling 33795:

[root@redhat ~]# lvextend -l 33795 /dev/ora_vg1/lvol_d03 Extending logical volume lvol_d03 to 1.03 TB Logical volume lvol_d03 successfully resized [root@redhat ~]# lvdisplay --- Logical volume --- LV Name /dev/ora_vg1/lvol_d03 VG Name ora_vg1 LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar LV Write Access read/write LV Status available # open 1 LV Size 1.03 TB Current LE 33795 Segments 5 Allocation inherit Read ahead sectors 0 Block device 253:4 [root@redhat ~]# vgdisplay --- Volume group --- VG Name ora_vg1 System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 5 Act PV 5 VG Size 1.18 TB PE Size 32.00 MB Total PE 38555 Alloc PE / Size 35555 / 1.09 TB Free PE / Size 3000 / 93.75 GB VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY

Above you can see we still have 3000 extents available. I tend to leave a little as wiggle room so if we ever get into a position of running out of space we aren’t screwed. 🙂

Now that LVM has extended the volume group, we need to have the filesystem recognize it:
(This box didn’t have ext3online (older kernel; 2.6.9), so just decided to do it the old school way…)

[root@redhat ~]# resize2fs /dev/mapper/ora_vg1-lvol_d03 resize2fs 1.35 (28-Feb-2004) /dev/mapper/ora_vg1-lvol_d03 is mounted; can't resize a mounted filesystem! [root@redhat /]# umount /prod/d03 [root@redhat /]# e2fsck -f /dev/mapper/ora_vg1-lvol_d03 e2fsck 1.35 (28-Feb-2004) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/mapper/ora_vg1-lvol_d03: 128/98172928 files (14.8% non-contiguous), 195569167/196345856 blocks [root@redhat /]# resize2fs /dev/mapper/ora_vg1-lvol_d03 resize2fs 1.35 (28-Feb-2004) Resizing the filesystem on /dev/mapper/ora_vg1-lvol_d03 to 276848640 (4k) blocks. The filesystem on /dev/mapper/ora_vg1-lvol_d03 is now 276848640 blocks long.

That’s it, now the moment of truth…

[root@redhat /]# mount -a [root@redhat /]# df -h [trimmed] /dev/mapper/ora_vg1-lvol_d03 1.1T 735G 306G 71% /prod/d03

Woot, all good! (749GB to 1.1TB)