bsd.m3th.org
Yet another *nix admin blog

Although it is not a usual task for replacing/upgrading notebook internal hdd, nevertheless, I have performed one lately due to a failing hdd. smartctl reported hdd read failure and I have decided to make an early replacement. However, I still need to duplicate the hdd for recent data that has not been backup.

Cloning the hdd seems not a good option as it takes longer time and might fail to completely replicate the data due to hdd read failure. So I reinstalled OpenSUSE on the new hdd and restore relevant data on partition.

Default lvm volume group naming convention from OpenSUSE installer is somehow same as previous volume group. This will create problem when accessing data on failing hdd as I need to mount partition on lvm volume group which is same as running system. You should change the volume group name to something else other than “system” during the installation. Guess I didn’t paid too much attention during the installation and now I have 2 “system” volume groups. How should I mount the volume on failing hdd then?

Actually it is just an easy task of renaming volume group name.

1) Discover the UUID of the volume with dd by dumping the disk header.

dd if=/dev/sdb2 bs=512 count=255 skip=1 of=/tmp/sdb2.txt


Checking the output for disk UUID.

cat /tmp/sdb2.txt


You will find some thing like this.

system {
id = "8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v"
seqno = 6
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "dAe8PS-ThIN-Piez-pmqE-8hUv-vdGM-dyvtSO"
device = "/dev/sda2"

status = ["ALLOCATABLE"]
flags = []
dev_size = 487845855
pe_start = 384
pe_count = 59551
}
}

logical_volumes {

home {
id = "hQH10J-MouP-sNok-VNJN-53As-BYsw-b5cqS3"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 50847

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0
]
}
}

root {
id = "nde2YD-6rgk-Ufm7-bLf7-ERTc-bHdO-kg7fwF"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 7680

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 51359
]
}
}

swap {
id = "KXGiD4-qFSH-smun-P4wS-TH14-xxfY-lWYlq8"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 2

segment1 {
start_extent = 0
extent_count = 512

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 59039
]
}
segment2 {
start_extent = 512
extent_count = 512

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 50847
]
}
}
}
}

The UUID of the volume group “system” is “8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v”

2) Renaming the volume group
vgrename 8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v oldsystem

3) Activate the renamed volume group

# vgchange oldsystem -a y


Now you should have your vg ready. Verify it with

# pvscan


Output

  PV /dev/sdb2   VG oldsystem      lvm2 [232.62 GiB / 0    free]
  PV /dev/sda2   VG system   lvm2 [297.93 GiB / 23.93 GiB free]
  Total: 2 [530.55 GiB] / in use: 2 [530.55 GiB] / in no VG: 0 [0   ]

Check the volume

# lvscan


  ACTIVE            '/dev/oldsystem/home' [198.62 GiB] inherit
  ACTIVE            '/dev/oldsystem/root' [30.00 GiB] inherit
  ACTIVE            '/dev/oldsystem/swap' [4.00 GiB] inherit
  ACTIVE            '/dev/system/home' [250.00 GiB] inherit
  ACTIVE            '/dev/system/root' [20.00 GiB] inherit
  ACTIVE            '/dev/system/swap' [4.00 GiB] inherit

That’s it. You can now mount and dump/restore the failing hdd.