Feature request: F and G partitions support.

[rizaumami]

The write capability is amazing, but the lack of F and G partitions support make fatxfs somewhat limited as these partitions are where we store our games.

[GXTX]

Support is already there, you just need to specify offset and size.

[rizaumami]

The problem is, I don't know what offset or size of my disk's partitions are. fdisk -l didn't work as it doesn't know what FATX is. The only thing I cant think of is using XBPartitioner on ogxbox to see disk partitions size.

[mborgerson]

Partitions are hardcoded now, but we can take a look at automatically discovering partition sizes based on how other tools do so

[mborgerson]

Here's xbpartitioner source for reference: https://github.com/opcow/XBpartitioner/blob/main/PartInfo.cpp

[rizaumami]

testdisk can list the ogxbox disk partition. Here is a 1 TB disk with F partition take all the space:

$ sudo testdisk /list /dev/sdc
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org
Please wait...
Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
Sector size:512
Model: TOSHIBA MQ01ABD100

Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition			Start        End    Size in sectors
 1 P FATX                     0  16 17    95 172 13    1536000
     FATX
 2 P FATX                    95 172 14   191  73 10    1536000
     FATX
 3 P FATX                   191  73 11   286 229  7    1536000
     FATX
 4 P FATX                   286 229  8   350 163  5    1024000
     FATX
 5 P FATX                   350 163  6 121601  80 63 1947892144
     FATX

Can I use that info to manually mount the partition?

[GXTX]

That almost looks broken to me. You have 5 partitions by default, what's odd is the size of your last one which should be Z:\ which is a cache partition. But anyway I think that's only checking at the known offsets, hacked kernels don't follow this with custom partitions.

https://github.com/cgsecurity/testdisk/blob/b2a0d41da609e62865beec1ed6faddd12bb5bdb8/src/partxbox.c#L165

[rizaumami]

All the partition is there except E. But if I mount (using --drive or offset/size) it's successfully mounted.

[rizaumami]

CMIIW, the offset for F would be 0x1ddd80000?

$ sudo fatxfs -o allow_other /dev/sdc ogxhdd --offset=0xddd80000 --size=0xe834f36000
failed to initialize the filesystem

Still no dice. But if the offset is correct, all I need to do is to calculate the of F?

EDIT: Found something interesting:

1. https://github.com/ldotsfan/fatx/commit/c4606b48343c202a9f4ad3a7baec3f7afdcdddd7
2. Parsing Of Xbpartitioner Style Partition Table From Linux

[rizaumami]

Found a solution. Based on EatonZ's suggestion, that all I need is to multiply LBAStart and LBASize by 512.

1. Read the first sector (dump disk's partition table)

   dd if=/dev/sdc bs=512 count=1 > ogxboxhdd
   

2. Search for active partition (hex value 0000 8000)

3. Multiply LBAStart and LBASize by 512.

   Below is bash script based on ldotsfan's tip:

   # table header
   printf ' %-12s   %-12s   %-12s\n' "OFFSET (Hex)" "SIZE (Hex)" "SIZE (Dec)" 
   
   while read -r PSTART PEND; do
       # print table
       printf ' %s%-10x | %s%-10x | %-10s\n' 0x $((0x$PSTART * 0x200)) 0x $((0x$PEND * 0x200)) $((0x$PEND * 0x200))
   # get active partision from boot sector dump
   done < <(hexdump ogxboxhdd | awk '/0000 8000/{ print $5 $4" "$7 $6; }')
   

   Result:

    OFFSET (Hex)   SIZE (Hex)     SIZE (Dec)  
    0xabe80000   | 0x1312d6000  | 5120024576
    0x8ca80000   | 0x1f400000   | 524288000 
    0x80000      | 0x2ee00000   | 786432000 
    0x2ee80000   | 0x2ee00000   | 786432000 
    0x5dc80000   | 0x2ee00000   | 786432000 
    0x1dd156000  | 0x7381e30000 | 496100376576
    0x755ef86000 | 0x7381e30000 | 496100376576
   

Now, I can successfully mount F:

sudo ./fatxfs -o allow_other /dev/sdc ogxhdd --offset=0x1dd156000 --size=0x7381e30000

Or G:

sudo ./fatxfs -o allow_other /dev/sdc ogxhdd --offset=0x755ef86000 --size=0x7381e30000

Thanx @mborgerson and @GXTX for the assistance.

[GXTX]

Not all kernels use the "partition table", it's a scene made up thing, some kernels will have hard set offsets for F/G.

[rizaumami]

Ah, yes.
As I've read, the original HDD not using partition table. But stored the hard coded partition offset and size in its BIOS.
The "partition table" rising after XBPartitioner use.

[rizaumami]

#34 add F drive to the mount options. It's F-takes-all disk so won't works on F & G formatted drives. Perhaps give some note/warning in --help text to inform users.