Ubuntu 26.04 講座 / 起動・カーネル・ネットワーク障害の復旧

Ubuntu 26.04の障害復旧は、まずコンソールでどこまで起動しているかを確認し、直前の変更とログを保存した後、範囲を絞ります。SSHに接続できないという理由だけで、OSが起動していないと判断することはできません。起動・カーネル・ネットワーク・アプリに分けて調査し、戻す設定を一つずつ選びます。 関連する条件と手順は、Linux ログで障害原因を絞り込むを参照できます。 関連する条件と手順は、障害を再現して証拠に基づいて復旧する総合実習を参照できます。

障害の段階と変更対象を区別する

可能であれば復旧前に状態を保持し、既存のバックアップとディスク暗号化の解除キーを確保します。実習のために運用サーバーのディスクやネットワークを意図的に壊しません。調査記録には時刻・エラー原文・最後に成功した作業・直前の変更を残し、秘密キーや認証情報は含めません。

ログインできる時に読み取り専用で調査する

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

以前のブート記録があれば、sudo journalctl -b -1 -p err --no-pagerで比較します。過去のログがないという事実は障害がなかった証拠ではありません。ディスクがいっぱいでもログを一括削除せず、原因と保存場所を確認して必要な記録を保持します。エラー行だけで因果関係を知るのが難しい場合は、当該時刻前後およびユニットごとの記録を調査します。

複製VMで制限されたサービスの失敗と復元を練習する

元の環境と隔離した練習用VMでコンソールにログインして実施します。以下の新しいユニットはブート時に有効化せず、既存のデータファイルを削除したり、ネットワークを変更したりしません。まず正常な動作を確認し、その後falseを使用して drop-inで意図的な失敗 を作成し、そのファイルのみを削除して復元します。この実習はサービス診断の手順であり、実際のカーネル・ブート障害まで再現したものではありません。

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

基準動作はResult=success・ExecMainStatus=0、失敗の練習ではResult=exit-code・ExecMainStatus=1を期待します。oneshotのinactiveと失敗を区別し、journalの失敗時刻・実行コマンドを比較します。次の復元は、このファイルを作成後、編集が一切行われていない条件でのみ実行します。

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

再度 success·0 かどうかを確認します。完全に整理するには、unit が今回の実習ファイルかどうかと非アクティブ状態を確認し、空の drop-in ディレクトリと unit のみを削除した後、daemon-reload します。実際の起動障害で以前のカーネルやリカバリモードを使う判断は、このサービス実習とは別に記録します。

更新後の起動失敗と以前のカーネルの確認

更新直後に起動が失敗し、GRUB と以前のカーネルを使用できる場合、コンソールの Advanced options for Ubuntu から以前のカーネルを選択して起動を試みます。GRUB の表示方法はファームウェア・ホスト・タイミングによって異なるため、VM コンソールや機器の起動操作方法を確認する必要があります。暗号化ディスクは依然として解除が必要です。

以前のカーネルで起動した場合、uname -r を記録し、更新履歴・該当カーネルのログ・関連ドライバおよび DKMS（Dynamic Kernel Module Support、追加のカーネルモジュールをビルドする仕組み）の状態を比較します。この結果のみで新しいカーネルが唯一の原因であるとは断定しません。実行中のカーネルと正常起動用カーネルを保持し、確認した原因に応じて修正した後、通常起動を確認します。

Ubuntu Wiki の Recovery mode ガイドで GRUB の回復メニューと事前条件を確認できます。

初期RAMディスクの生成基盤を区別する

26.04の標準基盤はDracutへ移行していますが、既存のinitramfs-tools構成もあり得ます。起動復旧で別のLTSの記事の再生成コマンドを直ちに実行せず、導入ツールと起動ファイルを先に確認します。

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

ツールの導入だけで現在の起動イメージの作成元を断定しません。暗号化・LVM・RAIDと対象カーネルに合う設定・公式手順を確認し、再生成前に正常カーネル・コンソール・バックアップを確保します。

Ubuntu 26.04のDracut移行

リカバリモードでも確認後、書き込みを許可します

復旧メニューの root シェルは強い権限を持ち、通常のログインとは異なります。ディスクの認識・空き容量・マウント状態・修正するファイルをまず確認します。ルートファイルシステムが読み取り専用で、実際の設定変更に書き込みが必要な場合のみ、復旧シェルで次の作業を検討します。

findmnt /
mount -o remount,rw /

復旧シェルでは root で実行するため、sudo は付けていません。ファイルシステムの破損や入出力エラーがある場合は、書き込みを繰り返さず、データの保全と構成に合った救出手順を優先します。マウントされたファイルシステムに対して修正モードの fsck を実行したり、対象が不明なディスクを初期化したりしません。

ネットワーク設定変更後に接続が切れたとき

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

コンソールで実際のインターフェース・管理主体・有効な Netplan 設定を確認します。最新の変更ファイルを変更前のバックアップと比較し、別名の YAML ファイルを追加して上書きしようとしません。cloud-init などで生成される設定かどうかも確認します。

正しいバックアップに戻すときは、現在の設定も保持し、netplan generate が成功した後にコンソールを確保した状態で sudo netplan try --timeout 120 を使用します。自動復帰が失敗する場合もあるので、実際のアドレス・通信経路・DNS と新しい SSH 接続を別途確認します。ネットワークが正常であれば、SSH キー・待機ポート、UFW もそれぞれ確認します。

netplan try の制約と復帰後の確認事項は公式マニュアルを確認してください。

資料保存と復旧完了の判断

インストールされているオペレーティングシステムで操作できない場合は、検証済みの Live ISO などの復旧環境を確認します。ディスクにアクセスする前に暗号化・LVM・RAID を確認し、元のディスクをインストール対象として誤って選択しないようにします。汎用 GRUB 再インストールやパーティション再作成コマンドを推測して実行せず、実際の構成に合った手順と検証済みバックアップを選択します。

復旧後に再起動・新しいSSH接続・サービス・アプリの読み書き・ログ・バックアップを確認します。何を戻し、何が改善されたか、未解決の事項や再発時に収集する記録を残します。応答が返ってきた瞬間よりも正常な運用を続けられるかが復旧完了の基準です。