Replacing /dev/sde with the block name of your SD card:
$ sudo dd if=ROCK-5B-Android12-rkr10-20221008-gpt.img of=/dev/sde bs=1048576 oconv=sync
$ sudo gdisk /dev/sde Go to expert mode and replace the protective MBR: it’s only for a 4 gig image, we have a larger piece of media
Command (? for help): x
Expert command (? for help): n
Expert command (? for help): w It sees the secondary header is in the wrong place. Let it move that header.
Warning! Secondary header is placed too early on the disk! Do you want to
correct this problem? (Y/N): y And then let it write the adjusted protective MBR + gpt secondary header
Do you want to proceed? (Y/N): y
$ sudo gdisk /dev/sde Now that the GPT table is fitted to the media, adjust the userdata partition. Delete it and then recreate it, since GPT fdisk doesn’t include a “change end” command
Command (? for help): d
Partition number (1-14): 14
Command (? for help): n
Partition number (14-128, default 14): enter
First sector (34-124704734, default = 8366080) or {±}size{KMGTP}: enter
Last sector (8366080-124704734, default = 124704734) or {±}size{KMGTP}: enter
Hex code or GUID (L to show codes, Enter = 8300): enter
Command (? for help): c
Partition number (1-14): 14
Enter name: userdata
Command (? for help): w And accept the warnings
Do you want to proceed? (Y/N): y
Now create an ext2 filesystem on the new userdata volume
$ sudo mke2fs /dev/sde14
Then take the SD card and toss it into your Rock 5B.
Edit to include: it might take a moment to come up on the first boot: the first round, it seems to boot into recovery, and then it boots into system.
I would imagine so. I did much the same thing through an Android root shell from the SD card boot to the eMMC boot.
There appears to be one catch, and that’s that Android will boot partially from eMMC and partially from SD if both contain an Android style partition table, with Android’s “super” partition on eMMC and userdata on SD.
Thanks for these detailed steps, was really helpfull as I’m not an expert in partitioning from cmd line.
Just a question for last step, when creating ext2 FS on userdata.
Currently my SD is /dev/mmcblk1. After following your steps, I can print from gdisk, the different partitions:
On the Rock5 itself, I’ve noticed the SD is always mmcblk0 and eMMC is always mmcblk1.
In either case, when you wrote the partition table on mmcblk1, did you get a notice indicating that the table may not be in use by the kernel yet? It’s possible that some partition was automounted off of the device, and since the media is busy, Linux won’t re-read the partition table.
Options here:
Reboot the machine. This will typically take care of it, but remember the caveat I mentioned above.
Make sure everything on mmcblk1 is unmounted, then force Linux to re-read the table. This can be done with gdisk again (run gdisk on the media again, then save and exit) or with partprobe (which just informs the kernel that it needs to check the partition table again).
exactly, I just rebooted and can now see the 14 partitions as expectede, seems like it was sync/refresh issue.
gonna run last command and check if android launch
Just rebooted, but for now doesn’t seems android is running. At the beginning can see green/blue leds flashing. After a while blue stays on forever but I don’t see any video output.
Tried unpluggin peripherals like NVMe and wifi card to be sure wasn’t hardware related but didn’t change anything.
Will restart from beginning (redoing previous steps) in case something wrong happened.
2nd attempt: SUCCESS
not sure what happened the first time, now I see android launching as expected.
Thanks a lot for your support, now having Linux on NVMe, and Android on SD
OK so I managed to boot android from eMMC using your method, but I think that (as for other people as well), the HDMI cable needs to be disconnected to boot. Or maybe it just didn’t work at first. I will need to figure it out.
Also, after creating the protective MBR in gdisk I just resized partition 14 in the gnome-disks GUI - no need to remove and recreate it.
Right, I did this entirely through the CLI, never bothered with trying to find GUI tools for it.
As far as HDMI being connected, I haven’t had any issues there: first boot is a recovery boot - probably because the ‘metadata’ partition and such aren’t initialized in the image; from then on, it’s a normal Android startup, with HDMI working at boot time.
do i need to do anything during recovery boot? without anything appear on the screen, i didnt know if it does something. tried press enter multiple time will just make the led stay green.
adb reboot bootloader didnt help too.
OK, I messed around with this for longer than I’d like to admit… :-/
Here is what finally worked for me to get the Android image on SD card booting (make sure it is gpt).
Follow the super helpful steps outlined by Sarah (command line)… then… Android only boots for me if I have Debian installed on an nvme SSD on the Rock5 and then do a reboot from the Debian software… then I get into Android… otherwise it fails to boot. But hey, got into Android!
Not sure if we are speaking about same issue, but I observed boot issues with android (blue led staying on forever).
At first I tought it was a mistake during sdcard setup, but then I saw it booting and failing again on reboot.
Didn’t identify cause yet. Will check if it has something to do with HDMI.
Everything seems to have worked fine for me. The board acts the same as when I run Linux with the blue flashing light, just no video output. Tried waiting a bit before plugging in the HDMI but still no luck. Maybe something is up with the HDMI?
