slslsl

Thanks for the reply, I'll consider overlayroot!

Yes, that's right! Since the root directory is already mounted, I did not remount /boot. Instead, I changed the permission of /boot to read-only, or tried to change the permission of the armbianEnv.txt file to read-only. However, this method did not solve the boot failure. If that cannot write to armbianEnv.txt, that may not be able to properly pass boot parameters to the kernel. (When I search my fstab with cat in recovery mode, nothing comes up.) I will try it! Thankyou! Great. If the previous method fails, I will try the overlayroot method. Actually I just fixed boot.cmd now and it solved the boot fail problem. Make a backup file such as armbianEnvDefult.txt that is not accessed during booting, and load it in boot.cmd. In this case, even if the original armbianEnv.txt is damaged, booting does not fail. But I don't think this method is very cool... isn't it? Than I will also try to apply your advice! I really appreciate the advice!!

Oh I see. Thanks for your kind reply!!!!!!!!!!! I took your advice and looked up my /etc/fstab. My root directory is already mounted as read-only as shown below (The file system is not VFAT, but ext4) UUID=XXX-XXX-... / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 Doesn't above apply to the subdirectory /boot? If it is not applicable, can I add the following command to /etc/fstab? UUID=XXX-XXX-... /boot vfat errors=remount-ro 0 1 And I don't really know what the behavior might be different after mounting it like this.... Can you answer this? Thankyou!

Thankyou for the answer! Can Armbian also use overlay boot? Is the result you want to achieve with overlayroot the same as mounting /boot read-only? Also, is it true that commit 600 means data writes occur every 6 seconds, which is enough time to protect the boot system?

Thank you for answer. I have an additional question for you. 1. Is the problem caused by VFAT? I wonder what the reason is. 2. If the /boot directory is mounted as read only, is it correct that all files in the /boot directory become unmodifiable?

Mr. Igor, I'm really sorry, I was in a rush, so I didn't read the rules carefully. Sorry for being rude. Your time will of course be equal to or more expensive than mine. I respect and appreciate the time you give. I would like to know how to recover when I have this boot problem. Even if the problem occurs because the user accidentally cuts the power, we want to recover it on the next boot. Reading your answers, it seems that modifying the boot-related scripts solves the problem. Is that correct? (ex) Edit /boot/boot.cmd... etc.) I apologize once again for any disruption to the forum operation.

I'm really sorry..... My previous post was wrong, but I can't edit it, so I'm writing again. I am using armbian OS. Hello, we contact you with Odroid booting issues. I've confirmed that the problem occurs from the next boot when the board is powered off while the armbian logo is displayed. (It happens with a high probability.) When booting, the following log is displayed and it does not boot. Loading, please wait... starting version 237 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block … done done. Gave up waiting for root device. Common problems: -Boot args (cat /proc/cmdline) -Check rootdelay= (did the system wait long enough?) -Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk1p1 does not exits. Dropping to a shell! BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.2) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs)_ After that, if you try to reboot about 5-6 times, one boot is possible. (This phenomenon does not disappear and continues.) The sd card is not physically damaged. This is because cloning the OS will reboot normally. Another feature is that the Armbian logo does not appear normally after booting problems. When there were no problems booting, the Armbian logo was always displayed. It appears that some file related to booting are crashed on an abnormal shutdown. This is because we found a file that is believed to be the cause. After a few tries I successfully booted from the sd card with this boot problem and checked the /boot/armbianEnv.txt file. And found that the file contents are broken. (The contents are different from normal files.) I got the armbianEnv.txt file from a general sd card that did not have the problem raised in this article, overwritten it, and then booted it, and it was confirmed that it boots normally without any problem. I think this happens if the file writes don't complete properly while boot.cmd is running. Is my guess correct? I've heard that armbianEnv.txt is giving incorrect kernel parameters for the root filesystem root=/dev/mmcblk1p1 if it is corrupted. On the other hand, the kernel recognizes the SD card as /dev/mmcblk0p1, so there is a problem when booting. Has this phenomenon ever been reported? I would like to know the exact cause of this phenomenon and how to fix it or prevent this problem? We are looking for a way to recover if this happens during boot up. For example running script that pass hard coded boot parameter to kernel each boot... Because the product must be used in an environment where it is difficult to restrict users, unexpected power off (whether booting or not) may occur. (However, the system must be restored and operational.) We are considering mass production, so I think this is a very important issue. Thanks in advance for the reply. ------------------------------------------------- Environment of use - board : odroid c4 - power : DC 9V, 0.5A - os : Armbian //uname -a (Linux (none) 5.10.81-meson64 #21.08.6 SMP PREEMPT Mon Nov 22 11:21:41 UTC 2021 aarch64 GNU/Linux) - sdcard : SanDisk Ultra micro 32GB