rg35xx-cfw/Koriki

Fresh 1.0.3 install skips userdata copy/volume expansion step

Opened this issue · 9 comments

mennoliefstingh commented

What happened?

I've been troubleshooting a fresh install using batocera-rg35xx-rg35xx--20240103.img (1.0.3) for a few hours now, until I read that there should be a 'copying userdata' step. This step did not take place when flashed a fresh SD card with Balena on macOS.

I just flashed the 1.0.0 release and now saw the copying/expansion step for the first time; this is also a valid workaround but something that should probably be addressed in a future release.

mennoliefstingh commented

Didn't remember to look for logs (sorry) but I do have a diskutil terminal output that might be relevant:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         494.4 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +494.4 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            9.8 GB     disk3s1
   2:              APFS Snapshot com.apple.os.update-... 9.8 GB     disk3s1s1
   3:                APFS Volume Preboot                 6.1 GB     disk3s2
   4:                APFS Volume Recovery                1.7 GB     disk3s3
   5:                APFS Volume Data                    452.2 GB   disk3s5
   6:                APFS Volume VM                      5.4 GB     disk3s6

/dev/disk4 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *63.9 GB    disk4
   1:             Windows_FAT_32 BATOCERA                3.2 GB     disk4s1
   2:                 Linux_Swap                         536.9 MB   disk4s2
   3:                      Linux                         536.9 MB   disk4s3
                    (free space)                         59.6 GB    -
                   ```
acmeplus commented

The step takes place but it's not displayed on the screen. However that version has an issue with the SHARE partition being formatted in ext4 format. The new v1.0.3.1 update fixes that.

  • ❤️1
Nexus6p commented

It expands on 1.03.1 as far as I can tell, but SHARE partition is still ext4

Al3xJ0bs commented

1.0.3.1 still does not expand the SHARE partition ( Takes up 512 mb) and is still in EXT4 format

  • 👍1
gordoneyal commented

For me too, after the 1.0.3.1 image is flashed, a 512MB EXT4 format SHARE partition apears.
However, when I reformat this partition to FAT32, it expands automatically to 26GB, during first boot.

  • 👍2
Al3xJ0bs commented

For me too, after the 1.0.3.1 image is flashed, a 512MB EXT4 format SHARE partition apears. However, when I reformat this partition to FAT32, it expands automatically to 26GB, during first boot.

It works

manumito commented

For me too, after the 1.0.3.1 image is flashed, a 512MB EXT4 format SHARE partition apears. However, when I reformat this partition to FAT32, it expands automatically to 26GB, during first boot.

It worked for me too.

Dylan96 commented

I just used version 1.0.3.1 and my SHARE partition is still formatted as EXT4
partitions

souporman commented

I just used version 1.0.3.1 and my SHARE partition is still formatted as EXT4 partitions

Yeah, this is a bug, but you can workaround it by manually reformatting that SHARE partition from EXT4 to FAT32 directly after you flash it. After that, pop it in your handheld and boot it up once. It'll expand SHARE and copy over the correct data and you'll be able to see it on Windows to add your games/Bios.