記事一覧に戻る
Web技術系

Ubuntu 24.04の更新記録:カーネルの反映から再起動後の確認まで

Ubuntu 24.04サーバーで、カーネルの再起動待ちを確認し、Node.jsを含む通常更新を適用した記録。SSHとWSLの取り違え、2回の再起動、ESM Appsと未修正の脆弱性も整理する。

ノートと鉛筆のイラスト

Linuxカーネルの脆弱性が気になり、SSHで接続しているUbuntuサーバーの更新状態を確認した。すると、新しいカーネルはすでにインストールされていたのに、動いていたのは古いカーネルだった。

まず再起動で新しいカーネルに切り替え、続いてNode.jsなどの通常更新を適用した。更新後にも再起動が必要になり、今回は合計2回再起動している。その確認手順と、途中でつまずいたSSH・WSLの違いを残しておく。

作業日と公式情報の確認日は2026年10月30日。接続先のホスト名とユーザー名は説明用の値に置き換えている。以下のバージョンは今回の記録で、実際に更新するときはその時点の配信状況を確認する。

今回の環境と結果

項目 作業前 作業後
Ubuntuの表示 24.04.3 LTS 24.04.5 LTS
稼働中のカーネル 6.8.0-107-generic 6.8.0-147-generic
Node.js 22.22.0 22.23.4
通常の更新候補 100件以上 0件
systemdの失敗サービス 作業前は未確認 0件
再起動通知 作業前は未確認 最後の再起動後は表示なし

手元のPCはWSL2で、そこからサーバーへSSH接続した。サーバーではAPTによるパッケージ管理を利用し、管理作業にはsudoを使っている。

今回は同じUbuntu 24.04 LTSの中で更新した。ログイン時に案内された26.04へのリリースアップグレードは行っていない。

サーバーのOSと稼働中のカーネルを確認する

まず、手元のPCからサーバーへ接続する。userとserver.example.comは自分の接続先に置き換える。

ssh [email protected]

接続先のサーバーで、次を実行した。

cat /etc/os-release
uname -r

/etc/os-releaseはOSの種類とバージョン、uname -rは現在動いているカーネルを確認するためのもの。今回の出力を抜粋すると、次の状態だった。

PRETTY_NAME="Ubuntu 24.04.3 LTS"
VERSION_ID="24.04"
VERSION_CODENAME=noble
6.8.0-107-generic

Ubuntuのバージョンとカーネルのバージョンは別の情報なので、両方を確認しておく。

インストール済み・更新候補・稼働中を比べる

続いて、パッケージ情報を取得し、カーネルの更新候補とファイルを確認した。

sudo apt update
apt-cache policy linux-image-generic
ls /boot/vmlinuz-*

apt updateは配布元からパッケージ情報を取得する操作。パッケージ本体の更新には、後述するapt upgradeを使う。Ubuntu公式のパッケージ管理手順

apt-cache policyの出力は、次のようになっていた。配布元などの行は省略している。

linux-image-generic:
  Installed: 6.8.0-147.147
  Candidate: 6.8.0-147.147

/bootには、古いものと新しいものの両方があった。

/boot/vmlinuz-6.8.0-107-generic
/boot/vmlinuz-6.8.0-147-generic
表示 今回確認したこと
Installed linux-image-genericの導入済みバージョンは6.8.0-147.147
Candidate 配布元から選ばれる候補も6.8.0-147.147
/boot/vmlinuz-* 新しい6.8.0-147のカーネルファイルが存在する
uname -r それでも稼働中なのは6.8.0-107-generic

linux-image-genericは、対応するカーネルパッケージを導入するためのメタパッケージ。新しいカーネルが入っていることと、それで起動していることは別だった。Ubuntuの公式資料でも、新しくインストールしたカーネルで動かすには再起動が必要と説明されている。Livepatchによる稼働中のカーネルへの修正適用は別の仕組みで、今回はその適用状況までは確認していない。Ubuntu公式のカーネル解説

1回目の再起動で新しいカーネルに切り替える

サーバーを再起動した。実行するとSSH接続も切れ、サーバー上のサービスは一時停止するので、停止できるタイミングで行う。

sudo reboot

再起動直後のConnection refused

再起動してすぐにSSHで接続し直したところ、接続が拒否された。接続先を説明用に置き換えると、次のエラーになる。

ssh: connect to host server.example.com port 22: Connection refused

今回は少し待ってから再接続するとログインできた。再起動直後はSSHがまだ接続を受け付けていない可能性がある。ただし、このエラーだけで再起動中と断定はできない。数分待っても続く場合は、サーバーの管理画面やコンソールから起動状態とSSHサービスを確認する。

SSHが切れたあとは手元のPCに戻っている

このとき、接続できていないまま手元のターミナルでuname -rを実行してしまった。

6.6.87.2-microsoft-standard-WSL2

これは手元のWSL2のカーネルだった。サーバーの再起動結果を調べるには、SSHでサーバーへ入り直してからコマンドを実行する必要がある。

実行する場所 実行すること
手元のPC・WSL ssh [email protected]で接続する
SSH接続先のサーバー uname -rでサーバーのカーネルを確認する

再接続後、サーバーで実行した。

uname -r
6.8.0-147-generic

これで新しいカーネルに切り替わった。6.8.0-147-genericはコマンドの出力なので、それ自体を入力する必要はない。

残っているパッケージの更新を適用する

カーネルを切り替えたあと、ほかにも更新候補が残っていたので一覧を確認した。

apt list --upgradable

今回の一覧には、次のようなパッケージが含まれていた。

対象 一覧で確認した内容
Node.js 22.22.0から22.23.4への更新
PHP関連 php-commonと画像処理ライブラリのlibgd3の更新
OS関連 AppArmor、Netplan、起動関連パッケージ、各種ライブラリなど

Node.js 22.23.4は、2026年10月21日公開のセキュリティリリース。TLSやDNS処理、Brotliなどの修正を含む。Node.js公式リリースノート

PHP本体のphp8.x-cliやphp8.x-fpmの更新は、この一覧にはなかった。php-commonの更新だけでは、PHP本体やWeb側で稼働しているPHPのバージョンまで確認したことにはならない。

一覧を確認したあと、サーバー側で通常の更新を実行した。

sudo apt upgrade

最初のDo you want to continue? [Y/n]で内容を確認して進める。Ubuntu 24.04では、更新されたライブラリを利用するサービスがneedrestartによって自動再起動される場合もある。Ubuntu公式のサービス再起動の説明

キーボード配列の設定画面が出た

途中でConfiguring keyboard-configurationという画面が開いた。日本語配列向けの選択肢として、一番上に通常のJapanese、その下にDvorakやKanaなどの種類が並んでいた。

日本語配列の環境では通常のJapaneseを選び、Tabで<Ok>へ移動し、Enterで確定して進める。別の配列を使っている場合は、その環境に対応するものを選ぶ。

更新後の確認と2回目の再起動

更新処理が終わったあと、サーバー側で次の4つを実行した。

node -v
apt list --upgradable
systemctl --failed --no-pager
cat /var/run/reboot-required 2>/dev/null
確認項目 更新直後の結果
node -v v22.23.4
apt list --upgradable Listing... Doneだけで、更新候補の行はなし
systemctl --failed --no-pager 0 loaded units listed.
再起動通知 *** System restart required ***

パッケージの更新は終わっていても、再起動が必要という通知が残っていた。そのため、もう一度サーバーを再起動した。

sudo reboot

少し待ち、手元のPCから再び接続した。

ssh [email protected]

再接続後のログイン表示は、次の状態になっていた。

Ubuntu 24.04.5 LTS (GNU/Linux 6.8.0-147-generic x86_64)
0 updates can be applied immediately.

さらに、サーバー側で失敗サービスと再起動通知を確認した。

systemctl --failed --no-pager
cat /var/run/reboot-required 2>/dev/null

失敗サービスは再び0 loaded units listed.。再起動通知のコマンドは何も表示しなくなった。2>/dev/nullはエラー出力を表示しない指定で、通知ファイルが存在しない場合のメッセージも隠している。

今回の記録では、SSHで再接続でき、失敗状態のsystemdサービスと再起動通知が残っていないことまで確認できた。Webアプリのページ表示、ログイン、DBを使う操作などは、これらとは別に確認する必要がある。この記録には、公開サイトの動作確認結果は含めていない。

通常更新が0件でも、残っている対応がある

今回関係するカーネル脆弱性の代表例を、Ubuntu公式の情報と照合した。

脆弱性 Ubuntu 24.04の標準カーネル向けの状況(2026年10月30日確認)
PPPoEject・CVE-2026-68121 6.8.0-147.147で修正済み。今回起動したカーネルに修正が含まれる。Ubuntu公式
TCP/IPv4・CVE-2026-98432 修正準備中。公式ページには6.8.0-149.149で作業中とあり、今回の6.8.0-147では未修正。Ubuntu公式

また、最後のログイン時にも次の案内が残っていた。

Expanded Security Maintenance for Applications is not enabled.
17 additional security updates can be applied with ESM Apps.

ESM Appsは、Ubuntu Proで提供される追加のセキュリティ更新で、universeのパッケージを対象とする。今回は有効化しておらず、この17件は通常更新に含まれていない。対象パッケージやCVEの内訳までは今回確認していない。Ubuntu公式のESM解説

今回完了したのは、有効な配布元から通常適用できるパッケージ更新と、その反映のための再起動・状態確認。今後も更新候補を確認し、修正準備中のカーネル脆弱性は配信後に対応する。ESM Appsの追加更新については、対象パッケージと利用状況を別途確認する。