eMMC will not boot

I also have the same problem. eMMC just arrived today and it can’t boot.
I’ve first tried to boot the eMMC only (it had partitions and everything, just from the box marked AllNet, but didn’t managed to mount any partition) but no HDMI signal - tried few times.

Then I’ve copied uSD to eMMC and still no luck - no access via SSH, no HDMI signal.

While eMMC is inserted, uSD boots ok - no problem with that any time.

Also I’ve noticed that eMMC has two boot partitions (boot0, boot1) which are read-only and empty (only bytes NUL for the whole partitions) and other one “rpmb” which is even not readable (can’t make a copy of it). Now after uSD copy there is only the copy, two boot partitions and rpmb.

@jack can you help us with these?

One of the solutions here is to comment out everything in /etc/fstab file. That was my problem at least. System won’t boot if there are invalid entries. You may want to mount devices later, after system boot.

This is still an issue. Still trying all of the things in the first post. Did I get a bad RockPi ?

I’m not able to boot from my 64GB eMMC, either. Heartbeat flashes on the SBC, but only a solid black HDMI monitor.
uSD boots and runs the same new Debian build, w/no probs. Used Etcher on Windows 10 to flash both.
OTG procedure will only get me into deeper do-do, so I’ll live w/uSD boot for now. Pulling the eMMC will be my last resort, having installed the heatsink w/compound and M.2 adapter.
Don’t understand why the eMMC build can’t be repaired/overwritten under the uSD OS. Someday.

eMMC can be repaired/overwritten under the uSD. Just boot using the uSD, download the image you want to write to the eMMC, uncompress it, and use:

dd if=<name of the image> of=/dev/mmcblk1 bs=1M

Shutdown, take the uSD card out and it should boot from the eMMC.

No way! Life is not that simple.
But, I’ll give it a shot :wink:
Thanks for the tip.

Okay, first question: The download will be debian-arm64.img.gz onto the Rock Pi 4B uSD, running the same build. What tool do I use to uncompress it?

This newbie sincerely appreciates your patience.

I made a mistake in my previous post – eMMC is mmcblk1, not mmcblk0. Make sure you follow the instructions from this one.

You have to open the terminal application. Then go to the directory where the image is (I would guess Downloads, but I might be wrong).

cd Downloads
zcat debian-arm64.img.gz | dd of=/dev/mmcblk1 bs=1M

That’s it. zcat uncompresses the image on the fly and passes it to the dd command which saves it to the eMMC card (/dev/mmcblk1).

Shutdown, remove the uSD card, power the board.

I’ll bet that even I can follow that. (there I go, getting all cocky)

Will return to let you know the outcome. Sure would be nice to overcome this obstacle and get on with some projects.

All the best :slight_smile:

I’m baa-aack. At first, I couldn’t copy the image to the uSD, because of insufficient space on a 32 GB SD? Hmm. But, I managed to mount the 1 TB SSD and copy it there. But, even run as sudo:
“dd: failed to open ‘/dev/mmcblk1’: Permission denied”

mmcblk1 is not mounted and already has 5 partitions, 2 mounted.

I forgot about permissions. :frowning: Do:

sudo su
zcat debian-arm64.img.gz | dd of=/dev/mmcblk1 bs=1M

Or
zcat debian-arm64.img.gz | sudo dd of=/dev/mmcblk1 bs=1M

Also, it is a good idea to unmount the eMMC partitions first.

“No passwd entry for user ‘zcat’”

you probably typed something like
sudo su zcat …

“sudo su” has to be followed by Return, then you’ll be root and type “zcat …”

Got it! Just needed ‘sudo’ prior to both commands.
Let me try a reboot.

Bummer. Just a black monitor & SBC heartbeat.
The partitions are gone from mmcblk1. There are mmcblk1boot0 and mmcblk1boot1 disks, which are 4M & flagged RO 1. There’s also mmcblk1rpmb disk, also 4M flagged RO 0. They were there before running zcat. Should they be there?

At this point, should I start over with fdisk?

First of all, I want to give a shout out to @lucho for holding my hand while teaching me zcat usage.
I found that, after running zcat on the image file, /dev/mmcblk1 no longer had partitions, according to lsblk. But, fdisk -l listed the partitions, but reported pmbr errors. So, fdisk -w repaired the pmbr, with a backup. The partitions re-appeared in lsblk.
But, I noticed that partition #4 was full, so I used fdisk to delete p4 & p5, then recreate them with partition # 4 being twice its original size.
Unfortunately, zcat still trashes the pmbr, so the system hangs during eMMC boot, just after the screen turns totally black, before the mouse pointer appearing.
Boot from uSD and the partitions are missing from lsblk again. And the loop goes on… and the loop goes on…(catchy tune)

Can you try with a different image? It worked well for me with the radxa provided armbian.

You don’t give up, do you? Awesome!
Yes, I’ll download it again. This is the most recent build from Radxa and is also the current uSD source. Wanted to stick with Debian-arm64 build because it works. The Armbian_5.73.190128_Rockpi-4b_Debian_stretch_dev_4.20.0 build didn’t (last week). But stuff happens, including file corruption.
Was planning to try the same process, w/another uSD via USB adapter.

Today I’ll be shopping for counters & wood to build a workbench. So, I’ll resume troubleshooting this evening.

Very grateful for your assistance. :slight_smile:

Thank you, it works.

Much appreciated.

Yes, you nailed it. After switching to the:
rockpi4_debian_stretch_lxde_armhf_20181105_2120-gpt.img
eMMC booted fine.

I notified @O635789 of the issue and (s)he is kindly working on a solution.

Thanks to your assistance, my problem has been solved.
Have a great day!

Sorry to drudge up an older thread, but I’m having similar issues not being able to boot from emmc. I can boot from sd-card just fine and flash both debian and ubuntu image to the emmc. I can see the partitions(*) and data and all on my host computer but it won’t boot on the rock pi.
When having both emmc and sd connected to the rock pi and booting from sd I can also not see any additional mmc* in /dev except the sd-card itself.
Any idea what the issue might be? As a sidenote, is it normal that the emmc chip is only “loosely” connectable to the board? It always feels like it would fall of with a good shake…

* Related perhaps: When opening the emmc device in gparted it tells me Not all of the space available to /dev/mmcblk0 appears to be used, you can fix the GPT to use all of the space (an extra 115589120 blocks) or continue with the current setting? Is that part of the issue? Neither fixing or ignoring this message through gparted resolved anything though.

edit: Nevermind, I’m an idiot. Apparently it was not properly connected. I just had to actually really press the emmc card into the connector for it to ‘click’. This really isn’t for the heavy handed. :slight_smile:

1 Like