rhmr Posted April 29, 2020 Share Posted April 29, 2020 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 More sharing options...
Igor Posted April 29, 2020 Share Posted April 29, 2020 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 More sharing options...
martinayotte Posted April 29, 2020 Share Posted April 29, 2020 Most probably that the /boot/armbianEnv.txt is corrupted since it is where "rootdev" is set/overwrite the one defined in /boot/boot.scr ... Link to comment Share on other sites More sharing options...
richardk Posted April 29, 2020 Share Posted April 29, 2020 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 More sharing options...
rhmr Posted April 30, 2020 Author Share Posted April 30, 2020 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 More sharing options...
Igor Posted April 30, 2020 Share Posted April 30, 2020 Try removing commit=600 from /etc/fstab Link to comment Share on other sites More sharing options...
rhmr Posted May 6, 2020 Author Share Posted May 6, 2020 My second board that failed had commit=10 in fstab. As far as I know the default is something like 5. Link to comment Share on other sites More sharing options...
Recommended Posts