
これはよくあるシナリオです。何らかの理由で、initramfs (OpenSUSE の場合) がルート ファイルシステムを見つけられず、レスキュー シェルに切り替わります。ただし、マウントする必要があるデバイスは完全にわかっています。質問:
ルート ファイルシステムをマウントしてブート シーケンスを続行する正しい手順は何ですか?
おそらくそれがすべてポイントレスキューコンソールの。しかし、これを実際にどのように行うのかを文書化した人は誰もいないようです。
明らかにルートファイルシステムをどこかにマウントすることはできます。しかし、それを根ファイルシステム ツリーの? その後、通常のブート プロセスを続行しますか? (シェルを終了するだけで完了すると思っていましたが、そうではありません)。続行する前にマウントする必要があるものは何ですか? また、どのように続行しますか?
答え1
switch_root /mnt/root /sbin/init を実行します。
答え2
問題の種類によって異なります。問題が initramfs イメージ自体を壊していた場合、問題を解決するには実際にそれを再生成 (update-initramfs を実行) する必要があります。initramfs ファイル システムは RAM ファイル システムであることに注意してください。そのため、問題を解決するには、圧縮された initramfs イメージを修正するか、ルート ファイル システムを修正する必要があります。
不良な crypttab によって壊れたブートを再開するために、LUKS で暗号化された Ubuntu システムで次の手順を使用しました。
まず、パーティションを復号化しました
cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt
はdevice_crypt
ランダムではないことに注意してください。システムのマウント時に通常使用される名前と一致する必要があります (パーティション + _crypt が標準のようです)。
次に、暗号化解除されたパーティション上のボリューム グループをアクティブ化する必要があります。
vgchange -ay
これで、/、/boot、proc、swap などのファイル システムをマウントして、そのように実行してみることができます。
私の場合は、exitと入力するだけで、initramfsは論理ボリュームがそこに存在するのを認識し、問題なく起動を再開しました。その時点で、損傷を修復して実行するのは簡単でした。update-initramfs -u
答え3
fsck
オプションなしでコマンドを実行し、initramfs
再起動するだけです
例: ルートパーティションはsda3
fsck /dev/sda3
答え4
通常の手順は
- /dev/sdX /mnt をマウントします
- /mnt の問題を修正
- リブート
あなたはしたいかもしれない
- /dev/sdX /mnt をマウントします
- /mnt を修正
- アンマウント /mnt
- /dev/sdX/ をマウントします。
- 手動でブートを完了する
これは推奨されません。起動のたびに実行する必要があります。実稼働環境では、手動起動が自動起動と同じ手順に従うとは限りません。
ただし、重要なデータを扱う緊急事態の場合、ステップ 5 は通常、次のようになります。
- 5.1 ネットワークの設定
- 5.2 重要なファイルを安全な場所にコピーする