Fixing an ext4 whole-device filesystem and corrupt GPT partition table

Question

I have an issue very similar to the question here:

https://askubuntu.com/questions/1370421/restore-ext4-hd-after-creating-gpt-partition-table

My problem seems to be that I had an ext4 filesystem which sat directly on a block device, and installing windows to an entirely different drive decided to mess with that device's partition table (or, seemingly, it's lack of a partition table).

When I booted, this drive has a GPT partition table which looks like so:

λ  sudo fdisk -l /dev/nvme1n1
Disk /dev/nvme1n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 73405727-65E8-485F-99F8-C2D65E99D767

Device         Start        End    Sectors   Size Type
/dev/nvme1n1p1  2048 1953525127 1953523080 931.5G Linux filesystem

But this partition is unmountable and appears to have an invalid filesystem. I can, however, get all my data back by running fsck.ext4 /dev/nvme1n1 - but seemingly since this is the whole device rather than the partition, doing this then blows up the GPT table:

λ  sudo fdisk -l /dev/nvme1n1
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
...

I can re-write the table with gdisk, but then I'm back to having a broken file system. I can toggle back and forth like this, but I can't figure out how to do what I actually want: create a valid GPT partition table and recover my existing filesystem onto it.

I have tried passing explicit superblocks, without good results:

λ  sudo fsck.ext4 -p -b 32765 -B 4096 /dev/nvme1n1p1
fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme1n1p1

Answer 1

It's not possible (that way).

You can't have a partition table, and a filesystem, on the same block device.

When you create a partition on /dev/nvme1n1, it gives you a new block device /dev/nvme1n1p1 — you have to use the new block device for the filesystem.

And that means shifting all data by the partition offset. Keeping the filesystem data at the old offset won't work. fsck won't fix that for you. So it can't be done (the way you're trying to do it).

So your options are:

• keep using the bare drive as is and remove the msdos/gpt partition table headers entirely (use wipefs to remove msdos/gpt partition headers only)

• shrink the filesystem by 2MiB then move it by 1MiB (or whatever your partition offset is). Shrinking is necessary to make room for GPT headers at start and end of drive.

• backup all files, set it up properly from scratch with new partitions and filesystems, then restore files to it

I recommend the last option. While shifting data offsets can be done in theory (and tools like gparted might help you), it's actually very risky to do so and when anything goes wrong, you're left with a device that is unusable and there is no trivial fix.

Using bare drives directly is possible in theory but in practice, you run into this exact case that something else "helpfully" creates a partition table for you, damaging your data in the process.

Thus having a partition table is not optional; it's mandatory.