1 1
rhmr

Tinkerboard S eMMC enumeration causes dropping to shell during startup

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?

Share this post


Link to post
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.

Share this post


Link to post
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?

 

Share this post


Link to post
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 :)

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1