Linuxが起動中に時々フリーズする理由が分かりましたか？initramfsでシステムがbusyboxプロンプトでフリーズしてしまう場合、ディスクまたはファイルシステムに問題がある可能性があります。特に、再起動や基本的なチェックを試しても問題が解決しない場合は、非常に困ったものです。このガイドでは、壊れたスーパーブロックの修復やfstabの修正など、実際の解決策を解説します。そうすれば、頭を悩ませることなくLinuxを再び使えるようになるでしょう。
LinuxがBusyBoxに落ちたときによくある起動問題を解決する方法
fsck による破損したスーパーブロックの修復
Linuxがビジーボックスのプロンプトにクラッシュし、スーパーブロックの破損に関するメッセージが表示される場合、おそらくディスク上のスーパーブロックのコピーが破損しているだけです。これは通常、システムが正常にシャットダウンされなかったか、停電によって重要なデータが失われた場合に発生します。スーパーブロックにはファイルシステムに関する重要な情報が保存されているため、これを修復することでインストール全体を救える可能性があります。
まず、Live CD、レスキューディスク、またはLinuxがインストールされたUSBメモリから起動します。この環境になったら、ターミナルを開きます。目標は、Linuxパーティションを特定し、バックアップスーパーブロックを見つけて修復を試みるコマンドを実行することです。
- 正しいパーティションを見つけるために、ディスクとボリュームを一覧表示してください
# sudo fdisk -l | grep Linux。設定によっては、/dev/vda2のような名前が返されることがあります。これは次の手順で必要になるので覚えておいてください。 - 利用可能なスーパーブロックを確認するには、次のコマンド
# sudo dumpe2fs /dev/vda2 | grep superblockを実行します。バックアップスーパーブロックの場所のリストが表示されます。ほとんどのext4ファイルシステムでは、バックアップオプションとして98304や2064などが表示されます。
バックアップスーパーブロック（プライマリスーパーブロックではありません）を選択してください。通常、98304 で問題なく動作します。次に、次のコマンドを実行します# sudo fsck -b 98304 /dev/vda2 -y。このコマンドは、fsck にそのバックアップスーパーブロックを使用してファイルシステムを修復するよう指示します。
「/dev/vda2 がマウントされています」のようなエラーが表示された場合は、まずマウントを解除してください# sudo umount /dev/vda2。マウントされていないにもかかわらず、マウントされていると表示されることがあるため、注意してください。一部のマシンでは、この魔法の修復後、修復されたファイルシステムをスムーズに読み込むために再起動が必要になる場合があります。
チェックが正常に終了すると、次のようなメッセージが表示されます。
* FILE SYSTEM WAS MODIFIED *修正されたエラーのリストが表示されます。その後、ドライブを完全にアンマウントし、再起動してください。うまくいけば、システムが正常に起動するはずです。
fsck「予期しない不整合」エラーの処理
時々、busybox が表示されるときに と表示されることがあります/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY。これは分かりやすいヒントで、ファイルシステムがクリーンではないことを示しています。通常は、# fsck /dev/sda1 -yプロンプトで と入力してください。その後、プロンプトが再び表示されたら、良い兆候です。再起動してください。すべてがうまくいけば、Linux がすぐに起動するはずです。
なぜそれが機能するのかはわかりませんが、場合によっては、initramfs でこれを行うと、完全な起動を妨げる小さな破損を修正するのに役立ちます。
/dev/volume が存在しない問題への対処
この問題は、/etc/fstabが実際のボリュームまたは UUID と一致しない場合に発生します。通常、USB からインストールし、デバイスの UUID が変更されたか、設定が誤っている場合に発生します。
レスキューモードまたはライブLinuxを起動します。疑わしいディスクを以下の場所にマウントします# sudo mount /dev/sda2 /mnt。次に、/etc/fstabを編集します。
# sudo nano /mnt/etc/fstab（または別のボリュームを参照する）行を見つけ/dev/sda1、正しいUUIDに置き換えます。正しいUUIDはsudo blkidで確認できます。行は以下のようになります。
UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 / ext4 errors=remount-rw 0 1保存して、アンマウントして、再起動します…これで、システムがデバイスが見つからないと文句を言わなくなるはずです。
ハードウェア関連の問題の場合: SATAポートの番号またはUUIDの不一致を修正する
一部の特殊なマザーボードや特定のハードウェア構成では、SATAポートの番号がおかしくなったり変更されたりするため、Linuxはルートデバイスがなくなったと認識することがあります。これを修正するには、grub.cfg を編集する必要があるかもしれません。
緊急モードで起動するか、Live CDを使用して、編集モードで開きます。カーネルコマンドライン（おそらくroot=/dev/sda1/boot/grub/grub.cfg ）がある行を探します。これを/dev/sda1ではなくUUIDに変更します。以下のようになります。
linux /boot/vmlinuz-...root=UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 ro quiet elevator=noop fsck.repair=yesUUIDへの移行により、SATAポートが変更されたり、ドライブの順序が変わったりしても、Linuxは起動時に正しいディスクを見つけられるようになります。完璧な解決策ではありませんが、多くのシステムで起動失敗を防いできた一般的な回避策です。
そしてもちろん、Linux では物事が本来あるべきよりも複雑になりますが、これらの問題を解決するのは不可能ではありません。ただ面倒なだけです。
まとめ
- ライブ メディアから起動して、ファイルシステムを修復するか、UUID の問題を修正します。
dumpe2fsバックアップ スーパーブロックを検索し、fsckスーパーブロック上で実行するために使用します。- 起動エラーを回避するために、正しい UUID を使用して /etc/fstab を確認して修正します。
- ハードウェアの異常が問題になる場合は、grub を編集してデバイス パスから UUID に切り替えます。
まとめ
これらの問題のほとんどは、ファイルシステムの破損やデバイス参照の設定ミスが原因です。修復には、ディスクチェック、設定の編集、そして時にはハードウェアが正常に動作するのを祈るしかありません。1つの修正方法がうまくいかなくても、別の方法で解決できるかもしれません。この情報が、誰かの頭を悩ませる時間やフラストレーションを少しでも軽減してくれることを願っています。念のためお知らせですが、ディスクユーティリティを操作する前に、可能であれば必ずデータをバックアップしてください。そうしないと、問題が発生する可能性があります。