1

Reason: /boot filesystem corrupted: Both bootable hard drive cables were disconnected with motherboard by accident when it was powered on, which caused the HDDs /boot filesystem crashed. CentOS 7 Bootable 2 x 320GB entire hard drives were mirrored by LVM2 (/dev/mapper/cl-root, /dev/mapper-cl-home and swap) during the installation.

I boot up with CD-ROM, tried to repair the corrupted root partition superblock without success. Now I put the drive connected with SATA->USB connect to another CentOS 7 server's USB port, showing as following:

[root@localhost ~]# fdisk -l
.....  (**ignore the current server internal drivers info here**)
--- below is the external USB SATA 320GB corrupted /boot drive -----
......
Disk /dev/sdg: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disk label type: dos
Disk identifier: 0xe9e67578
   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1   *        2048     2099199     1048576   83  Linux
/dev/sdg2       606116385   625137344     9510480    7  HPFS/NTFS/exFAT
/dev/sdg3         2099200   606115839   302008320   8e  Linux LVM

My main purpose is to recover the HOME directory data from the crashed boot disk. I am looking for your help on one of the followings which can achieve this goal:

  1. copy data out of the crashed hard drive.
  2. repair the superblock to boot up as previously (in order to keep this question as short as possible, if you consider this is easier than 1, please let me know, so I have a longer troubleshooting code to paste here);

Below is the detail information for what I did on 1):

  1. Copy data out of the crashed hard drive:
[root@localhost ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   2.7T  0 disk 
......(ignore the internal disk, below is the USB HDD)....

sdg           8:96   0 298.1G  0 disk 
├─sdg1        8:97   0     1G  0 part 
├─sdg2        8:98   0   9.1G  0 part
└─sdg3        8:99   0   288G  0 part 
sr0          11:0    1   4.1G  0 rom  

I am mounting all of the 3 slice onto the mount points: but the /dev/sdg3 failed with the following error <<-- this is my key problem: how can I mount this slice to see the HOME data? (it's obviously the data is not on sdg1 and sdg2).

[root@localhost ~]# mount /dev/sdg1 /media/1 
[root@localhost ~]# mount /dev/sdg2 /media/2
[root@localhost ~]# mount /dev/sdg3 /media/3
mount: unknown filesystem type 'LVM2_member'

[root@localhost ~]# df -k
Filesystem           1K-blocks      Used  Available Use% Mounted on
......
/dev/sdg2              9510476   8211864    1298612  87% /media/2
/dev/sdg1              1038336    300072     738264  29% /media/1

I tried to use testdisk to dump out data from sdg3, with output file image.dd. however, at the end I found that this image.dd file is stilled wrapped with LVM2_member:

[root@localhost home-gwu-old]# ls -l
total 302008328
-rw-r--r--. 1 root root 309256519680 Jan  5 19:34 image.dd

[root@localhost]# mount -o loop image.dd /media/3
mount: unknown filesystem type 'LVM2_member

Any your help would be greatly appreciated! gordon

3
  • It's all about using LVM. Here it's not a simple LVM since it's also in RAID1 (it might also be the litteral mirror mode, which is distinct from RAID1). Also, there are chances that the rescue system, an other CentOS probably similarly installed uses an LVM VG with the same name cl, creating conflicts. All this adds complexity and makes an answer more difficult (for me anyway). You should familiarize with LVM.
    – A.B
    Jul 2, 2020 at 16:44
  • It seems that /dev/sdg3 is an LVM physical volume. It also seems that it is not recognized as such. What is the output of lvs? Jul 3, 2020 at 2:13
  • thanks a lot for all of your helps here! the lvs output looks like this: LV=home|root|swap; VG=cl|cl|cl; LSize=...... I am not able to find out the LV name anywhere - otherwise I'll mount the LVM with it's name to /media/3 to copy the data out. can I ask that should I turn my direction to fix the currupted /boot/Grub2 and rebuilt the LVM to solve this issue? thanks again! gordon
    – Gordon
    Jul 3, 2020 at 2:20

1 Answer 1

0

Normally a LVM-capable Linux system might automatically detect and activate any LVM volume groups it sees, but in a data recovery situation, you will need to know how to activate VGs/LVs manually.

When dealing with a LVM volume group with an uncertain health status, a manual vgscan as a first step should never hurt. If it returns error messages, you'll know that the volume group is damaged somehow.

After a vgscan, you might try vgchange -ay --activationmode degraded first. In most distributions, that would be the default automatic activation, but your distribution just might be using the more strict complete activation mode by default.

If that does not work, try vgchange -ay --activationmode partial. If this succeeds while the previous command failed, be aware that a portion of some of the activated LVs might be missing.

Activating the VG should also cause the device nodes for the individual LVs to appear. In some exceptional situations, you might have to create the device nodes explicitly with vgscan --mknodes, though.

If the VG was successfully activated (even partially), any LVs should become visible in the lvs output. After that, you can try mounting the LVs as usual, using either /dev/VGname/LVname or /dev/mapper/VGname-LVname naming schemes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .