1

I seem to have corrupted my primary LVM partition [1] which contains root and swap partitions.

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00025e8d

Device     Boot    Start       End   Sectors  Size Id Type
/dev/sdb1  *        2048   2099199   2097152    1G 83 Linux
/dev/sdb2       39051264 468862127 429810864  205G  5 Extended
/dev/sdb5       39053312 468860927 429807616  205G 8e Linux LVM

gparted says this about /dev/sdb5:

Unable to detect file system! Possible reasons are:
- The file system is damaged
- The file system is unknown to GParted
- There is no file system available (unformatted)
- The device entry /dev/sdb5 is missing

The system doesn't seem able to find the LVM partitions at all:

$ sudo vgchange -ay ubuntu-vg
  Volume group "ubuntu-vg" not found
  Cannot process volume group ubuntu-vg

$ sudo lvscan -av
    Using logical volume(s) on command line.
    No volume groups found.

How can I go about fixing /dev/sdb5?

I'm currently running gpart on /dev/sdb to see if that helps. fsck doesn't work:

$ sudo fsck /dev/sdb5
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb5

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

I believe the original filesystem on /dev/sdb5 was "lvm2 pv", and I have the option to format /dev/sdb5 as that via gparted, but before I make things worse, I thought I would ask here.

[1]: I was adding extra space to my boot partition when I corrputed this. I was following directions here, here, and here. This is roughly the order I did things in (to the best of my memory)

  • I reduced ubuntu-vg/root by a couple GBs to free up some space
  • I tried to pvmove ubuntu-vg/swap, but it complained about not having enough space
  • I reduced ubuntu-vg/root some more
  • I p4moved ubuntu-vg/swap to push the unallocated space to the end of /dev/sdb2
  • I used KDE Partition Manager to move /dev/sdb5 to the end of /dev/sdb2, so that the unallocated space is at the beginning of /dev/sdb2
    • I tried to have KDE partition manager then shrink /dev/sdb2 to free up the unallocated space for /dev/sdb1, but it errored out on that operation. I opened gparted, and it told me to reboot, so I did
  • I opened gparted, and shrunk /dev/sdb2 and grew /dev/sdb1. This is when I noticed that had an error on /dev/sdb5
Jeffrey
  • 231
  • 4
  • 15

2 Answers2

0

This is a bit old, but let me give my two cents worth. I've had logical volumes corrupt several times, and I'm in the middle of it again now. I don't know why it happens, but I'm guessing it's when I do a backup, which creates a temporary snap volume to preserve integrity of the data during the backup process,and the backup script crashes due to some (I raise my hand) error. This leaves the snap volume hanging in LVM space, and I'm guessing corrupts the logical volume I was backing up.

Luckily, I've learned over the years to do backups daily, so I always have a fresh backup. The question is when the corruption occurred, as the system will still seem to work fine, with minor glitches here and there as the corruption gets worse until the operating system can't even boot, which can take several days to over a week (maybe?).

I see there is a lvmreport tool which is included with the LVM package, but I haven't used it. I'll have to look into it and maybe make it part of my standard backup procedure.

Also luckily, I've learned over the years to have multiple versions of Linux installed on each of multiple hard drives in my system, so if one goes down, or a whole drive goes down, I can boot into another, and then try to recover the buggy installation. If you don't have this, you can always boot from a live CD, DVD, or thumb drive.

As I've said, I at first don't know that the lvm is the problem, so I'll do a restore, preferably using an image file (I use fsarchiver for my image backups), but alternatively using a tar backup. If the recovered installation is still buggy, I know the logical volume is corrupt and I'll need to delete the logical volume(s) and recreate them. It's possible I might also have to delete the volume group and recreate that. If there are other logical volumes in the volume group, it could be questionable if they are corrupted or not, and whether the data can be transferred to another clean volume in another group or a physical partition. DO what you feel is necessary.

So then delete the volume group if necessary, or just delete the logical volumes, recreate the volume group and/or logical volumes, reinstall the installation from backup.

You'll also need to run chroot to renew the boot folder for the new logical volumes. You can find info on that here how to restore boot folder?

Oh, BTW, gparted has no visibility into logical volumes, or has anything to do with creating or restructuring them. you need LVM or KVPM for that, which I see you do use. Also, it's a good practice (note to me) to leave unused space on your hard drive as well as within your LVM physical volumes and volume groups, so you have room to move things around when you're in a dire situation like this.

randyman99
  • 151
0

I know this is an old way, but it is still getting a lot of views, so I thought I would post a useful answer:

This is issue is the hardiest to fix, as the root drive is part of the lvm, and therefor you do not have the backup lvm configs to use to recover.

It appears you were able to boot into a working version of ubuntu. I would therefore suggest you install testdisk.

testdisk can search and recover partitions. If this situation happens to you, do not move partitions around or do anything to the drive unless you have to. The partition table is an index, if you loose your partition table, it can be "fairly easily" recovered, however if you move the partitions, and/or copy data to the drive, then your data may get overridden, as the controller for your drive, does not know there is data already stored in the sectors. If you data gets overrideen, then you can not recover your data,it is impossible.

testdisk can be installed via apt. Documentation on how to use testdisk can be found at https://www.cgsecurity.org/testdisk.pdf The documenttion also includes a number of helpful tips to repair differnt types of file systems.

Luke Attard
  • 982