Tinkerboard S eMMC enumeration causes dropping to shell during startup

[rhmr]

Hi all,

 

I am using Armbian Bionic on ASUS Tinkerboard S board(s) in an application where the power may fail at any point.

 

I have now, for the second time, seen a running OS starting to fail with the error.

ALERT!  /dev/mmcblk0p1 does not exists. Dropping to a shell!

I have restarted the board several times, but the error continues.

 

If I do a:

(initramfs) blkid
/dev/mmcblk2p1: UUID=....
/dev/mmcblk2: PTUUID=..

 

It seems that the OS tries to boot from the wrong device.

 

If I then, booting from another OS using SD card, change the /boot/boot.cmd rootdev:

setenv rootdev "/dev/mmcblk2p1"

And rerun the mkimage

sudo ../usr/bin/mkimage -C none -A arm -T script -d boot.cmd boot.scr

This fixes the problem..

 

Did anybody else experience this? I have seen it on two distinct boards so far.  I can provide Armbian versions if needed.

How does this device enumeration work, and why does it suddenly change? Could this be due to power failure during boot?

[Igor]

1 hour ago, rhmr said:

where the power may fail at any point.

... which means you have to do something about filesystem. Make it read only, remove all caching, etc. This issue is general, which is why I move this post to general section. And not even specific to Armbian.

[martinayotte]

Most probably that the /boot/armbianEnv.txt is corrupted since it is where "rootdev" is set/overwrite the one defined in /boot/boot.scr ...

[richardk]

I've been investigating a few devices (Rock64, Armbian 19.11.3 "stable") where the first bytes of /boot/armbianEnv.txt gets overwritten with the contents of /etc/logrotate.d/alternatives.  The first time, I concluded it was power-loss-related filesystem corruption.  But, then the exact same thing happened again; the same data overwrites the same place in the same file.  That's when it became a concern.

 

When deployed, these devices will have power protection (UPS, and power loss notification), but during development many have simply lost power.

 

Should I continue to investigate, or should I assume that power protection will solve it?

 

[rhmr]

I agree that filesystems should be mounted read only, but my analysis was that the device enumeration somehow got messed up. I now see that this is wrong. Should I change the topic to avoid further confusion?

 

I can confirm that it in both cases was the armbianEnv.txt that got corrupted. This perfectly explains the issue and why it works updating the boot.cmd.

I can further confirm that I also got data from the logrotate / alternative configuration in my armbianEnv.txt

 

Thanks to all of you for your feedback

 

[Igor]

Try removing commit=600 from /etc/fstab

[rhmr]

My second board that failed had commit=10 in fstab. As far as I know the default is something like 5.