My Armbian based Orange Pi webserver crashed (probably because of a power loss). I thought it would be fine since ext4 is more resilient and it usually has been in the past, but for some reason, this time, it didn't reboot, it hung. When I checked, it seems the "drive" (actually a memory-card) "does not have a valid filesystem".

I pulled the card and made a backup image (amounting to ~4.5GB out of the 32GB space on the card) and examined it in a hex-editor and various programs. I also burned an Armbian ISO to an identical memory-card to compare metadata values.

I do have a copy of the system from a couple of years ago on a different (non-identical card), but the server has changed a fair bit since then. Hopefully it can at least provide some more information to compare.


I've noticed several issues:

  • Most programs are unable to detect the card as containing a filesystem. No, fsck, testdisk, etc. don't work, they complain about a bad magic number, or wrong fs type, bad option, bad superblock, or missing codepage, or filesystem seems damaged, or bad relative sector, or other blocking errors.

  • The superblock is damaged (and I couldn't find backups); it looks like most of the entries are okay, but the following definitely have unusual/invalid values. I compared the values of the broken system with the new one, leaving out values like partition size or mount count which will naturally differ. Expected values with a question mark are ones which I'm not sure are specific to the drive or not, that is, I don't know if they're incorrect.

Field Actual value Expected value
Blocks per group 0 32768
Fragments per group 0 32768
inodes per group 5680 ? 8160
Maximal mount count 0x7777 0xffff
Magic signature 0x6753 0xef53
File system state 🤨 ‽‽‽ 0x03 0x00 or 0x01
First inode number 3 ? 11
Compatible features 0x34 ? 0x3c
Incompat features 0x246 ? 0x242
R0 comp features 0x63 ? 0x7b
  • Searching the drive with a hex-editor, I'm able to find various directories and files, but examining it with some programs seems to indicate that at least some inodes seem to be wiped/zeroed out.

  • If I modify some of the superblock values (specifically the …per group values, magic signature, and file system state, then programs can see it, but with the following problems:

    • They still complain about things like it being an invalid filesystem or partition type
    • Some programs can list the root directory, but only show a few subdirectories (bin, boot, dev, lib, lost+found)
    • Contents of displayed directories are incorrect (eg only a few Python files in /boot)
    • Other subdirectories (etc, mnt, …, usr, var) are shown as broken/unknown files instead of directories
    • At least one subdirectory (home) isn't listed at all—though that might be because home is a symlink to somewhere in one of the broken directories 🤔
  • One program's validation routine shows the following problems:

    • Integrity status: invalid
    • inodes count is valid: no
    • SuperSector copy exists and matched: no (is that supposed to be superblock? 🤔)
  • Most programs are showing the root-directory as ' instead of /. 🤨

  • The damaged card has ~300MB of unallocated space after the ~29GB partition. That may or may not have been like that before the corruption. I distinctly recall a Pi setup tutorial saying to run a command to expand the partition to the full size of the drive/card after burning the ISO and booting the first time, but I just can't seem to find the tutorial or command 🤷. When I burned the new card and expanded the partition, it used the the whole card. It does seem like the old version on the old card also has a ~290mb unallocated chunk at the end.

  • Sometimes I get the sense that something was deleting everything on the card, but that doesn't make sense because it wasn't a virus that crashed it, it was a faulty power-supply. 🤨


Here are some resources I have available at my disposal:

  • Original corrupted card with minimal modifications (which I can reverse)
  • Cloned image of corrupted card
  • Previous version of the system from 2019 before it was transferred to a new card (though I can't for the life of me remember if I cloned it to the new card and then updated it or just burned a new ISO from scratch and transferred some files 🤔—I know I started with Jesse, updated to Stretch somehow, and was using Buster before the crash)
  • Another identical memory-card that (should) have identical parameters (eg sector count)
  • Free or trial versions of as many data-recovery and/or forensic programs as I could find (I'd consider purchasing a license to something if it's not too expensive and it'll definitely help restore the server)
  • A WordPress SQL dump from two months before the crash (but it doesn't contain external files like graphics files 🤦)
  • Backups of the etc, home, var/lib/mysql, and var/www directories from a couple of years ago—I could swear I made a more recent backup of at least etc but can't seem to find it anywhere 😕
  • ISOs of various versions of Armbian
  • Various screenshots
  • Unfortunately, I'm not too knowledgeable about ext* (yet; I'm reading up on it now), but I am very familiar with FAT* and have done a lot of data-recovery with that over the years, so hopefully my skills can transfer to this filesystem 🤞
  • I'm happy to provide any other information or answer any other questions needed


Ideally, I'd like to be able to modify a couple of values to fix the filesystem so that it's all fixed like nothing happened, but it looks like that's not going to happen.

As a last resort, I can restore the image from late 2019 and try to manually restore/re-inject the other individual backups, at the risk of possibly losing a couple of years of work.

At a minimum, I need to recover:

  • At least a few things from etc (mostly text files)
  • Any new files in root/home since last version (mostly text files)
  • Any new files in var/www since the last version (mostly graphics files—WITH FILENAMES)
  • Ideally var/lib/mysql (binary files) to avoid losing two months since last SQL dump
  • List of installed packages (where does Linux keep the list? please be a text-file🤞) Remeber, this is offline, so I can't run a command to dump it (though I swear I did recently, but again, I can't seem to find it 🤦)

(You know, looking at it like this, it doesn't seem so disastrous anymore; it feels like time and work but seems doable. 😀)


Is there a way/program that will let me rebuild the directory tree or inode chains? That is, some way to look for directories and files (eg a string/byte search), then fill in the sector/cluster/inode of the start of the item, then have the program rebuild the inode chain based on that and the length of the file/directory?

The card was at least 80% empty and there wasn't too much delete/write activity, so most of the files and directories should be unfragmented, so it should be sufficient for most of them to just know the start and length to be able to restore the directory or copy the whole file.


A regular content-based file-recovery scan isn't going to be of much use since it would just dump a ton of files with no filenames or directory structure, which is useless here since many of the files will be similar and/or binary, and thus very difficult to rename or locate their appropriate directories.

Tangential question

How does the system know if the partition is ext2/ext3/ext4 if they all use the same partition identifier of 83/0x53? I couldn't find another field to identify it it. 🤔

2 Answers 2


The ext2/3/4 filesystems are just different variants of the same filesystem, with newer features being added, so much on the on-disk structure is the same. That is why there is only a single magic value for all three variants of the filesystem. The major new feature in ext3 is has_journal, while ext4 added extents and several other features.

You may consider to download and build the e2fsprogs sources (on a different system/card) to get a copy of the findsuper program. It will do a sector scan of the device looking for the ext2/3/4 magic value in the superblock, regardless of whether the partition table is corrupted or not. This will identify the start offset (in bytes) of the partition where each filesystem is located, which may help you rebuild/recover the partition.

  • The partition itself is fine(-ish? 🤔) It's being detected, but some programs are complaining about invalid states (eg incorrect inode count). I did consider manually searching for other superblocks, but even then, that won't help with the missing inodes. 😕
    – Synetech
    Jun 9, 2021 at 1:00
  • (Also, that doesn't explain how tools differentiate between ext2/3/4. There must be something that distinguishes them that tools can display the appropriate string.)
    – Synetech
    Jun 9, 2021 at 1:21

As discussed ext/ext2/3/4 are very much the same derived from UFS/FFS (see also 1 and 2) they order the data in the same way in terms of inodes, blocks and pointers (indirect blocks etc), which are all common to FFS - the first filesystem for Unix. Linux is a derivative of unix and ext is FFS with some additional features. The linux filesystem API is built into the kernel and is compatible with all versions of ext

In terms of recreating the inode table the core of the filesystem is a list of pointers to blocks containing the data of each file. Without this list the blocks corresponding to each file can only be guessed. Ext4 in particular is good at allocating blocks that are contiguous (it incorporates a 'multiple block allocation' or mballoc feature) so this guess may be fine. But for large files where there may be fragmentation the task becomes difficult and as far as I know there is no known tool that can reconstruct a file from blocks that are fragmented. I would reiterate that ext2 is good at allocating contiguous blocks (blocks of a given file are almost always close together). you may read about the low level structure of ext2/3/4 here. In the case of fragmentation you would have to manually locate the blocks yourself which for a large file would be extremely difficult. Larger files are more likely to be fragmented.

The metadata (the inode corresponding to each file) is as important as the data itself and without the metadata your data can no longer be considered present - even if it is still present unchanged on the disk - strictly speaking there is no ability to reconstruct the blocks in order so a large fragmented file is as good as lost without the inode table

The only options are to use a data carving tool (such as PhotoRec or foremost) alongside your own heuristics of what the data consists of, which may help to reconstruct your files.

Given how important the metadata is and how easy it can be corrupted, you may consider regularly scheduling e2image which allows backup of only metadata - which is a fraction of the size of a full backup. Of course if the filesystem changes after the backup the metadata will become irrelevant

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .