Partition corruption after resizing with GParted – Need help recovering my Linux KDE Neon

Help
1

Partition corruption after resizing with GParted – Need help recovering my Linux KDE Neon (nvme0n1p4)

Initial context:

I had a dual boot setup with Windows 10 and Linux KDE Neon 5, where GRUB was installed on the old KDE partition (nvme0n1p4) and used to boot all my OSes.

A few months ago, KDE Neon 5 became outdated and couldn’t be updated properly anymore, so I installed KDE Neon 6 on a new partition while keeping the old KDE Neon 5.
However, I never reconfigured GRUB, so I continued using the GRUB from the old KDE installation to boot both my new KDE Neon 6 and Windows 10.

The old KDE (Neon 5) was no longer my main OS, but I kept it because it contained important files that I hadn’t fully migrated yet.

What caused the problem:

I initially tried to run my Windows 10 installation in a VM using KVM/Passthrough, but I couldn’t get it to work properly.
So I thought about installing Windows 11 on a new partition instead.

To do that, I decided to shrink the partition of my old KDE (nvme0n1p4) using GParted to free up space for the new installation.

  • I booted into RescueZilla (Live USB)
  • I launched GParted and started resizing nvme0n1p4
  • GParted crashed during the process, and the partition became corrupted

Since then, the partition /dev/nvme0n1p4 is inaccessible, and since GRUB was installed on that partition, I could no longer boot into any Linux system, and my PC would boot directly into Windows 10.

By selecting my KDE Neon 6 installation from the boot menu, I ended up in a minimal GRUB shell.
I was able to manually boot into KDE Neon 6 using GRUB commands, and once inside my Linux system, I reinstalled GRUB properly for KDE Neon 6 so that I could boot normally again.

Attempts to recover the corrupted partition:

1. Checking the partition in GParted (from RescueZilla)

From RescueZilla, I opened GParted to inspect the partition status:

  • The partition /dev/nvme0n1p4 is still detected
  • The total partition size and used space are correctly displayed
  • There is an unallocated space that matches the amount I tried to shrink before the crash

I’m attaching a screenshot of GParted showing these details.

image
image2559×1439 140 KB

2. Repair attempts with fsck and e2fsck

First attempt with fsck:

sudo fsck /dev/nvme0n1p4

➜ Result: It detected a massive number of errors and asked for manual confirmation (“o”) to fix each one.
I pressed “o” repeatedly, but there were still many more errors left to fix.

Attempt with e2fsck (automatic mode):

sudo e2fsck -y /dev/nvme0n1p4

➜ Result: It automatically fixed many errors without requiring manual confirmation.
However, some critical errors remained unresolved.

Another attempt with different parameters:

sudo e2fsck -f -y /dev/nvme0n1p4

➜ Result: Some errors were fixed, but others persisted, including corrupted inodes, unreadable blocks, and file system inconsistencies.

Example errors encountered:

Inode 102614 has an invalid checksum.
Fix? yes
Inode 203487 is in use, but has dtime set.
Fix? yes

Some issues were resolved, but not all.

3. Attempt with TestDisk

I then tried TestDisk to see if I could recover the partition.

sudo testdisk
  • It detected the /dev/nvme0n1p4 partition
  • It reported corrupted blocks and overlapping file system structures
  • It suggested rebuilding the partition table, but I wasn’t sure about the correct approach
  • I ran a deep scan, and it correctly identified the partition with the right size, but I wasn’t sure which recovery option to choose safely

4. Using find-overlap.py and dd to recover the partition

I found a script on GitHub that helps identify corrupted areas in a partition after a failed resize operation:
:link: GitHub link to find-overlap.py

The script generated several dd commands to attempt a recovery.

Example of the generated commands and their execution:

sudo dd if=/dev/nvme0n1p4 bs=1048576 count=171032 of=/dev/nvme0n1p4

:heavy_check_mark: This command successfully copied about 179 GB without errors.

sudo dd if=/dev/nvme0n1p4 bs=1048576 skip=171039 seek=171032 of=/dev/nvme0n1p4

:x: This command returned an error:

dd: error reading '/dev/nvme0n1p4': Input/output error

Despite the error, 140 GB were copied.

Other similar dd commands successfully restored some areas, but some regions still have errors.

Current situation and questions:

  • Current state of /dev/nvme0n1p4:

    • The partition is still detected by GParted and TestDisk
    • Some parts of the file system are readable, but others still show I/O errors
    • fsck and e2fsck fixed some errors but not all
    • The dd commands helped recover certain blocks, but some areas remain corrupted

  • GRUB issue:

    • Due to this corruption, I lost the GRUB installed on the old KDE
    • I was able to boot into my new KDE (Neon 6) via the GRUB shell and then properly reinstall GRUB for KDE Neon 6

What I need help with:

  1. How can I fully repair /dev/nvme0n1p4 and recover my old KDE Neon 5 without data loss?
  2. Can TestDisk help restore this partition safely? If so, what’s the best method for this specific case?
  3. Should I retry some dd commands or use ddrescue instead to recover the remaining corrupted areas?
  4. Are there any other tools or approaches I could use to retrieve the existing files from the partition?

Thanks in advance for your help!

2

DONT WRITE TO THAT DISK

I haven’t read this yet, but I’m here to give you urgent advice. I’ll reply again when I’ve read it.

2 Likes
3

Aw I was too late :frowning:

Tip for future dramas: Do the recovery on a clone of the drive. Once you start writing to a drive, you’re potentially making deleted or lost data unrecoverable, so you don’t want to be doing that to the real drive. You want to freeze that thing in time, as intact as it is or isn’t, and work on a copy of it. Ultimately, you take one clone from it, and then copy that, and work on the copy of the clone. This way, if you hose the copy, you still have the clone, and don’t have to risk reading from the drive again and again, in case of electrical or mechanical issues.

It’s too late to prevent damage, but it’s not too late to keep it to a minimum.

  1. Don’t. Restore from a backup, or copy recovered data from the drive however you’re able, but don’t attempt to recover the partition for future usage. That thing is toast. Once you have the data you need, low-level format the thing. That partition has done you wrong and can’t be trusted.

  2. I’d ask about TestDisk on their forum I doubt there are better experts elsewhere.

  3. The right tool to use, really varies from one recovery to the next. Even in the professional space, a lot of data recovery is a case of trial and error. Try all of the tools. Since you’re working on a copy of a clone, you can safely experiment and squeeze as much data as you like out of each tool until you get what you need.

  4. Edit: Mix and match the tools as needed. Sometimes you might need to use tool A and C but not B. Not all of them will help, some will just make it worse. Another reason why it’s important to not work on the real one.

Sheesh, good luck OP. I’m going to go do that backup I’ve been putting off I’m terrified now.

2 Likes
4

You’re absolutely right, I should have worked on a cloned drive, but unfortunately, I didn’t have another one large enough on hand. That was a huge limitation for me. The problem with using large drives is that if you don’t have a second one of similar size, making a full backup is pretty much impossible unless you compress everything massively, which seems like a headache.

I also naively thought GParted would handle everything as usual and that nothing would go wrong, obviously, that was a mistake. This was a big wake-up call, and I realize now that I was really close to losing my current system, which contains a lot of critical data!

From now on, I’ll make sure to secure my data as much as possible during these operations and prioritize backups.

Just in case, I’ll be posting on the TestDisk forum as you suggested, but do you think my other partitions are at risk because of the corrupted partition or the operations I performed?

In the end, I won’t stress too much about recovering this partition. Luckily, most of the important files were already copied over to my new OS, so my main concern was really just the GRUB issue. If I can recover the partition, great, but I won’t fight too hard for it since it’s not my primary system anymore.

That said, I’ll still try to gather as much information as possible since this could be useful in the future. I guess I got lucky this time and narrowly avoided disaster, this is a strong reminder that backups are essential!

And of course, thanks again for your help and response! :blush:

1 Like
5

For grub, I’d just put a fresh bootloader on there, there’s nothing much to gain from recovering that. It’s only really the data that you need, the pictures and videos and music and your epic novel and stuff.

If you can get that by means of the filesystem recovery then great, but if the filesystem is being resistant, you might as well go around it. Especially if this is your only copy, it might be best to do that anyway. Repairing the filesystem might write data to the drive and nuke some data you wanted to keep. Rather than trying to fix it, just try to read from it in a meaningful way.

The filesystems and the partitions can be rebuilt. The bootloader partition, if it was damaged too, definitely just nuke it from orbit and put a new one on there (or better yet just use that one bootloader for all your OS’s). As for how to do that, I’ll leave it to the Neon experts, which I am not.

I feel you mate, that is exactly what I’m wrestling with right now

1 Like
6

Yeah, I totally agree about GRUB, I already reinstalled it properly on my current KDE Neon 6 installation, so that part is all sorted. No need to recover the old one.

I’ve followed your advice and posted a message on the TestDisk forum, I’m just waiting for it to be validated by the moderators now.

Thanks again for your help and your time!

1 Like