1

I have a concerning adventure while trying to resize(shrink) my LUKS lvm partition. I wanted to shrink my partition so that I can easily copy my system to a new smaller sized drive. Before I started anything I deleted some files from my old disk to make some space available. Afterwards I booted from USB live ubuntu and I used the KDE partition manager to firstly unlock the LUKS partition. Afterwards I had my LVM root partition available and I used the resize option of the KDE partition manager to shrink it. This unfortunately resulted to the same issue as described here: "Either the superblock or the partition table is likely to be corrupt!" after partition resized

And my problems started from a misunderstanding of one of the answers. So what I ended up doing is that I run the following command:

e2fsck -f /dev/the_unlocked_lvm_root

With the following selection of options:

e2fsck 1.45.5 (07-Jan-2020)
The filesystem size (according to the superblock) is 239771648 blocks
The physical size of the device is 125080576 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Error reading block 126877728 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes

I pressed yes some times until I realized that I was not doing what I should. Right now I didn't restart my computer and I didn't do anything more. My question is basically how much damage I did, is the problem recoverable or did I loose all of my data? I am pretty concerned since when I stopped the e2fsck command it stated "Filesystem modified".

Any feedback is appreciated!

VGe0rge
  • 559

1 Answers1

0

I just ended up having a similar problem and could resolve it. I didn't use the KDE partition manager but the command lvresize to resize my logical volume:

DO NOT RUN THIS COMMAND: lvresize --verbose -L -40G /dev/mapper/vgubuntu-root

My question is basically how much damage I did, is the problem recoverable or did I loose all of my data?

What happened?

The following description is my assumption and could partially be wrong, please feel free to edit/comment to clarify misunderstandings.

  1. First of all, a logical volume is just THAT, a volume similar to a hard drive, NOT a partition table or a file system.

  2. The file system resides inside the logical volume, so to my understanding the logical volume does not have a partition table. (Creating a filesystem on a whole disk rather than a partition is possible, but unusual)

  3. Shrinking the volume without shrinking the filesystem is like cutting out sectors of a hard drive. Probably because of the missing partition table, the KDE partition manager thought the volume was empty, letting the user edit it freely.

  4. NOW the volume shrunk BUT the filesystem still has blocks that are beyond of the volume scope, that is why e2fsck can not read block 126877728, it is beyond the scope of the volume.

  5. Although e2fsck wanted to rewrite, it could NOT because the block is simply not accessible.

  6. Because the information about the volume size, as well as the filesystem, are stored at the BEGINNING of the overlying partition on the physical hard drive, NO DATA IS ACTUALLY LOST, at least on HDDs (probably on SSDs to). Again e2fsck could NOT rewrite the blocks, bits and bytes are basically untouched somewhere on the actual hard drive.

  7. So quite logical UNDO the shrinking by simply increasing the logical volume size WITHOUT touching the file system should resolve the issue.

TL;DR

Increase the volume back to its original size should resolve the issue without data loss:

lvresize --verbose -L +SIZE /dev/mapper/vgubuntu-root
    # SIZE you shrunk the volume
    # `lvresize` <volume> => resize a logical volume
    #   --verbose  => Give more info.
    #   --resizefs => Resize filesystem AND LV with fsadm(8).
    #   -L         => Specifies the new size of the LV, 
    #                 +/- add/subtracts to/from current size, e.g. g|G is GiB.

e2fsck -f /dev/mapper/vgubuntu-root
    # e2fsck <fs-path> => Check a Linux ext2/ext3/ext4 file system
    #   -f => Force checking even if the file system seems clean.


# Output should look like this:
#   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

IF YOU DON'T KNOW THE ORIGINAL SIZE, you can subsequently increase the volume size (within the boundary of the overlying partition), e2fsck should subsequently have less blocks in its error report:

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +121110528 +(121110532--121110533) +(121110537--121111049) +(121112586--121113097)

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +(121110537--121111049) +(121112586--121113097)


lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Pass 5: Checking group summary information

How to shrink the logical volume AND the file system

Use lvresize with the --resisefs option (which will resize the filesystem - Captain Obvious):

# Shrink logical root volume AND filesystem
lvresize --verbose --resizefs -L -SIZE /dev/mapper/vgubuntu-root
goulashsoup
  • 187