HDD has corrupted partition table after installing to NVME-SSD

I have a PC which has an HDD for data storage and an NVME-SSD for system components. I installed Manjaro via the “erase disk” option to the NVME-drive.

The HDD contains a BTRFS fileystem directly on the device with not partition-table or the like. I did not select this drive anywhere during the installation.

When running cfdisk /dev/sda I get the following

Device          Boot            Start            End        Sectors      Size     Id Type
  /dev/sda1       *                  64        4769207        4769144      2,3G      0 Empty                 
    /dev/sda2                     4769208        4777399           8192        4M     ef EFI (FAT-12/16/32)
    Free space                    4777984     3907029167     3902251184      1,8T

When I run btrfs check /dev/sda I get

[seb@athene ~]$ sudo btrfs check /dev/sda
Opening filesystem to check...
checksum verify failed on 22134784 wanted 0x25272c51 found 0x983f4607
checksum verify failed on 22134784 wanted 0x14652fb6 found 0x1b1c3832
checksum verify failed on 22134784 wanted 0x25272c51 found 0x983f4607
bad tree block 22134784, bytenr mismatch, want=22134784, have=12897599460455243095
Couldn't read chunk tree
ERROR: cannot open file system

My /etc/fstab reads like

UUID=AC0B-E9A2                            /boot/efi      vfat    umask=0077 0 2
UUID=6747c9fe-d6c9-40f1-8711-54533f56fbc9 /              btrfs   subvol=/@,defaults 0 0
UUID=6747c9fe-d6c9-40f1-8711-54533f56fbc9 /home          btrfs   subvol=/@home,defaults 0 0
UUID=6747c9fe-d6c9-40f1-8711-54533f56fbc9 /var/cache     btrfs   subvol=/@cache,defaults 0 0
UUID=6747c9fe-d6c9-40f1-8711-54533f56fbc9 /var/log       btrfs   subvol=/@log,defaults 0 0
UUID=e112ce71-8e9e-4ffb-b3d7-a0fcc0903586 swap           swap    defaults,noatime 0 0

and running blkid gives

/dev/nvme0n1p3: LABEL="swap" UUID="e112ce71-8e9e-4ffb-b3d7-a0fcc0903586" TYPE="swap" PARTUUID="9ad7fe92-191f-234f-9210-8f50340f2cd3"
/dev/nvme0n1p1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="AC0B-E9A2" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="92929a65-8d76-5d49-88f2-93f25ba8aa1c"
/dev/nvme0n1p2: UUID="6747c9fe-d6c9-40f1-8711-54533f56fbc9" UUID_SUB="26bd9ebf-c56b-4a06-aaf2-293f45979251" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="root" PARTUUID="3f7e1a67-c5ba-f146-abc2-140243f56ad7"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MISO_EFI" LABEL="MISO_EFI" UUID="E681-61D6" BLOCK_SIZE="512" TYPE="vfat"

What happened to the BTRFS device? During the setup there was no notification that this device would be even touched.

Do I have any chance of getting back my files on this drive? If so, how?

When I run gparted it correctly shows me /dev/sda to be a BTRFS-device and nothing else in the partition table.

After some more trying things out with spastically shaking hands, I installed testdisk and then ran it on /dev/sda with partition table type None. There it quickly finds the following:

Disk /dev/sda - 2000 GB / 1863 GiB - CHS 243201 255 63
     Partition               Start        End    Size in sectors
>P btrfs                    0   0  1 243201  80 63 3907029168

Structure: Ok.

Keys T: change type,
     Enter: to continue
btrfs blocksize=4096, 2000 GB / 1863 GiB

However, I cannot write this new partition table, since I selected “None” as type.


It seems like the superblocks are also intact:

[seb@athene ~]$ sudo btrfs rescue super-recover -v /dev/sda
All Devices:
	Device: id = 1, name = /dev/sda

Before Recovering:
	[All good supers]:
		device name = /dev/sda
		superblock bytenr = 65536

		device name = /dev/sda
		superblock bytenr = 67108864

		device name = /dev/sda
		superblock bytenr = 274877906944

	[All bad supers]:

All supers are valid, no need to recover

To rule something out, any SMART errors logged on the HDD?

sudo smartctl -l error /dev/sda
sudo smartctl -l selftest /dev/sda

If none, then what about running a short selftest, and possibly a long selftest?

What if you boot into a live ISO, and try to access/mount the BTRFS subvolumes manually?

It looks for me, that your UUID dont match at fstab. Like


what should be from blkid


After a new installation, it can happen, that the UUID changes for a disk.

At least, i hope you didnt buy some chinese scam, i bought lately 2, 3 Sdd, what been fakes with the size and had a manipulated firmware. They are cheap(er) at the prize, but worth nothing.

Thanks for the suggestions, but I found out that I am a hell of a lot dumber than I suspected.

I did the following before installing:

  1. do a backup of all my important data on the SSD to the HDDD
  2. download the manjaro ISO
  3. use DD to flash it to my pen-drive
  4. try to boot the stick
  5. realize it is not working
  6. trying to reflash the stick
  7. realizing that my old debian installation isn’t booting anymore
  8. not giving any ■■■■■ since I wanted to do a reinstall anyway
  9. use my work laptop to flash another pendrive
  10. install manjaro to SSD
  11. try to mount the data-HDD
  12. realizing that the filesystem is botched
  13. fall asleep, wake up at night, realizing that in step 2. I DD’ed the manjaro ISO to my data-HDD
  14. fall asleep again, crying.

So Manjaro did nothing wrong, I was just very stupid.

Have you already tried to mount the btrfs filesystem readonly ?

If this is true,

I would try to rescue my data. Before i change anything on this disk !!!

When you are able to mount this filesystem readonly, you can rescue its Content in various ways. Which way you choose is up to you.

A) Copy all Files with rsync to an empty device that is big enough

This can be done when the filesystem on sda is mounted ro into a live manjaro

B) Copy some valuable files to an filesystem with enough space

This can be done when the filesystem on sda is mounted ro into a live manjaro

C) Use btrfs send to clone the filesystem

I cant´t give any advice on this one

or D) Move the btrfs filesystem to another device

That seems crazy, but for me that would be the my way.

However, I cannot guarantee that this will work with the damaged blocks (checksum).

  • First, of course, save important data with Method B!

  • Then try to mount the file system rw. (Don’t forget to have compression turned on!) If the structure is not damaged, this should work

  • Then add another (empty) device to the volume (of sda) that has enough space for all data. But this time a partition, please! (The partition must not be formatted)

  • Then remove the existing device(sda) from the volume (sounds crazy) After that btrfs will move all data from the existing sda to the new partition while the complete file system keeps all snapshots …

  • This may take some time now. Only when the process is completed, continue !!! You can check this with btrfs filesystem show. Then only the new partition (1 device) will be displayed

  • After you have inspected your data there!

  • Switch sda to a partition table and do not format

  • Allocate all space for sda1 , add sda1 to the volume, and move the whole thing back by removing the partition that was just used as temporary storage.

  • Again btrfs will move all data of the volume back to /sda1

These will only move blocks that have real data in it. empty blocks will not be moved at all.

Good luck


Your data is gone.

Do you have any backup of such data?

At first it was originally on the SSD, but it sounds like you formatted the SSD after you “safely” copied its contents to the HDD. Then you accidentally wiped the HDD with “dd”.

So where else does this data exist?

Always have three copies of important data.

  1. The original.

  2. A backup.

  3. Another backup (usually in a different physical location).