I used KDE's partition manager tool from the Manjaro live CD to shrink my existing Linux Mint partition and create another one to install Manjaro.

This went fine, however, it looks like my Linux Mint partition got corrupted in the process. Trying to boot into it sends me to initramfs.

Here's the output of e2fsck:

$ e2fsck -fy /dev/nvme0n1p6
e2fsck 1.45.5 (07-Jan-2020)
The filesystem size (according to the superblock) is 32907264 blocks
The physical size of the device is 22641408 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

Here is the output of lsblk:

nvme0n1     259:0    0 238,5G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part /boot/efi
├─nvme0n1p2 259:2    0    16M  0 part 
├─nvme0n1p3 259:3    0  93,5G  0 part 
├─nvme0n1p4 259:4    0   980M  0 part 
├─nvme0n1p5 259:5    0  13,1G  0 part 
├─nvme0n1p6 259:6    0  86,4G  0 part              # Linux Mint partition
├─nvme0n1p7 259:7    0   5,2G  0 part [SWAP]
└─nvme0n1p8 259:8    0  39,2G  0 part /            # New Manjaro partition

  • 1
    Have you installed Manjaro, or have you only created the new partitions? Commented Feb 5, 2020 at 16:25
  • It seems KDE's partition manager doesn't care about the filesystem, probably increase the partition the same size you shrunk using KDE's partition manager (before deinstalling it) THEN run e2fsck and the filesystem should be fine again. Then resize the filesystem first (maybe there is a command that can decrease the partition and the filesystem in one go). Commented Jun 5, 2022 at 16:33

3 Answers 3


I’m assuming the question is “what do I do now?”

First of all, any data stored at the end of your Mint partition is gone. If any of the data on the file system is important, you should make a copy of the partition to another device.

To fix the file system and hopefully boot again, you need to first complete a fsck run:

e2fsck -f /dev/nvme0n1p6

Answer “n” to the first question (“Either the superblock or the partition table is likely to be corrupt! Abort?”), then “y” to all the subsequent questions — e2fsck will ask you about all the lost inodes.

Next, try to resize the file system:

resize2fs -f /dev/nvme0n1p6

This will work if no files were present past the end of the (shrunk) partition. Otherwise, you won’t be able to resize the file system, and you’re into file system surgery territory. One approach which could work is to delete the swap and Manjaro partitions, edit the partition table to restore the Linux Mint partition’s old size, and then resize it to its new size. Since you’ve only just installed Manjaro, presumably you might not mind reinstalling it!

  • 1
    It might not be lost, he says he used KDE's partition manager, if he has only modified the partition size without doing anything else he might have all his data, he just needs to repartition again to the previous partition size. If he used the resize2fs then he might have lost it. The steps to resize a partition are first resizing resize2fs and repartition after that. Maybe he has only done the second step and he is able to go back and do it the right way.
    – YoMismo
    Commented Feb 5, 2020 at 16:19
  • @YoMismo I thought the OP installed Manjaro in the space freed by resizing... But you’re right, perhaps only the partitions have been resized. Commented Feb 5, 2020 at 16:24
  • this fix my luks partitioned harddisk that cannot be mounted.
    – buncis
    Commented Mar 31, 2023 at 6:45
  • Thank you. I have cloned my partition from old ssd and using those commands, it's booting again. ;) Commented Apr 12, 2023 at 22:56

If other answers do not fix your problem, you may need to make sure the partition table matches the device.

  1. fdisk
sudo fdisk -l /dev/whatever

Copy the results down (on paper). Then up-fix the partition table:

sudo fdisk /dev/whatever

Delete the partitions. Then recreate them using the same parameters. Don't be surprised if the final partition forces/lets you use a different size.

  1. fsck
sudo fsck /dev/whatever

Answer “n” to the first question (“Either the superblock or the partition table is likely to be corrupt! Abort?”), then “y” to all the subsequent questions.

  1. Shrink the offending filesystem:
sudo resize2fs -f /dev/whatever_partition

e.g: resize2fs -f /dev/sdb9

With thanks to https://unix.stackexchange.com/users/86440/stephen-kitt for his first answer, which I would love to upvote but due to stack exchange policy can't because I don't have 'reputation'. Can't add a comment either. :-( It's his answer except I had to add the bit about making sure the partition table matched the device.

I had this problem when I dd'd a Pi image onto a new chip which apparently didn't match to original chip's geometry.

  • 1
    Great! I was able to fix a stupid inexplicable problem on a partition that would not mount like this: The filesystem size (according to the superblock) is 122096390 blocks The physical size of the device is 122096389 blocks ( resize2fs -f /dev/sdc1 fixed the problem)
    – MKaama
    Commented May 1, 2021 at 16:31

I ran into the same problem: I shrunk the last partition of my drive without adjusting the file system, resulting in a partition/file system mismatch.

However, I did not create a new partition in the freed space yet!

Because of that, I could resolve the mismatch by extending the resized partition to its old size: I could not use KDE's partition manager for this, as it stopped with a fsck error when checking the existing partitions.

Instead, this comment helped me to resize the partition using growpart.

Note, that I did not format the freed space after the shrunk partition. And it was also at the end of my drive, where the mismatch occurred.

I don't know if the tool works in other cases, but for the described case it resolved the issue and restored my bootable system.

You must log in to answer this question.

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