kernel update後にVPSが起動しないときの復旧方法

VPS が kernel update 後に起動しない場合の最初の対応

kernel update 後に起動しない VPS でも、通常は数分で復旧できます。update によって、昨日まで動作していた kernel まで削除されることはないためです。Ubuntu は新しい kernel を古い kernel と並べてインストールし、GRUB がデフォルトで起動するエントリだけを変更します。したがって、最初に行うのは修復ではありません。boot menu で以前の kernel を選択し、login prompt に戻してから、稼働中のシステムで原因を調べます。

server での対応は、laptop の修復とは異なります。keyboard は接続されておらず、panic の画面を表示する monitor もないためです。マシンが sshd の起動に到達していないため、SSH にも応答しません。以下の操作はすべて、provider の console から行います。

変更を加える前に、自分の console を確認してください。画面に表示された内容によって、該当する障害の種類が決まります。「起動しない」状態が同じ 2 台の server でも、必要な対処が正反対になることがあります。

SSH が停止した場合にコンソールへ接続する方法

プロバイダーのコントロールパネルを開き、コンソールを探します。一般的な名称は VNC console、web console、noVNC、serial console です。両方が利用できる場合は serial console を優先します。実際のテキストを表示でき、スクロールやコピーも可能だからです。VNC は画面の画像を表示するだけです。マシンが正常なうちにこの機能を探し、開けることを確認します。障害発生中に探すと、必要な冷静さが失われます。この確認は、ファイアウォールルールや SSH keys と合わせて、新しい VPS で最初の 10 分間に行う作業に含めます。

多くのパネルには rescue mode または recovery image もあります。これはプロバイダーのネットワークから小さなシステムを起動し、ディスクを追加デバイスとして接続します。そのため、ディスク上のシステムは実行されません。GRUB 自体が壊れている場合は rescue mode が代替手段になります。また、復旧を断念したサーバーからデータをコピーする場合にも使用します。

ログインできないマシンでは sudo reboot を実行できないため、通常はパネルからハードリセットを実行して boot menu に入る必要があります。ハードリセットは電源を切断することと同じです。ファイルシステムは正常にシャットダウンされないため、次回の起動時にファイルシステムチェックが実行されることを想定してください。

GRUB メニューで古いカーネルを選択するにはどうすればよいですか？

リセットを押した直後からコンソールを監視します。最初の数秒間に Esc を繰り返し押してください。legacy BIOS モードで起動するマシンでは、Shift を押したままにします。選択できる時間は短く、コンソールビューアーの接続には通常 1 秒ほどかかります。そのため、早めに押し始め、押し続けてください。

メニューが表示されたら、「Advanced options for Ubuntu」を選択します。このサブメニューには、インストールされているすべてのカーネルが新しい順に表示されます。各カーネルには recovery mode の項目もあります。通常モードの 2 番目の項目、つまり最新の 1 つ下のカーネルを選択し、Enter を押します。recovery mode は別の機能です。最小構成の single user system で起動するため、修復作業用であり、サービスを再びオンラインにするためのものではありません。

古いカーネルで起動できれば、サーバーは再び稼働しています。現在使用しているカーネルを確認し、番号を記録してください。

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

dpkg の出力には、インストールされているカーネルの一覧が表示されます。1 行しかない場合は、フォールバック用のカーネルがまったくありません。まずこれを修正する必要があります。

GRUB メニューが表示されません。どうすればよいですか？

クラウドイメージには、メニューを非表示にする設定が含まれています。Ubuntu イメージでは、/etc/default/grub.d/ 配下のファイルでタイムアウトが 0 に設定されていることが一般的です。そのため、最新のカーネルがすぐに起動し、押すべきキーもありません。

逆のケースもあります。メニューが画面に表示されたまま待機し、ハングしたように見える場合です。GRUB は起動失敗を記録し、次回の起動時にキーが押されるまでメニューを開いたままにすることがあります。キーボードのないサーバーでは、この待機が終わりません。コンソールにメニューが表示され、何も進まない場合は、この状態です。エントリを選択して続行してください。

サーバーが正常に動作している間に、両方の問題を修正してください。/etc/default/grub を編集します。

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

次に設定を適用し、編集内容が保持されていることを確認してください。/etc/default/grub.d/ 内のファイルは /etc/default/grub の後に読み込まれるため、設定が上書きされることがあります。

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" により、メニューがグラフィカルコンソールとシリアルポートの両方に表示されます。そのため、パネルが提供するどのビューアーからでも確認できます。console= のカーネル引数は、続いて表示される起動メッセージにも同じ設定を適用します。起動ごとに 10 秒待つだけで、2am でも実際にアクセスできるメニューを確保できます。

確認しているのはどの障害クラスですか？

コンソールの表示が止まる直前の20行を確認します。カーネル更新後に発生する問題の大半は、次の4パターンに分類できます。

GRUB が自身のファイルを見つけられない。 grub rescue> プロンプトが表示されるか、存在しないパーティションまたはファイルに関するエラーが表示され、カーネルメッセージが一度も出ません。この時点では、まだカーネルは関与していません。これは通常、カーネルパッケージ単体ではなく、ディスクやパーティションの変更、またはブートローダーを誤ったデバイスに書き込んだことが原因です。

カーネルは起動するが、root をマウントできない。 カーネルメッセージが流れた後、プロンプトが (initramfs) と表示される busybox シェルに移行するか、root ファイルシステムをマウントできないという panic で起動が終了します。カーネル自体は読み込まれています。実際の root ファイルシステムを検出してマウントする小さな一時 root である initramfs が、ディスクを検出できていません。Ubuntu では通常、このシェルに移行する前に root device の待機を断念したというメッセージが表示され、必要としていた UUID も示されます。その UUID をコピーし、後で blkid の出力と比較します。

論理ボリュームが表示されない。 これは前のクラスに属し、原因が1つに限定されたケースです。(initramfs) プロンプトで ls /dev/mapper を実行します。表示される項目が control だけなら、LVM (logical volume manager) のボリュームが有効化されていないため、root device がまだ存在していません。次のコマンドでボリュームグループを手動で起動します。

lvm vgchange -ay
ls /dev/mapper
exit

exit により initramfs スクリプトへ制御が戻り、マウントが再試行されます。その後システムが起動する場合、新しい initramfs に LVM の構成要素が含まれていません。修復するには、カーネルに手を加えるのではなく、そのイメージを再構築します。

Linux からの表示がまったくない。 コンソールにファームウェアのテキスト、UEFI (unified extensible firmware interface) シェル、カーネル出力のない空白画面、または再起動ループが表示されます。障害は Linux の起動前に発生しています。多くの VPS インスタンスは legacy BIOS モードで起動し、EFI パスをまったく使用しないため、復旧後にサーバーが実際に使用しているモードを確認します。

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

アップグレード中に /boot/efi がマウントされていないことは、UEFI マシンでよくある原因です。この場合、EFI system partition を管理するパッケージが、通常の空のディレクトリに書き込んでしまいます。ファームウェアは、ディスク上の内容と一致しなくなるまで、古い boot entry の起動を続けます。

もう1つのパターンは、そもそもブート障害ではありません。root シェルに到達し、システムが emergency mode であると表示される場合、カーネルは起動済みで、userspace が停止しています。通常は /etc/fstab の不正な行、またはチェックに失敗したファイルシステムが原因です。そのシェルで journalctl -xb を実行し、失敗した unit の名前を確認します。

カーネルパッケージが壊れているのか、それとも initramfs が壊れているのか

コンソール上ではこの2つが同じように見えますが、必要な修復方法は異なります。古いカーネルで起動してから、ファイルを比較します。

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

インストール済みの各バージョンについて、サイズが妥当な vmlinuz- と、それに対応する initrd.img- が1つずつ必要です。initrd が存在しない場合や、他のバージョンより大幅に小さい場合は、initramfs の生成に失敗しています。通常の原因は /boot が満杯になっていることです。根拠はパッケージログに残っています。

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log には、直近の処理でインストールされたパッケージと、その時刻も正確に記録されています。これにより、何が変更されたかを確認できます。

/boot が満杯の場合は、まず空き容量を確保します。次に、必要なバージョン用のイメージを再生成し、メニューを更新します。バージョン文字列には、実際の ls の出力に表示される値を使用してください。下のプレースホルダーは実在するリリースではありません。

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

最後の ls が確認結果です。通常のサイズのファイルがあれば、イメージは存在します。一方、カーネルイメージ自体が破損している場合や、dpkg -l でパッケージの状態が ii 以外の場合は、パッケージを再インストールします。

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

レスキューモードで、どのカーネルでも起動しない場合に修復する

メニュー内のすべてのエントリで起動に失敗する場合は、プロバイダーのレスキューイメージを起動し、外部からディスクを修復します。ディスクは未マウントのデバイスとして認識されるため、ディスク上では何も実行されず、修復作業を妨げるプロセスもありません。

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

新しい kernel を次回の起動だけ試す

GRUB は、1 つのエントリを 1 回だけ起動し、その後に選択したデフォルトへ戻せます。デフォルトを信頼できる kernel に設定し、新しい kernel を 1 回だけ起動します。失敗した場合は、パネルからハードリセットすれば、コンソールの操作タイミングを合わせなくても正常な kernel に戻せます。

/etc/default/grub で GRUB_DEFAULT=saved を設定し、sudo update-grub を実行します。次に、エントリのタイトルを一覧表示し、1 つを正確に指定できるようにします。

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list の出力には、選択したタイトルが saved_entry として表示されます。この出力は、この仕組みが機能することの証明です。保存には書き込み可能な /boot/grub/grubenv が必要ですが、一部のレイアウトでは利用できない状態でもエラーが表示されないためです。エントリ 0 はメニューの先頭であり、最新の kernel です。ここでは番号よりタイトルのほうが安全です。kernel をインストールまたは削除するたびに番号が変わるためです。

ヘッドレスサーバーで autoremove が危険な理由

APT には、自動的に削除してはならないカーネルパッケージの一覧があります。次のコマンドで確認します。

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

このファイルは、カーネルパッケージが変更されるたびに再生成され、実行中のカーネルと直近のカーネルを保護します。問題は実行するタイミングです。新しいカーネルで再起動した直後に sudo apt autoremove --purge を実行すると、保護対象の一覧もすでに更新されています。そのため、頼りにしていた古いカーネルが保護対象から外れます。キーボードを接続できるマシンなら不便で済みます。しかしヘッドレスサーバーでは、メニュー項目を選択できるか、レスキューイメージからディスクをマウントすることになるかの違いです。

カーネルは最低2つ残し、/boot に余裕がある場合は3つ残してください。uname -r を確認してから、古いカーネルを名前で削除します。これにより、実行中のカーネルを削除できなくなります。

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

その後、最後のコマンドをもう一度実行してください。数が3から2になるのはクリーンアップです。数が1になるのは、次回の再起動で障害になる状態です。

アップグレード前にスナップショットを取得する

apt upgradeの前に取得したスナップショットは、何も起動せずに復旧できる唯一の手段です。スナップショットを復元すると、ディスクは旧カーネルがデフォルトだった状態に戻ります。そのため、コンソールを開いたままアップグレードを再試行できます。稼働中のマシンのスナップショットはクラッシュ整合性を持ちます。これは、電源を突然切断した場合と同じ状態でディスクを取得するという意味です。そのため、プロバイダーがオフラインスナップショットに対応している場合は、先にサーバーを停止してください。スナップショットは通常、コピー元のボリュームと同じ基盤上に保存されるため、バックアップでもありません。VPS スナップショットと実際のバックアップの違いを理解しておくことが、障害がカーネルの範囲を超えたときにどちらが復旧に役立つかを左右します。

これは、カーネル、initramfs ツール、ブートローダー、GRUB 設定が 1 回の処理で変更されるリリースアップグレードで特に重要です。スナップショットは、前日の夜ではなく、Ubuntu 24.04 から 26.04 へのアップグレードを開始する直前に取得してください。そうすれば、復元ポイントがこれから変更するマシンの状態と一致します。

カーネルパッケージに対する unattended-upgrades の動作

Ubuntu の unattended-upgrades は確認なしでセキュリティ更新をインストールします。カーネルパッケージも、ほかのパッケージと同様に security pocket から提供されます。ここから2つの結果が生じます。

1つ目は、新しいカーネルがインストールされても、実行中にはならないことです。カーネルはブート時にのみ有効になります。/var/run/reboot-required ファイルが作成され、/var/run/reboot-required.pkgs に再起動を要求したものが記録されます。ただし、/etc/apt/apt.conf.d/50unattended-upgrades で Unattended-Upgrade::Automatic-Reboot を有効にしていない限り、何も再起動しません。

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

2つ目は、その空白期間によって原因が隠れることです。サーバーが3月にカーネルをインストールし、まったく別の理由で6月に再起動した後、起動に失敗することがあります。ブートを壊した変更は3か月前のものなので、その日に行った作業を調べても原因は分かりません。現在起動に失敗しているカーネルをインストールした実行履歴は、/var/log/apt/history.log で確認できます。

コンソールを開いた状態で、都合のよい日に意図的に再起動してください。この習慣だけで、原因不明の障害を2分間のメニュー選択に変えられます。予期しない再起動を避けつつ自動化したい場合は、自動インストールを有効にし、自動再起動を無効にしてください。正確な設定方法は、Ubuntu で unattended-upgrades を設定する方法 を参照してください。sudo apt-mark hold linux-image-generic でカーネルパッケージを保留すると、カーネルパッケージの更新自体が完全に停止し、同時にカーネルのセキュリティ修正も停止します。そのため、これは安全対策ではなく、意図的に選択したトレードオフとして扱ってください。

FAQ

キーボードなしの VPS で古い kernel を起動するにはどうすればよいですか？

プロバイダーのコンソール（VNC または serial）を開き、control panel からハードリセットを実行します。通常の手順で再起動するためにログインできないためです。マシンの再起動中に Esc を繰り返し押すか、legacy BIOS boot の場合は Shift を押し続けて、GRUB menu を表示させます。「Advanced options for Ubuntu」を選択し、最新の kernel の下にあるエントリを選びます。login prompt が表示されたら、uname -r を実行して使用中の kernel を確認し、dpkg -l 'linux-image-*' でインストール済みの他の kernel を確認します。システムが再び稼働してから診断してください。

VPS に GRUB menu がまったく表示されないのはなぜですか？

Cloud image では、/etc/default/grub.d/ 配下のファイルで GRUB timeout が 0 に設定されていることがよくあります。そのため、何も操作しなくても最新の kernel が起動します。/etc/default/grub で GRUB_TIMEOUT=10 と GRUB_TIMEOUT_STYLE=menu を設定し、menu が serial console にも表示されるように GRUB_TERMINAL="console serial" を追加してから、sudo update-grub を実行します。grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ で確認してください。この directory 内のファイルは main file の後に読み込まれるため、変更内容が上書きされる可能性があります。

/boot の容量を確保するために古い kernel を削除すべきですか？

最も古い kernel を削除し、少なくとも2つは残してください。/boot が満杯になると、それ自体が障害の原因になります。initramfs の生成に失敗し、動作する image のない kernel だけが残るためです。uname -r を確認してから、正確な package name を指定して purge します。これにより、実行中の kernel が削除候補になることを防げます。headless machine では、無条件の sudo apt autoremove --purge は避けてください。保護対象 kernel の一覧は kernel の変更ごとに再生成されるため、実行のタイミングが悪いと、kernel が1つだけになり、menu に fallback entry がなくなる可能性があります。

unattended-upgrades によって boot に問題が起きることはありますか？

boot に失敗する kernel がインストールされることはあります。ただし、/etc/apt/apt.conf.d/50unattended-upgrades で Unattended-Upgrade::Automatic-Reboot が true に設定されていない限り、マシンは再起動しません。よくあるのは、遅れて発生する障害です。自動実行中に kernel がインストールされ、/var/run/reboot-required が表示されますが、問題が表面化するのは数週間後の次回再起動時です。あらかじめ console を開いた状態で意図的に再起動し、/var/log/apt/history.log を読んで、現在起動している kernel をインストールした実行を特定してください。