0

I was trying to shrink my home partition. I followed this ArchWiki article for that. According to this I first resized my filesystem using resize2fs and then resized my physical device using parted. In resize2fs parameter I gave my intended size as XG and after resizing, it reported that new size is Y (4k blocks). From this info I calculated my partition size is (Y * 4) KiB and when resizing physical partition using parted I used this size. But in reality it is (Y * 4) KB. So now total block number of the filesystem is higher than the total block number of the physical device.

In resize2fs man page it is stated that if size isn't specified it will take up whole space from the device. So to solve this problem I ran resize2fs again so that it match the fs size with physical size. But it gave following error:

resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/sda3 to 159907584 (4k) blocks.
resize2fs: Can't read a block bitmap while trying to resize /dev/sda3
Please run 'e2fsck -fy /dev/sda3' to fix the filesystem
after the aborted resize operation.

But when I issue e2fsck it reported the mismatch and suggested to abort. So, now I am stuck in a loop:

e2fsck 1.45.6 (20-Mar-2020)
The filesystem size (according to the superblock) is 186122240 blocks
The physical size of the device is 159907584 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? 

Is there any way to recover from this? Is it safe to mount and access the partition so that I can take backup?

Thanks!

  • 1
    You are lucky both these tools aborted before doing damage. – Philip Couling Jun 19 at 20:01
2

From what you write, you have accidentally shrunk a partition smaller than the file system it contains. On it's own this shouldn't lose any data but almost every action you might do after that could [have]. This definitely includes resize2fs, e2fsck and mount. It appeares you were very lucky since the two commands you executed both detected the problem and aborted.

The big question is did you do anything with the extra space you created by shrinking the partition? If you did, if you made an additional partition and formatted it, then you may have damaged your data beyond repair. If not then you may be okay.

To fix the immediate issue you must use a tool such as parted to increase the partition back to its original size. If you did nothing with that free space already then your data should be right where you left it. This will fix the immediate problem and you can use e2fsck to double check. Do abort if it gives you a similar warning to the first time.


The root cause of your problem is that you have not properly shrunk the file system with resize2fs before you shrink the partition with parted. This is necessary to move any file data out of the space you are going to remove from the partition.

I note that the wiki you reference correctly indicates that you should specify the size in resize2fs....

... Please be very careful with units and take the time to understand the numbers you are entering. 4k blocks in an ext2/3/4 means 4096 bytes. Elsewhere the term "block" can mean something completely different. Also many partitioning programs including parted make a distinction between KB, MB... and KiB, MiB. Make sure you know which units you intend:

  • KB = 1,000 MB = 1,000,000
  • KiB = 1,024 MiB = 1,048,576
| improve this answer | |
  • Actually, I knew the distinction between KB and KiB. When resize2fs reported size as 4k blocks I thought it as 4KiB block while actually it was 4KB blocks. Anyway, I didn't do anything with the free space. I can do what you suggested. There is an issue though. Originally there were 4 partitions in following order /, swap, /home and then another partition with some space. I deleted 4th partition and then shrank /home. The problem is I think now there is no way to tell the original size of the /home partition. Should I merge all the free spaces with /home? or make it exactly how it was? – Ashfaqur Rahman Jun 19 at 21:05
  • 1
    Yes. 4096=4KiB. It's okay to use parted to make the partition bigger than it originally was. Think of the partition as the area the file system has access to. By shrinking the partition you took away access to the end. If you add back more than you took away, you are just granting access to something it doesn't need. – Philip Couling Jun 19 at 21:07
  • It worked! Phew! I have merged all the free space and then ran e2fsck. Executed without any error. Thank you! This was a lesson for me though. I will be more cautious in the future for sure in these operations. Anyway, concepts like KB, KiB, and then blocks is pretty confusing and easy to get messed up while using multiple tools. OK I am gonna mount the partition, lets see If everything is allright. – Ashfaqur Rahman Jun 19 at 21:23

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.