私はu-bootをブートローダーとして使用し、systemd initシステムを使用して組み込みLinuxを開発しています。これらのツールは標準のbusyboxに制限されています。
いくつかの問題の分析中に、ルートファイルシステムが読み取り専用であり、問題を引き起こすことがわかりました。その理由は、一部のサービスとプログラムが書き込み可能なルートファイルシステムに依存してエラーを引き起こすためです。
いくつかの調査の終わりに、ルートファイルシステムは電源が切れたときにのみ読み取り専用であることがわかりました。 （特定のエラーが発生すると、プライマリデバイスは電源リサイクルをトリガーします。）ルートファイルシステムがいくつかの重要なファイルを書き込んだり、一部のサービス/プロセスのロゴを更新しようとすると、停電時にファイルシステムにエラーが設定されていると思われます。次回の起動時に、fsckはこのフラグを読み取り、ルートを読み取り専用でマウント/再マウントするか、またはfsckがルートをある種の回復モードに強制します（回復モードがあるかどうかはわかりません）。
私の家は正しいですか？もしそうなら、エラーが発生したときにFSに設定されたfsフラグは何ですか？ルートがROで始まるのを防ぐ方法は？
メモ:
ルートファイルシステムは "errors=continue" を使用してマウントされます。したがって、fsckがremountオプションのスーパーブロックを読み取る場合は、エラーを無視してRWに再マウントする必要があります。
ddコマンドを実行しながら電源を切るなど状況を再現してみましたが、一度も再現されませんでした。
追加の質問：どのudev / systemdマジックがルートfsをマウントしますか？
答え1
起動時にファイルシステムを調べて、システムが正常にシャットダウンされたかクラッシュしたかどうかを確認し、後者の場合は必要な回復操作を実行する必要があります。最新のジャーナルファイルシステムでは、これは一般的に自動化できるシンプルで迅速なジャーナルリカバリ操作を意味します。
ルートファイルシステムのチェックとマウントは通常initramfs / initrdによって実行されますが、組み込みシステムには存在する場合と存在しない場合があります。
initramfsを使用しない場合、従来のアプローチはカーネルを使用することです。いつもルートファイルシステムは最初に読み取り専用でマウントされます（起動オプションを使用してroot=/dev/<whatever> ro起動スクリプトがfsck最初に実行されます（使用されているファイルシステムタイプに必要であると仮定））。読み書きモード。
initramfsがルートファイルシステムを検証しない場合（おそらく使用されていないため）、ルートファイルシステムでファイルシステム検証を実行するために使用される標準のsystemdサービス名はで指定されますsystemd-fsck-root.service。確認した結果、systemdを使用してルートファイルシステムを再マウントするサービス名が見つかりませんでした。
ブート時にルートファイルシステムのチェックでルートファイルシステムの変更が必要な場合、修正は通常、カーネルが既に読み取りおよびキャッシュしている内容に影響を与える可能性があるため、ルートファイルシステムが変更された後に変更されるため、後で再起動します。一貫性のない。ディスクはfsck。