I have been running Pop!_OS for a while now, and decided to install Kubuntu. I booted into the Kubuntu USB drive to try it first, and decided to prepare the partition for installation with KDE Partition Manager.

This SSD already had 4 partitions: sda1 (old Windows install), sda2 (data), sda3 (Pop!_OS) and sda4 (swap). To make space for a new partition for Kubuntu, I shrunk the end of sda2 by 30Gb, but couldn't format this unallocated space as there were 4 primary partitions already. So I decided to delete sda1, move it's unallocated space to the right of sda2 and add that space into sda2. When applying the actions there was an error (something about a size mismatch) and it was aborted.

Booting back on Pop!_OS, I can see the 30Gb of unallocated space taken from sda2 are there, and that sda1 wasn't touched, but I can't mount sda2:

sda mount error

Here is what GParted shows now:

What GParted shows

Here are the info for sda2:

Info about sda

And the output of fdisk -l:

enter image description here

(partition table entries are not in disk order).

As it seems there could me multiple problems, I decided not to touch it for now and get some advice, I'd really like to recover the data in that partition. If any more information is needed I'd be glad to provide it. Sorry for the long thread, and thank you so much for your time.


While I wait for any feedback, I've attempted to fix the order of the partition table entries using fdisk. After doing the procedure (and having to fix GRUB to be able to boot back in) fdisk does not report them as out of order.

Another thing I did was use gparted's check option on that partition, which returned some more interesting info:

GParted 0.32.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2
Check and repair file system (ext4) on /dev/sda2  00:00:00    ( ERROR )

calibrate /dev/sda2  00:00:00    ( SUCCESS )

path: /dev/sda2 (partition)
start: 275396608
end: 782370815
size: 506974208 (241.74 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )

e2fsck -f -y -v -C 0 '/dev/sda2'  00:00:00    ( ERROR )

The filesystem size (according to the superblock) is 71051776 blocks
The physical size of the device is 63371776 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

e2fsck 1.45.3 (14-Jul-2019)

That is the error that started all of this, I just had not managed to save that info. It seems to me the partition simply doesn't know it's actual size? It started of with over 270GB, then I removed 30GB for a new partition. Thunar reports it has 260GB, Dolphin, GParted and fdisk report it has 240GB, which makes sense. Now how could I fix that, without making things worse? Thank you so much again, for anyone reading.

  • Welcome on U&L! I uploaded the images you shared to the official cloud storage used by Stack Exchange, to ensure they will stay available, and replaced links with images to make your question more readable. Please note that, as a general rule, we should avoid posting images of text (mainly talking about fdisk's output here); refer to the linked Q/A on the Meta site for further information. Thank you.
    – fra-san
    Mar 13, 2020 at 16:39
  • Thank you very much @fra-san :)
    – Neptunian
    Mar 13, 2020 at 17:13
  • Did you ever get this to work? Did you try the steps given in the answers?
    – Gordster
    Mar 20, 2020 at 8:19

2 Answers 2


It looks like you forgot to resize the filesystem after shrinking the partition. You must use resize2fs in order to shrink the filesystem to be smaller than the partition is. You cannot have partitions that are smaller than filesystems

resize2fs /dev/sda2 239G

This should give you one gig of space to ensure the filesystem is smaller than the partition itself.


This advice is given without any guarantee, especially considering that we can not know what exactly happened to your partitions/file systems.

Before making changes to your partitions and/or file systems you should backup the raw data, e.g. by booting from a live CD/DVD/USB and copying your entire disk to a safe location. Saving it as a compressed regular file (to save space) is as easy as:

$ sudo gzip -c /dev/sda >/path/on/safe/storage/sda.img.gz

That said, it looks like your partition manager has successfully shrunk sda2 (the partition), but failed to shrink the contained file system.

You should be able to confirm what GParted is saying by running:

$ sudo fsck.ext4 -v -f /dev/sda2

(answer y if it asks you to abort).

Instead of trying to resize the file system, I'd suggest you to restore the size of sda2 to what it originally was. Or, anyway, to grow sda2 by the amount of free space it has on its right. If the contained file system is not damaged, this should make it possible to mount it again, at least allowing you to backup your data before trying to shrink that partition anew.

Based on personal preference, I'd use GNU parted to edit the partition table and re-create the second partition (sda2):

$ sudo parted /dev/sda
(parted) unit s
(parted) rm 2
(parted) mkpart primary ext4 275396608 843810815
(parted) quit

This, of course, is based on the fdisk output you originally posted. You may need to adjust it if something as changed since then.

(Using fdisk instead of parted is straightforward, too: after sudo fdisk /dev/sda, use p to inspect the partition table, d followed by 2 to remove sda2, n followed by p, 275396608 as the first sector and nothing as the last sector (the last sector of the contiguous free space will be picked by default) to re-create sda2, w to save. You may then need sudo partprobe -s /dev/sda to tell the kernel about the updated partition table).

Then, you may be able to check the file system (as above, using fsck.ext4 -v -f /dev/sda2) and to mount sda2 again.

Finally, you may retry shrinking sda2: the tools you are using, including KDE Partition Manager, should be able to do it. I'd just suggest you to save/apply one operation at a time (e.g. delete sda1 or shrink sda2 or shift sda2...) and avoid enqueuing several of them—it increases the probability to come across some untested corner case.

You must log in to answer this question.

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