カーネルクラッシュ:カーネルパニックとその後の対処
マシンが起動せず画面にカーネルメッセージが表示されたままになる場合の対処方法を説明します。エラーテキストの取得、カーネルのロールバック、リカバリディスクからのfstabの修正手順を扱います。
更新日 2026年8月23日
カーネルパニックとは、カーネルが停止して処理を続行できなくなった状態です。マシンは SSH やネットワークに応答しませんが、実行中として表示され続けます。トラブルシューティングに必要なものはすべてコントロールパネルから利用できます。コンソールには全画面が表示され、リカバリディスクを使えばシステムファイルにアクセスできます。
ステップ1. メッセージを確認する
/hosting/vds/m/<id> の「コンソール」タブ、「画面」ビュー(VNC)を開きます。テキストコンソールにもカーネルの出力は表示されますが、パニックはグラフィカルバッファに描画されることが多く、「画面」のほうが確実に確認できます。重要なのは最初の行ではなく、最も下にある意味のある行で、通常は次のいずれかです。
VFS: Unable to mount root fs on unknown-block(0,0)— カーネルがルートパーティションを見つけられませんでした。Kernel panic - not syncing: Attempted to kill init— プロセス番号1が終了しました。多くの場合、更新の失敗による/sbin/initの破損が原因です。Kernel panic - not syncing: No working init found— 同じ問題です。- スタックトレースを伴うドライバーエラー — 通常はサードパーティ製カーネルモジュールのインストール後に発生します。
すぐに写真を撮るかテキストをコピーしてください。再起動すると画面はクリアされます。
ステップ2. 以前のカーネルを試す
更新直後にパニックが発生した場合、GRUB には古いカーネルが残っています。コントロールパネルからマシンを再起動し、「画面」でメニューを捕まえます。最初の数秒で Shift または Esc を押し、「Advanced options」と以前のバージョンを選択します。
古いカーネルで起動できたら、動作する状態を固定し、新しいパッケージに対処します。
uname -r
dpkg -l | grep linux-image
apt install --reinstall linux-image-amd64
ステップ3. リカバリディスク
ブートローダーのメニューが表示されない場合や、古いカーネルもクラッシュする場合は、「アクセス」タブで「SystemRescue リカバリディスク」起動モードを有効にしてマシンを再起動します。root としてパスワードなしでログインします。マシンのディスクは /dev/sda として表示されます。
lsblk
mount /dev/sda1 /mnt
ls /mnt
破損が疑われる場合はファイルシステムを確認します。
umount /mnt
fsck -f /dev/sda1
手動編集後のパニックの典型的な原因は /etc/fstab のエラーです。存在しないパーティションや誤った UUID を含む行があると起動が停止します。確認します。
blkid /dev/sda1
cat /mnt/etc/fstab
システム内部で作業する場合(カーネルの再インストール、ブートローダーの編集)は、chroot で入ります。
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash
作業が終わったら、必ず「アクセス」タブで通常の起動モードに戻してください。そうしないと、再起動のたびにマシンが SystemRescue で起動し、システムがまったく起動しなかったと勘違いしてしまいます。
ステップ4. 再インストールしたほうが簡単な場合
マシンの自動バックアップや状態スナップショットは用意されていないため、判断はお任せします。ディスク上に貴重なデータがある場合は、まず SystemRescue から scp でご自身のマシンにコピーし、それから「アクセス」タブから OS の再インストールを開始してください。再インストールはディスクを完全に消去します。
手順は、データのコピー、ご自身側で読み取れることの確認、再インストールです。再インストール後に元に戻すことはできません。
繰り返さないために
データのコピーはマシンの外に保管し、カーネルは他のパッケージとは別に更新し、更新後すぐに再起動してください。そうすれば、問題に気づくのは都合のよいタイミングであり、1か月後の不意の再起動時ではありません。通常のサービス障害のトラブルシューティングについては、サービスが起動しない: systemd のトラブルシューティングをご覧ください。