Base Image of mod 2.5 is invalid

[Skeeve]

Please also see #27

The issue is still present in the newest base image, but the solution there didn't work for me.

In fact, it's much easier, but you need to have gdisk installed. Easy done with homebew: brew install gdisk.

1. Flash the uncompressed image to your card. In this example I'm using /dev/rdisk7. Make sure you're using the correct device!

sudo bash
dd if=RG35XXH-V1.1.3-EN16GB-240614-MOD-v2.5.img of=/dev/rdisk7 bs=1m status=progress
sync
 11263803392 bytes (11 GB, 10 GiB) transferred 793.971s, 14 MB/s
10755+0 records in
10755+0 records out
11277434880 bytes transferred in 794.964728 secs (14186082 bytes/sec)

Alternatively Balena Etcher should work as well.

2. Do NOT eject the card! Fix the card with gdisk

gdisk /dev/rdisk7
GPT fdisk (gdisk) version 1.0.9

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk /dev/rdisk7: 62333952 sectors, 29.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): AB6F3888-569A-4926-9668-80941DCB40BC
Partition table holds up to 8 entries
Main partition table begins at sector 2 and ends at sector 3
First usable sector is 4, last usable sector is 125045420
Partitions will be aligned on 2048-sector boundaries
Total free space is 103092905 sectors (49.2 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           73728          204799   64.0 MiB    0700  special
   2          204800          270335   32.0 MiB    0700  boot-resource
   3          270336          303103   16.0 MiB    0700  env
   4          303104          434175   64.0 MiB    0700  boot
   5          434176        17211391   8.0 GiB     0700  rootfs
   6        17211392        22026239   2.3 GiB     0700  UDISK

Enter the commands x, e, and w.

Command (? for help): x

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/rdisk7.
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.

Eject the disk now, plug it into your device and power it on.

Happy gaming.

[JazzJohannes]

Well I guess in speed terms, it depends on whether you use a full 100% HDD still or are already on an SSD (as the old method used the faster internal bus speed rather than the SD Card Reader for editing). But I can see the benefit in your results, yours seems to be formatted correctly file system wise, and also the ROM part is still expandable and not locked, as well as ROMS potentially being above 4 gigs, is that right?

[Skeeve]

No. The #27 simply didn't work. Regarding speed: #27 should be slower as you first create a new image and then flash. So the flashing time in both cases is the same or marginally faster for me because I flash less than #27 does.

But what I'm not sure about is the content of the SD card which might already be there.

So given the fact that the MOD2.5 image is 3615 blocks shorter than the partition table suggests, there might be 3615 bytes of garbage be left on the SD card.

But as I'm no expert in regards to partitions and filesystems, I can only say: It worked for me ;)

[JazzJohannes]

No. The #27 simply didn't work. Regarding speed: #27 should be slower as you first create a new image and then flash. So the flashing time in both cases is the same or marginally faster for me because I flash less than #27 does.

But what I'm not sure about is the content of the SD card which might already be there.

So given the fact that the MOD2.5 image is 3615 blocks shorter than the partition table suggests, there might be 3615 bytes of garbage be left on the SD card.

But as I'm no expert in regards to partitions and filesystems, I can only say: It worked for me ;)

Well write speed is limited on the sd card, so realigning the partition table is also writing twice, but also slow, internal bus speed is always faster and so is using ssd. Hence the comparison of hdd and ssd as thats what is going to limit you.

My suspicion is, that cebpex used a brand new pre-formatted sd card for imaging, that left the dual filesystems in place, he probably even did it on linux instead of either mac or pc.

[Skeeve]

Realigning the partition table is writing two (I think) blocks. Minimal delay.

Creating an empty image first (the /dev/zero part), then overwriting it with the original image will take some time. Time not used when following my solution.

[JazzJohannes]

Well interesting i didnt know thank you, that aligning partitions on flash memory does not shift data around, but it makes sense!

But nevertheless write and read speeds on sd cards is half that of usb 3 even, let alone a fraction of speed of SSDs

[mweicht]

Thank you @Skeeve for these detailed instructions! Can confirm this solution worked for me while others here did not.