イベントの古いファイルを削除し、アーカイブで実行されている組み込みターゲットルートファイルシステムに新しいファイルをコピーしてファイルを置き換える単純なアップデータbashスクリプトがあります。このようにして、スクリプトはシステムファイルを更新するだけでなく、プログラムスクリプト自体も更新できます。
mount -o remount,rw /dev/rootfs /mount -o remount,ro /dev/rootfs /最近では、R / W access（）で再マウントし、更新操作を実行し、R / O access（）で再マウントして読み取り専用ファイルシステムを処理するようにスクリプトを拡張しました。
しかし、このアプローチは失敗しました。通常、スクリプトは最初の実行（R / Oアクセスで再インストールする場合）または2回目の実行（R / Wアクセスで再インストールする場合）で失敗します。以下は一般的なエラーメッセージです。
root@device:~# mount -o remount,rw /dev/rootfs /
EXT3-fs (mmcblk0p2): warning: couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead.
mount: mounting /dev/rootfs on / failed: Invalid argument
少し調査した後（例：https://stackoverflow.com/questions/7834667/self-deleting-bash-script）問題は、ファイルシステムから開かれたファイルを削除する方法のメカニズムにあることに気づきました。つまり、呼び出し時にファイルのinodeへのリンクのみが切断され、そのファイルを使用するすべてのプログラムがファイルを閉じると、そのinodeが表すファイルは実際に削除されます。そのため、R/O モードで再マウントすると inode へのリンクが消えますが、inode 自体は消えず、ファイルシステムが破損し、リストされたエラーが発生します。この結論は正しいですか？
今私が興味を持っているのは、この問題を正しく解決する方法です。 R / Oモードで再インストールしてシステムを再起動する必要はありませんか？しかし、R / Oモードで再マウントしてシステムの再起動を防ぐためのより良いソリューションはありますか？
ソリューションはファイルシステムの種類とは無関係でなければなりません。特に私はext3 / ext4とubifsを使用しています。
編集する：個々のサービスを再起動する必要のない一般的なソリューション（システムの把握など）を探しています。システムを再起動することは実際には問題ではなく、アップデートスクリプトを実行する前と同じ状態にシステムを戻すだけで正しいように聞こえます。つまり、ファイルシステムが実行される前にR / Oである場合は、おそらくR / Oである必要があります。その後も。しかし、おそらくそのような前提は無効です。