The main reason I ended up getting the orange pi (3B, to be exact) was because it has an eMMC connector. This means you don’t have to use an SD card for your boot drive, which I’ve had issues with in the past (they aren’t built for the read/write patterns that OS systems require, so they fail fairly often). I also assumed the device would be quite a bit snappier with an SSD (which turned out to be true).

However, it ended up being trickier than I thought to get the OS on the eMMC card. tl;dr: you want to use dd to copy the .img file to the emmc after bootstrapping the system with a SD card with the OS image.

nand-sata-install Doesn’t Work on Ubuntu

I tried using a magic command (also recommended by this video) which is basically undocumented nand-sata-install to move the current SD filesystem over to the eMMC card. This ran but was did not work for me even though it was "successful". It didn’t seem to copy over the partitions on the original card properly. I think this is because it’s an armbian-specific command, and I’m running an Ubuntu server on my orange pi. But, it was hard to tell.

dd On a Running Boot Disk Isn’t a Great Idea

Next, I figured it was worth a shot doing a low-level disk duplication command to copy all of the data from the current boot drive over to the eMMC card. Maybe the sata script just had a ubuntu-specific bug?

I tried running this command:

sudo dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=4M status=progress

• dd = disk duplicator. It’s a low-level command to copy a device byte for byte.
• if == from
• of == to
• The references are to "root" devices, i.e. not partitions
• bs = blocksize. Increasing this (from the default) can speed up the operation
• dd will copy the entire disk, even the parts which are empty. This means the operation can take a decent amount of time to complete, even if most of your disk on the SD card is not used.
• This also means all partitions, including the partition map, will be copied.
• sudo fdisk -l is the best view of all connected storage devices to the drive to figure out which values to use for the params.

After running dd I got the following error when running fdisk -l:

Disk /dev/mmcblk1: 14.84 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 88A7BE5C-EC7C-6A45-87A9-DAC3CC0C5C47

Device           Start      End  Sectors  Size Type
/dev/mmcblk1p1   61440  2158591  2097152    1G Linux extended boot
/dev/mmcblk1p2 2158592 30801919 28643328 13.7G Linux filesystem
GPT PMBR size mismatch (31116287 != 488554495) will be corrected by write.
The backup GPT table is not on the end of the device.

I didn’t think much of it and just restarted the device. Not a good idea. I’m not sure exactly what happened but I’m guessing what happened was the uuid of the drive was cloned with dd which caused some weird behavior when I restarted the device, which caused both drives (SD and emmc) to break. I also learned that the partition map is cloned exactly as is: the partition is not resized to fit the available size on the disk.

In attempt to not lose the data on the eMMC disk (since I had already wiped the SD card to reboot the device) here’s what I tried:

• ls -l /dev/disk/by-uuid/ get /dev/ references from UUID
• Update /etc/fstab to use /dev references instead of UUID so when I plugged the eMMC back in it didn’t conflict with the SD card.
• sudo reboot --reboot to make sure the system still booted
• sudo shutdown now and then install the emmc back on the board
• Power the board back on (there’s a little button next to the red light you can use)
• sudo fdisk -l now shows the emmc drive.
  • I attempted to check it with fsck -t ext4 /dev/mmcblk0 and it gave me an error. I learned that fsck requires a partition reference, not the root device.
  • The boot drive had an error (log below). I tried fixing it, removing the SD card, and rebooting but this did not fix the issue. I tried both not fixing the "boot sector" issue and resolving it.

orangepi@orangepi3b:~$ sudo fsck /dev/mmcblk0p1
fsck from util-linux 2.37.2
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 3
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 1

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 1
/dev/mmcblk0p1: 233 files, 31235/261627 clusters

• As recommended here I installed gparted (sudo apt-get install gparted) and then realized this was a GUI command. The CLI version is resizepart which is included, but didn’t work for me. I ended up using sudo fdisk /dev/mmcblk0 to delete the partition (which does not delete the data) and then recreate the new partition with the new size. The run sudo resize2fs /dev/mmcblk0p2 which now properly reports the correct size when running sudo fdisk -l
• This still did not fix the issue, so I gave up and just decided to attempt to burn the img directly to the emmc.

Here’s what I learned:

• Copying a hot booted disk via dd will use the same uuid of the disk, which is problematic.
• Partitions are not automatically adjusted, which creates more manual effort.
• Additionally, there seems to be issues with the boot drive (~1G) that I could not resolve.

Copying OS .img to the eMMC Card is The Way

After discovering that Balena Etcher does not run on ubuntu ARM, I found this guide:

• Wipe the disk sudo dd bs=1M if=/dev/zero of=/dev/mmcblk0 count=1000 status=progress && sudo sync
• Copy image to orangepi scp ~/Downloads/Orangepi3b_1.0.4_ubuntu_jammy_server_linux5.10.160/Orangepi3b_1.0.4_ubuntu_jammy_server_linux5.10.160.img orangepi@192.168.7.32:~/ubuntu.img
• Copy it to the emmc drive `sudo dd bs=1M if=./ubuntu.img of=/dev/mmcblk0 status=progress
• I checked fdisk -l and it only showed a ~3G partition size. I went ahead and removed the SD card and rebooted the machine. It booted! And the disk resized.

If you have an orange pi, are using ubuntu, this is the way to setup the eMMC card.