Jump to content

Tinkerboard S eMMC enumeration causes dropping to shell during startup


rhmr

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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 :)

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines