How to Find an EXT4 Partition...

So you have a partition table that's a little unorthodox, and maybe is a mix between some NTFS partitions and an extended partition with Linux parts in it.  And one day you get the bright idea to nuke that extended partition because it's a user workstation and they only need Windows.  (And yes, in your heart of hearts you want nothing more for them to be in LinuxLand, but alas too many software vendors have still not joined the ranks...)

Then the shit hits the fan, and you realize you need that partition back.

And you have no idea where the hell it was, other than that it was on the latter half of the disk.

This happened to me, and I fiddled around until I found it, roughly.  This isn't a perfect guide, but might help someone on their way down a similar adventure.  Let's do it constructively.  First, we'll create an image to test with:

dd if=/dev/zero of=test.img bs=1M count=500

There we now have a 500 meg image file to play with.  We can fdisk it directly if we want:

fdisk test.img

I created two partitions, just for kicks, but one would be enough.  By default, fdisk creates the first partition 1M into the disk, leaving plenty of space for boot loaders and the like.  Thus...

Now, to create the file system so that we have something to find, you need to be a little careful with losetup.  Simply mounting the whole file with losetup won't give you the partitions, or at least it didn't for me.  So I did this (using the values for the first partition as show in the image above, meaning your precise command line may vary):

losetup -o $[ 2048 * 512 ] --sizelimit $[ 204800 * 1024 ] -f test.img

Note that the sector locations (start and end) are in 512-byte sectors, whereas the Blocks are listed in Kbytes.  Thus the 1024 multiplier for the size limit.  Subtracting the start sector from the end sector and multiplying by 512 should give the same answer.

Create the file system:

mkfs.ext4 /dev/loop0

(Or whatever device was assigned, remember to use losetup -a when in doubt.)

Let's unmount the device and remount the whole file now:

losetup -d /dev/loop0

losetup -f test.img

We now have a device, with a mystery partition on it.   Actually since the partition table is intact, we could easily access it...so let's really screw the goose:

dd if=/dev/zero of=test.img bs=512 count=2

That takes care of two sectors, one of which that was holding the original partition information.  We can now begin an attempt to mount:

for X in {0..2049}; do echo $X; mount -oloop,ro,offset=$[ 512 * $X ] \

   /dev/loop0 /mnt 2>/dev/null && break; done

Now, in this example we have a very good idea where to look.  In the real case where this effort was required, I had to recreate a primary partition to take the place of the extended partition (since I couldn't scan through the extended partition directly), and hope to run across it within the first few megs.  To obviate the endless output of errors, and to give myself some feedback on how far into the disk I was, I added the echo and the 2>/dev/null pieces.  I am mounting as a loop device, since loop supports the offset option, and am mounting read-only.  This way nothing bad should happen even if we run across other data that suggests another file system where it shouldn't be.  The loop breaks as soon as a successful mount occurs.

The loop breaks after spitting out sector # 2048, as it should.  The mount succeeds, and issuing a mount command reports that the device is in fact mounted and available.  Looking in /mnt shows us that there is a file system there.  If we want, we can remount with the correct offset, in read-write, and dump data into the test image.

If you are worried about mounting the wrong kind of file system (maybe it was an old, dirty disk that used to house other things, like an NTFS file system that never got zeroed out), you can limit mount's scope by just adding -t ext4, or even specifying multiples like -t ext2,ext3,ext4 ...


If you have the rough sector location, you don't necessarily need to create a partition; you could just scan through the raw device (like I'm doing with the loop0 device above).  By changing the start and end sector numbers in the for loop, you can look on any location of the disk.

So, why go through all this trouble?  Well, so far as I can tell from the limited reading I've done, EXT has no magic signature.  You can tell if you're looking at NTFS because the first sector has a huge NTFS label in the byte data, and xxd will show you this.  But EXT doesn't (again, so far as I can tell). 

The least you can definitively know about it is that its first important data is 1024 bytes into the partition, and that data will be the first superblock with all its superblock-ness.  It's a cryptic mash of bits, and does not suggest anything remotely about it being a file system of its own.

The most you might be fortunate enough to locate is a volume label, in that same superblock, if the volume was even equipped with one.  But luckily, thanks to this tutorial, you need neither.  You can scan away and find each and every buried and fossilized file system that mount can mount, no partition table required.

So there ya go!  Now when you need to "Find ext4 partition" that you lost, and you are tired of all the search results telling you how to find out sizes, and inode counts, and tuning options, and you just want the damned file system, now you know.