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)