partition recovery for a raspberry disk

[recuperation]

There is no superblock on your defective card, neither at the beginning of the partition nor at the location of the first duplicate. There is empty space.

"ext4_validate_block_bitmap" sounds like the name of a function that cross-checks a bitmap by comparing with the block usage extracted from file and folder usage and other sources I am not aware of.

You might try to check the other duplicate suberblocks.

Otherwise I don't have any proposal left - I don't use ext4 and I am not familiar with it.

[tom1689494]

ok...
it seems to me that all the superblock duplicates are all the same..

how about I try and copy the superblock of the clean card onto the defective one?

What would be the command to write a superblock back into a disk please?

[recuperation]

Replace

/dev/sdx1 with the name of the partition of your source superbock
/dev/sdy1 with the name of the partition of your target superbock

The command is:

dd if=/dev/sdx1 of=/dev/sdy1 bs=1024 count=1 skip=1 seek=1

[tom1689494]

many thanks!
I think you meant the second partition, so I ran (on the disk copy):

Code: Select all

dd if=/dev/sdb2 of=/dev/sdc2 bs=1024 count=1 skip=1 seek=1

then, the rootfs partition was displayed in the file explorer.

then ran fsck:

Code: Select all

sudo fsck.ext4 -f /dev/sdc2

it complained about errors I didn't have time to copy, and it started fixing stuff.
Actually, it put everything in the "lost+found" directory.

Here's the end of the fsck trace:

Code: Select all

Inode 8497 ref count is 2, should be 1.  Fix? yes

Unattached inode 8556
Connect to /lost+found? yes

Inode 8556 ref count is 2, should be 1.  Fix? yes

Unattached inode 8579
Connect to /lost+found? yes

Inode 8579 ref count is 2, should be 1.  Fix? yes

Unattached inode 8583
Connect to /lost+found? yes

Inode 8583 ref count is 2, should be 1.  Fix? yes

Unattached inode 8592
Connect to /lost+found? yes

...


Free blocks count wrong for group #0 (1960, counted=2058).
Fix? yes

Free blocks count wrong for group #1 (1599, counted=2890).
Fix? yes

Free blocks count wrong for group #2 (3736, counted=4784).
Fix? yes

Free blocks count wrong for group #3 (765, counted=1659).
Fix? yes

Free blocks count wrong for group #4 (2335, counted=4833).
Fix? yes

Free blocks count wrong for group #5 (1933, counted=2924).
Fix? yes

...

Free blocks count wrong (14385474, counted=7112693).
Fix? yes

Inode bitmap differences:  -(12--48) -(817--832) -(1361--1408) -(2833--2848) -(5329--5344) -(6705--6720) -(25905--25920) -(33729--33744) -(260145--260176) -(260241--260288) -(260321--260336) -(260385--260400) -(260625--260640) -(261457--261460) -(261462--261472) -(261681--261689) -261692 -261694 -(261696--261697) -(261700--261707) -(268225--268240) -(390162--390167) -(390170--390182) -(390185--390189) -390192 -(390241--390245) -(390248--390251) -(390254--390256) -(390433--390443) -(390445--390447) -390501 -(392241--392256) -(523905--523920) -(524001--524016) -(524049--524064) -(542689--542704) -(542833--542848) -(543105--543120) -(650273--650288) -(650449--650451) -(650454--650455) -650929 -650940 -(650945--650947) -(650953--650954) -(650956--650958) -651548 -(651551--651552) -(910369--910384) -(910497--910512) -(922033--922048) -922441 -(923058--923059) -(923066--923067) -(1170449--1170464) -(1170497--1170512) -1170915 -(1170917--1170918) -1170920 -1171132 -(1171134--1171136) -1171340
Fix? yes

Free inodes count wrong for group #0 (51, counted=201).
Fix? yes


...


Free inodes count wrong for group #144 (7621, counted=7662).
Fix? yes

Directories count wrong for group #144 (64, counted=45).
Fix? yes

Free inodes count wrong (3740441, counted=3677228).
Fix? yes

Recreate journal? yes

Creating journal (65536 blocks):  Done.

*** journal has been regenerated ***

rootfs: ***** FILESYSTEM WAS MODIFIED *****
rootfs: 175444/3852672 files (1.1% non-contiguous), 8478220/15525376 blocks

remounted the disk and was able to cd lost+found/

so now it lists all the directories that fsck found and it renamed most of them with numerified names.
In some of them I can see files with correct names from the /home directory : )

Code: Select all

drwx------   726 root          root                 61440 Dec 14 11:25  ./
drwxr-xr-x     3 root          root                  4096 Dec 14 11:25  ../
drwxr-xr-x     3 root          root                  4096 Feb 21  2023 '#100'/
drwxr-xr-x     2 root          root                  4096 Feb 21  2023 '#101'/
drwxr-xr-x     2 root          root                  4096 Feb 21  2023 '#102'/
-rwxr-xr-x     1 root          root                  2514 Feb  7  2025 '#10209'*
lrwxrwxrwx     1 root          root                    54 Apr 12  2025 '#10291' -> ../lib/aarch64-linux-gnu/glib-2.0/glib-compile-schemas
drwxr-xr-x     2 root          root                  4096 Aug 18  2019 '#103'/
-rwxr-xr-x     1 root          root              13993904 Jan  1  1970 '#10317'*
-rwxr-xr-x     1 root          root              22260240 Jan  1  1970 '#10323'*

...

Code: Select all

lrwxrwxrwx     1 root          root                     9 Feb 21  2023 '#22540' -> share/man
-rwxr-xr-x     1 root          root                 11541 Jun 10  2021 '#2255'*
lrwxrwxrwx     1 root          root                    27 Feb 21  2023 '#22554' -> /etc/alternatives/arptables*
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22555' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22556' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22557' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    35 Feb 21  2023 '#22558' -> /etc/alternatives/arptables-restore*
lrwxrwxrwx     1 root          root                    32 Feb 21  2023 '#22559' -> /etc/alternatives/arptables-save*
-rwxr-xr-x     1 root          root                   608 Jun 10  2021 '#2256'*
lrwxrwxrwx     1 root          root                     9 Jan  8  2021 '#22566' -> /bin/kmod*
lrwxrwxrwx     1 root          root                     7 Feb 22  2021 '#22567' -> dmsetup
lrwxrwxrwx     1 root          root                     8 Feb  8  2021 '#22568' -> fsck.fat
lrwxrwxrwx     1 root          root                     8 Feb  8  2021 '#22569' -> fatlabel
-rwxr-xr-x     1 root          root                  1719 Jun 10  2021 '#2257'*
lrwxrwxrwx     1 root          root                    26 Feb 21  2023 '#22572' -> /etc/alternatives/ebtables*
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22573' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22574' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    17 Jan 17  2021 '#22575' -> xtables-nft-multi
lrwxrwxrwx     1 root          root                    34 Feb 21  2023 '#22576' -> /etc/alternatives/ebtables-restore*
lrwxrwxrwx     1 root          root                    31 Feb 21  2023 '#22577' -> /etc/alternatives/ebtables-save*

...

Code: Select all

-rwxr-xr-x     1 root          root                    45 Aug 20  2024 '#9848'*
-rwxr-xr-x     1 root          root                    47 Aug 20  2024 '#9849'*
-rwxr-xr-x     1 root          root                    42 Aug 20  2024 '#9850'*
-rwxr-xr-x     1 root          root                 14416 Aug 20  2024 '#9854'*
-rwxr-xr-x     1 root          root                 10320 Aug 20  2024 '#9856'*
-rwxr-xr-x     1 root          root               3546448 Oct 20  2024 '#9869'*
drwxr-xr-x     2 root          root                  4096 Feb 21  2023 '#99'/

So it seems that great parts of the filesystem is "reachable" as fsck is able to find a lot of directories and files even with an inadequate superblock...

And I remember that testdisk was able to list files and directories of some instance of the rootfs partition it found after a deep search I tried... (although that partition instance didn't match the actual partition..)... but the /home folder was listed as empty there :-/

Is there a tool which could explore the filesystem similarly without the superblock? or even better, reconstruct the superblock...?

thanks again for your insight guys : )

[recuperation]

Sorry, you have to do your own research.
If you still have the clone of the sd card you cold clone the clone and test any recovery program that promisses to understand the ext4 file format.

At least you got some stuff recovered.