I encounter the problem when I try to shrink one logical volume. I took the actions as following steps shown below:

# unmount /home
# lvreduce --size -100G /dev/vg_dev/lv_home 
# lvdisplay /dev/vg_dev/lv_home 

--- Logical volume ---
LV Path                /dev/vg_dev/lv_home
LV Name                lv_home
VG Name                vg_dev
LV UUID                QOxrP3-nS36-nZTG-yL7e-sDi0-Wl9z-LXp4pJ
LV Write Access        read/write
LV Creation host, time , 
LV Status              available
# open                 1
LV Size                197.98 GiB
Current LE             50683
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:4

# e2fsck -f /dev/vg_dev/lv_home

e2fsck 1.41.12 (17-May-2010)
The filesystem size (according to the superblock) is 78113792 blocks
The physical size of the device is 51899392 blocks
Either the superblock or the partition table is likely to be corrupt!

# resize2fs /dev/vg_dev/lv_home

resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg_dev/lv_home' first.

Picture of console.

I cannot mount the logical volume at all, can someone help me solve this problem?


It sounds like you've tried to resize a volume and filesystem in the wrong order.

When shrinking, you should perform actions in this order

  1. Resize the file system
  2. Resize the logical volume

When growing, you should perform actions in this order

  1. Resize the logical volume
  2. Resize the file system

For your issue

The first thing I would do is clone the entire drive using dd to a spare drive, and work on this one for recovery.

If you are lucky and you didn't use any of the LV available extents and thus the blocks on the disk haven't changed, you might be able to resize the LV back to what it was previously, then attempt a fsck on the file system. If the fsck passes, you can then resize the file system.

If you still get an error with the fsck you might have done irreparable damage.


lvresize now supports file system resize when passing an additional argument -r|--resizefs which mitigates the need to resize in a particular order and drastically reduces the potential for error.


I resized my logical disc, /dev/mapper and I got the error:

Either the superblock or the partition table is likely to be corrupt!

The solution was to make this order with the corrupt partition:

[root@localhost]# mke2fs /dev/mapper/VolGroup-lv_home && fsck /dev/mapper/VolGroup-lv_home

and that's all.

source: Size in superblock is different from the physical size of the partition

  • does mke2fs delete the partition? – Sridhar Sarnobat Jul 19 '17 at 5:19
  • 1
    I think this command not delete the partition. – davidleosam Nov 5 '18 at 5:12
  • 1
    hey, you saved my life after a supid manipulation. Thanks a lot ! – Rebolon Sep 16 '20 at 14:26
  • You are welcome! – davidleosam Oct 5 '20 at 16:58

One possible solution is to extend the filesystem by 100GB, but there may be some data loss. Please take the backup of the desired filesystem.

# lvextend -L +100G /dev/vg_dev/lv_home 
# resize2fs /dev/vg_dev/lv_home 

Then you can mount the filesytem.

Hope this would solve your issue.

  • meeting the error: Bad magic number in super-block while tring to open /dev/vg_dev/lv_home couldn't find valid filesystem superblock. – Xb74Dkjb Jun 15 '17 at 9:29

Obviously, only the filesystem superblock is corrupted.  To fix this issue, execute the following commands, in case if it is an ext2/3 filesystem:

mke2fs -S /dev/XXX && fsck /dev/XXX

/dev/XXX has to be replaced with the corresponding device.   For other FS, it is expected to use the corresponding mkfs commands.  With the "-S" option, only the superblock and the group descriptors will be reinitialized. The "fsck" command right after the first one is run in order to fix/adjust the group descriptors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.