カーネル更新後にVPSが起動しないときの復旧方法

カーネル更新後に VPS が起動しない場合に最初に行うこと

カーネル更新後に起動しない VPS は、通常、数分で復旧できます。更新によって、前日まで動作していたカーネルまで削除されることはないためです。Ubuntu は新しいカーネルを古いカーネルと並べてインストールし、GRUB がデフォルトで起動するエントリだけを変更します。したがって、最初に修復を行う必要はありません。ブートメニューで以前のカーネルを選択し、ログインプロンプトを表示させてから、稼働中のシステムで原因を調べます。

サーバーでの復旧は、ノート PC での復旧とは異なります。キーボードは接続されておらず、パニック画面を表示するモニターもないためです。マシンが sshd の起動段階まで到達していないため、SSH も応答しません。以下の操作はすべて、プロバイダーのコンソールから行います。

何かを変更する前に、コンソールの表示を確認してください。その画面の内容によって、該当する障害の種類を判断します。「起動しない」という結果が同じ 2 台のサーバーでも、必要な対処が正反対になる場合があります。

SSH が使用できない場合、コンソールにはどう接続しますか？

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

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

ログインできないマシンでは sudo reboot を実行できないため、通常はパネルから hard reset を行って boot menu に進む必要があります。hard reset は電源を切断する操作と同じです。ファイルシステムは正常に終了されないため、次回の boot で filesystem check が実行されることを想定してください。

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

reset を押した直後からコンソールを確認します。最初の数秒間に Esc を繰り返し押してください。legacy BIOS モードで起動するマシンでは、Shift を押し続けます。操作できる時間は短く、コンソールビューアーの接続に 1 秒ほどかかることもあります。そのため、早めに押し始め、押し続けてください。

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

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

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

dpkg の出力には、インストール済みの kernel が一覧表示されます。1 行しかない場合、fallback はありません。まずこれを修正する必要があります。

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

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

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

マシンが正常に動作している間に、両方を修正します。/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" はメニューを graphical console と serial port に表示します。そのため、panel が提供する viewer のどちらからでも確認できます。console= kernel arguments は、その後に表示される boot messages にも同じ設定を適用します。2am に実際にアクセスできるメニューを用意できるなら、boot ごとに 10 秒待つ程度の負担は小さなものです。

どの障害分類に該当しますか？

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

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

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

論理ボリュームが表示されない。 これは、直前の分類に特定の原因が加わったケースです。(initramfs) プロンプトで ls /dev/mapper を実行します。表示が control だけなら、LVM (logical volume manager) のボリュームがアクティブ化されていないため、root device がまだ存在しません。次のコマンドでボリュームグループを手動で起動します。

lvm vgchange -ay
ls /dev/mapper
exit

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

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

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

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

もう1つのパターンは、boot failure ではありません。root shell に到達し、システムが 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

新しいカーネルを、次回の起動に賭けずにテストする

GRUB は、1 つのエントリを 1 回だけ起動し、その後は選択したデフォルトに戻せます。デフォルトを信頼できるカーネルに設定してから、新しいカーネルを 1 回だけ起動します。起動に失敗した場合は、管理パネルからハードリセットすると、コンソールでの操作に手間取ることなく正常なカーネルへ戻せます。

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

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 はメニューの先頭であり、最新のカーネルを指します。カーネルをインストールまたは削除するたびに番号は変わるため、ここでは番号よりもタイトルを使うほうが安全です。

ヘッドレスサーバーで 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 スナップショットと実際のバックアップの違いを理解しておくことが、障害がカーネルより大きくなったときにどちらで復旧できるかを左右します。

この点は、1 回の処理でカーネル、initramfs ツール、ブートローダー、GRUB 設定がすべて変更されるリリースアップグレードで特に重要です。スナップショットは、開始直前に取得してください。前夜ではなく、Ubuntu 24.04 から 26.04 へのアップグレードを開始する直前に取得することで、これから変更するマシンと復元ポイントの状態が一致します。そのアップグレードがまだサーバーに提示されていない場合、原因は設定の破損ではなくスケジュールです。LTS から LTS への移行は、最初のポイントリリースである 26.04.1 から開始されるためです。

カーネルパッケージに対する 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 またはシリアル）を開き、コントロールパネルからハードリセットを実行します。ログインして正常な再起動を行えないためです。マシンの再起動中に Esc を繰り返し押します。legacy BIOS boot の場合は Shift を押し続け、GRUB メニューを表示させます。「Advanced options for Ubuntu」を選択し、最新の kernel の下にあるエントリーを選びます。ログインプロンプトが表示されたら、uname -r を実行して使用中の kernel を確認し、dpkg -l 'linux-image-*' でインストール済みの他の kernel を確認します。システムが再び稼働してから診断を行います。

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

Cloud image では、/etc/default/grub.d/ 配下のファイルで GRUB timeout が 0 に設定されていることが一般的です。そのため、何も押さなくても最新の kernel が起動します。/etc/default/grub に GRUB_TIMEOUT=10 と GRUB_TIMEOUT_STYLE=menu を設定し、メニューが serial console にも表示されるよう GRUB_TERMINAL="console serial" を追加してから、sudo update-grub を実行します。grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ で確認してください。このディレクトリのファイルは main file の後に読み込まれるため、編集内容が上書きされる場合があります。

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

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

unattended-upgrades によって boot が壊れることはありますか？

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