Armbian unbootable after update from 20.04 to (presumably) 20.04.1

#1

I just installed Armbian for the first time on a Rock 4 Plus, getting it from here:

https://wiki.radxa.com/Rock4/downloads

and immediately was asked to upgrade to 20.04.1. When I told it to do so, the window just disappeared.

So I manually ran “sudo do-release-upgrade”.

Now I’m just seeing “U-Boot” on the upper right corner of the screen. The keyboard is unresponsive (no USB recovery mode, apparently).

I mean, I know I can wipe it and restart, but…

A. Are there official images somewhere that aren’t more than two years out of date? (Never mind. I found them by starting from armbian’s website. Maybe the wiki should link there instead of providing links to particular versions that will go stale quickly?)
B. Does anybody have any idea why installing an update like that would completely brick booting to the point where wiping everything is necessary?
C. Is there some way to expose Rock Pi’s internal eMMC as a mountable USB mass storage device so that it would be easier to diagnose these problems?

For now, I’m going to copy data from the eMMC to a file on disk (I assume 64 GB is actually 134217728 sectors) and wipe it and install 22.x, but it would be nice to have a better option in the future. Thoughts?

#2

Possibly related. After reinstalling, while resizing the filesystem, I saw a giant pile of hundreds of I/O errors:

I/O error, dev mmcblk1, sector xxxxxx op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0

for various values of xxxxxx, or rather dozens of them with 199 and 204 callbacks suppressed between groups.

It’s unclear whether this is a real error message or a kernel bug, as apparently somehow I ended up with what turned out to be an unsupported beta build of Armbian (Armbian_22.11.0-trunk_Rockpi-4bplus_jammy_edge_5.19.5). bangs head against wall

It claims to have only 0x733c000 (120832000) blocks, which is about 57 gibibytes or 61.8 gigabytes, which is way short of the expected 64 GB capacity no matter how you’re counting. That, combined with the I/O errors while zeroing pages, makes me wonder if there’s something wrong with this hardware. This is a brand new board, and I really don’t want to be stuck with it if the eMMC is failing. Thoughts?

#3

Well, a dd from /dec/mmcblk1 to /dev/zero read 120832000 records with no errors, which matches the number from the mmc tool. I’m unsure whether this capacity is caused by something not actually working or by the eMMC vendor reserving space for sparing bad flash pages and taking that out from the published capacity rather than adding it to the published capacity. I’m going to wipe one more time and install 22.08.1, which is a stable release, and see what happens.

#4

Never mind. After the third install, it booted exactly once, and dropped to initramfs on the second boot, indicating that the eMMC device could not be found. At this point, it’s pretty clear that the on-board eMMC is toast. I’m returning it for replacement.