10

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:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
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
Irreversible Reboot
  • 131
  • 1
  • 1
  • 6
  • 1
    Have you installed Manjaro, or have you only created the new partitions? – Stephen Kitt Feb 05 '20 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). – goulashsoup Jun 05 '22 at 16:33

3 Answers3

10

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!

Stephen Kitt
  • 434,908
  • 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 Feb 05 '20 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. – Stephen Kitt Feb 05 '20 at 16:24
  • this fix my luks partitioned harddisk that cannot be mounted. – buncis Mar 31 '23 at 06:45
  • Thank you. I have cloned my partition from old ssd and using those commands, it's booting again. ;) – Fernando Vieira Apr 12 '23 at 22:56
6

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.

fpmurphy
  • 4,636
dave58
  • 216
  • 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 May 01 '21 at 16:31
1

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.

leiri
  • 11