--- title: "Linuxのバージョン確認コマンド｜OSはos-release、カーネルはuname -rで見る" url: "https://www.issoh.co.jp/tech/details/17895/" published: 2026-09-27 updated: 2026-10-27 categories: ["OS"] publisher: "株式会社一創" --- # Linuxのバージョン確認コマンド｜OSはos-release、カーネルはuname -rで見る Linuxのバージョン確認は、`cat /etc/os-release`でディストリビューションの版を、`uname -r`でカーネルの版を見る、という2本立てが基本です。この2つは別の番号で、Ubuntu 24.04のGAカーネル（リリース時の標準カーネル）は6.8系、Rocky Linux 9.8のカーネルは5.14系というように一致しません。 この記事では、2026年10月27日にUbuntu・Debian・Rocky Linux・AlmaLinux・Amazon Linux・Alpine・Fedoraの公式コンテナイメージ10種で取得した実際の出力をもとに、OSとカーネルの確認コマンド、更新後に再起動を待っているカーネルの見分け方、コンテナやWSL2で結果が食い違う理由、複数台の版を集める実装、サポート期限の判定までを扱います。 ## まとめ：LinuxのOS版とカーネル版の確認コマンド ディストリビューションの版は`/etc/os-release`、カーネルの版は`uname -r`で確かめてください。スクリプトで判定するなら、各社のreleaseファイルや`lsb_release`ではなく、os-releaseの`ID`と`VERSION_ID`を読む実装が一番壊れにくい方法です。 - **OSの版**：`cat /etc/os-release`。実測した10イメージの全てに存在し、`VERSION_ID`で版が分かる - **点リリースまで見る**：UbuntuはPRETTY\_NAMEやVERSION（24.04.5など）、Debianは`/etc/debian_version`（13.7など）。Debian 13はos-releaseの`DEBIAN_VERSION_FULL`にも出る - **カーネルの版**：`uname -r`。更新後に再起動していなければ、導入済みの新しいカーネルとは番号が違う - **再起動待ちの判定**：Ubuntuは`needrestart -b -k`、RHEL系は`needs-restarting -r`で分かる - **コンテナ内**：`uname -r`はホストのカーネルを返す。イメージの版はos-releaseで見る - **期限の判定**：OSの期限は配布元の公式表で見る。kernel.orgのLTS表でRHELやUbuntuの標準カーネルの寿命を判定しない ## Linuxのバージョン確認で最初に分けるOSの版とカーネルの版の違い 「Linuxのバージョン」という言葉は、2つのものを指します。1つはUbuntu 24.04やRHEL 9といったディストリビューションの版、もう1つはLinuxカーネル自体の版です。ディストリビューションはカーネルにパッケージ管理やライブラリを組み合わせた製品で、その全体像は[Linuxの仕組みとディストリビューションを扱った解説](/tech/details/13160/)で整理しています。 ### ディストリビューションの版とカーネル番号が一致しない理由と具体例 ディストリビューションは、kernel.orgのカーネルから系列を選んで、自社で修正を当て続けます。RHEL系はOSの版ごとに1つの系列を保守し、Ubuntuは[カーネルのライフサイクル](https://ubuntu.com/kernel/lifecycle)のとおり、リリース時のGAカーネルに加えて、後の版の系列を移植したHWEカーネルも同じOS版で選べます。版の数字がずれるのはこのためです。次の表は、2026年10月27日に各ディストリビューションの公式リポジトリから取得できた標準カーネルの番号です。 | ディストリビューション | VERSION\_ID | リポジトリのカーネル | | ------------------ | ----------- | ----------------------- | | Ubuntu 24.04.5 LTS | 24.04 | 6.8.0-147-generic（GA） | | Rocky Linux 9.8 | 9.8 | 5.14.0-687.60.1.el9\_8 | | AlmaLinux 10.2 | 10.2 | 6.12.0-211.68.1.el10\_2 | | Amazon Linux 2023 | 2023 | 6.1.188（6.12・6.18も配布） | これらはkernel.orgの最新番号（後述）とは別に、配布元が保守する番号です。RHEL 9系の5.14はkernel.orgの長期サポート版（LTS）にも含まれない系列ですが、Red Hatが修正を当てて保守しています。番号だけを見て「古いカーネルだ」と判断するのは誤りです。カーネルがOSの中で何を受け持つかは、[カーネルの役割と仕組みを実装目線でまとめた記事](/tech/details/13534/)が前提知識になります。 ### どちらの版を見るべきかをパッケージ・脆弱性・ドライバの用途別に判断 用途が決まれば、見る版も決まります。 - **パッケージの導入手順を選ぶ**：OSの版。aptかdnfか、どのリポジトリを足すかはディストリビューションと版で決まる - **ベンダーの脆弱性情報と照合する**：OSの版とパッケージの版。RHELやUbuntuの勧告はカーネルも含めてパッケージ単位で出る - **ドライバやeBPFなど機能の有無を確かめる**：カーネルの版。ただしディストリビューションは新機能を古い系列へ移植することがある 実務ではOSの版を主に、カーネルの版を補助に使う場面が大半です。ドライバの動作要件を確かめる場合も、カーネル番号に加えて、配布元の対応表や必要な機能・設定を確認してください。 ## LinuxのOSを確認するコマンド一覧と出力から分かる項目の早見表 OSを確認するコマンドは複数ありますが、分かる情報と使える環境がそれぞれ違います。「使えなかった環境」の列は、10種のコンテナイメージで実際に打った結果です。 | コマンド | 分かること | 使えなかった環境 | | ------------------- | --------------- | --------------------- | | cat /etc/os-release | ディストリ名と版 | 無し（10種全てで可） | | uname -r | カーネルの版 | 無し | | uname -m | CPUアーキテクチャ | 無し | | cat /proc/version | カーネルとビルド情報 | 無し | | hostnamectl | OS・カーネル・アーキテクチャ | 10種全て（未導入かsystemd未起動） | | lsb\_release -a | ディストリ名と版 | 10種全て（未導入） | | systemd-detect-virt | 仮想化の種類 | systemd無しの環境 | `uname -s`は、LinuxならLinux、FreeBSDならFreeBSDと、カーネルの種類を返します。UNIX系が混在する環境では、まずこれで「そもそもLinuxか」を確かめてください。LinuxとBSDの違いは[FreeBSDとLinuxの違いを実装目線で比べた記事](/tech/details/15823/)で整理しています。バージョン確認以外の日常的なコマンドは、[用途別に引けるLinuxコマンド一覧](/tech/details/2754/)とあわせて手元に置くと迷いません。 ### ディストリビューションが分からないサーバーで上から順に試す確認手順 引き継いだばかりのサーバーで、どのディストリビューションかも分からないことがあります。その場合は、仕様で場所が決まっているファイルから順に読み、無ければ調査用の一覧に切り替えます。 ``` # 1. 仕様で決まった2か所を優先順に読む for f in /etc/os-release /usr/lib/os-release; do [ -r "$f" ] && { cat "$f"; break; } done # 2. 読めなかったときだけ、各社のrelease系ファイルを一覧にする [ -r "$f" ] || ls -1 /etc/*release /etc/*version 2>/dev/null # 3. カーネルの種類・版・アーキテクチャは常に取る uname -s -r -m ``` 1の段階で読めないのは、古いサーバーや組み込み機器のほか、空の`scratch`イメージにアプリだけを置いた最小コンテナ、権限の設定が崩れた環境などです。2で`/etc/redhat-release`や`/etc/alpine-release`のようなファイル名が出れば、系統の見当が付きます。ただし`/etc/debian_version`はUbuntuにもあるので、これだけでDebianと決めないでください（理由は後述）。 ### ログイン前に出るissueの表示をOSの版の根拠にしない理由 コンソールのログイン画面に出る「Ubuntu 24.04 LTS」のような文字列は、`/etc/issue`の中身です。[issue(5)のマニュアル](https://man7.org/linux/man-pages/man5/issue.5.html)は、このファイルを「ログインプロンプトの前に表示するメッセージまたはシステム識別情報」と定めています。中身は案内文にすぎず、管理者が警告文に書き換えることも珍しくありません。版の判定や手順書にはos-releaseを使ってください。 ## os-releaseファイルでディストリビューションの版を確認する手順 [os-release(5)の仕様](https://www.freedesktop.org/software/systemd/man/latest/os-release.html)は、`/etc/os-release`を優先し、無いときだけ`/usr/lib/os-release`を読み、両方を混ぜないよう求めています。中身はシェル変数と同じ`キー=値`の書式です。実測した10イメージでは、全てで`/etc/os-release`が`../usr/lib/os-release`へのシンボリックリンクでした。 ``` $ docker run --rm ubuntu:24.04 cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.5 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.5 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" ...（以下URL類は省略） ``` ### 主要ディストリビューション10種のos-release実測値 2026年10月27日に公式コンテナイメージで`cat /etc/os-release`を実行し、判定に使う項目だけを抜き出した表です。タグが指すイメージは更新されるので、後日取得すると点リリースの番号は変わります。値の引用符の有無はディストリビューションによって違います。 | イメージ | ID | ID\_LIKE | VERSION\_ID | PRETTY\_NAME | | ----------------------- | --------- | ------------------ | ----------- | --------------------------------- | | ubuntu:26.04 | ubuntu | debian | 26.04 | Ubuntu 26.04.1 LTS | | ubuntu:24.04 | ubuntu | debian | 24.04 | Ubuntu 24.04.5 LTS | | ubuntu:22.04 | ubuntu | debian | 22.04 | Ubuntu 22.04.5 LTS | | debian:13 | debian | （無し） | 13 | Debian GNU/Linux 13 (trixie) | | debian:12 | debian | （無し） | 12 | Debian GNU/Linux 12 (bookworm) | | rockylinux/rockylinux:9 | rocky | rhel centos fedora | 9.8 | Rocky Linux 9.8 (Blue Onyx) | | almalinux:10 | almalinux | rhel centos fedora | 10.2 | AlmaLinux 10.2 (Lavender Lion) | | amazonlinux:2023 | amzn | fedora | 2023 | Amazon Linux 2023.12.20260930 | | alpine:3.22 | alpine | （無し） | 3.22.7 | Alpine Linux v3.22 | | fedora:43 | fedora | （無し） | 43 | Fedora Linux 43 (Container Image) | VERSION\_IDの粒度がそろっていない点に注意してください。RHEL系は9.8のようにマイナー版まで、Alpineは3.22.7のようにパッチ番号まで入りますが、Ubuntuはリリースの年と月（24.04＝2024年4月）、Debianはメジャー版の番号（13）だけです。Amazon Linux 2023は2023で固定され、どの更新日の版かは、表の項目の中ではPRETTY\_NAMEの末尾（20260930）にだけ出ます。`/etc/system-release`にも同じ文字列が入っていました。Rocky LinuxのイメージはDocker Hubの`rockylinux/rockylinux:9`で取得しました。 ### ID・VERSION\_ID・ID\_LIKEの意味とLinuxが何系かの見分け方 画面で読むなら`PRETTY_NAME`、プログラムで判定するなら`ID`と`VERSION_ID`を使います。仕様では、`ID`は版を含まない小文字の識別子、`VERSION_ID`はOS名やコードネームを含まない版の文字列と定義されています。PRETTY\_NAMEに版番号を入れるかどうかはOS側の判断に任されているので、PRETTY\_NAMEを文字列解析する実装は避けてください。なお、ID以外の項目は仕様上すべて任意で、ローリングリリースのOSなどではVERSION\_IDが無いこともあります。空なら取得失敗ではなく「書かれていない」と扱ってください。 「このLinuxは何系か」を知りたいときは`ID_LIKE`を見ます。パッケージ方式やAPIが近いOSの識別子を、近い順に空白区切りで並べる項目です。上の表のとおり、Ubuntuはdebian、Rocky・AlmaLinuxはrhel centos fedoraと書き、Amazon Linux 2023はfedoraだけを書きます。Debian・Fedora・Alpineのように系統の親そのものにはID\_LIKEが無いので、判定は`ID`と`ID_LIKE`を合わせて行う必要があります（実装例は後の章）。 ### 点リリースの番号はVERSION\_IDに出ないためUbuntuとDebianで見る場所 Ubuntu 24.04.5やDebian 13.7のような点リリースの番号は、どちらもVERSION\_IDには出ません。見る場所はディストリビューションごとに違います。 - **Ubuntu**：os-releaseの`PRETTY_NAME`か`VERSION`（24.04.5 LTS） - **Debian**：`/etc/debian_version`の中身（13.7、12.15）。Debian 13はos-releaseに独自項目`DEBIAN_VERSION_FULL=13.7`もあり、Debian 12には無い 落とし穴は、Ubuntuにも`/etc/debian_version`がある点です。実測では、Ubuntu 26.04で`forky/sid`、24.04で`trixie/sid`、22.04で`bookworm/sid`と、土台にしたDebianの開発版の名前が入っていました。Ubuntuの版とは関係が無いので、「debian\_versionがあるからDebian」「中身がtrixieだからDebian 13」という判定は誤りになります。 ### lsb\_releaseや各社のreleaseファイルを後回しにする理由 古い手順書には`cat /etc/redhat-release`や`lsb_release -a`がよく出てきます。前者はRHEL系にしか無く、後者は実測した10イメージのどれにも入っていませんでした。Ubuntu 24.04のコンテナで`apt install lsb-release`を実行すると、次のように表示されます。 ``` $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 24.04.5 LTS Release: 24.04 Codename: noble ``` [Debian 13のlsb-releaseパッケージの説明](https://packages.debian.org/trixie/lsb-release)には、LSBパッケージへの依存をやめて`/etc/os-release`の情報を使う最小実装だと書かれています。つまり、同じ情報の出どころはos-releaseです。パッケージを足してまで使う理由は薄いので、手順書と自動化にはos-releaseだけを書くと決めておくと、ディストリビューションが増えても手順が分岐しません。ファイル名が分からない環境の調査で`grep -H "" /etc/*release`を使う方法は、[grepコマンドのオプションとログ検索を扱った記事](/tech/details/15274/)で触れています。 ## Linuxカーネルのバージョンを確認するコマンドと再起動待ちの見分け方 カーネルの版は`uname -r`で確認します。[uname(1)のマニュアル](https://man7.org/linux/man-pages/man1/uname.1.html)によると、`-r`がカーネルのリリース番号、`-v`がカーネルのビルド情報、`-m`がマシンのハードウェア名で、`-a`は不明な項目を除いて全てを並べます。次はUbuntu 24.04.4の仮想マシンで取得した出力です。 ``` $ uname -r 6.8.0-117-generic $ uname -m x86_64 $ cat /proc/version Linux version 6.8.0-117-generic (buildd@lcy02-amd64-102) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #117-Ubuntu SMP PREEMPT_DYNAMIC Tue May 5 19:26:24 UTC 2026 ``` `/proc/version`は[proc\_version(5)](https://man7.org/linux/man-pages/man5/proc%5Fversion.5.html)で定義された、カーネル自身が返す文字列です。ビルドに使ったコンパイラの版とビルド日時まで分かります。Ubuntu 26.04では`uname`がRust製のuutils coreutils 0.10.0に置き換わっていましたが（`uname --version`で確認）、`-r`と`-m`の出力形式は同じでした。 ### uname -rの番号の読み方とディストリ独自の後置部分の意味 `6.8.0-117-generic`のうち、先頭の`6.8.0`が元にしたカーネルの系列、ハイフン以降がディストリビューション側のビルド番号と種類です。Rocky Linux 9.8なら`5.14.0-687.60.1.el9_8.x86_64`、AlmaLinux 10.2なら`6.12.0-211.68.1.el10_2.x86_64`、Amazon Linux 2023なら`6.1.188-233.386.amzn2023.x86_64`のように、末尾の記号で配布元とOSの版が分かります。 脆弱性の修正が入ったかどうかは、先頭の系列だけでは分かりません。`6.8.0-147.147`のような完全なパッケージ版を配布元の勧告と照合してください。UbuntuでLivepatchを使っている場合は、再起動なしで稼働中のカーネルに当たった修正があるので、[Livepatchの状態確認の手順](https://ubuntu.com/security/livepatch/docs/client/how-to-guides/operations/check-client-status/)にある`canonical-livepatch status`で適用状態も確かめます。同じ6.8.0でも、2026年10月27日にUbuntu 24.04のリポジトリにあった最新は`-147`で、`-117`のまま動いているカーネルはそれより前のビルドです。 ### hostnamectlでOSとカーネルとアーキテクチャを1回で表示する方法 systemdで動くサーバーなら、[hostnamectl](https://www.freedesktop.org/software/systemd/man/latest/hostnamectl.html)をサブコマンド無しで実行するだけで、OSの名前、カーネル、アーキテクチャ、仮想化の種類が並びます。systemd 255のUbuntu 24.04.4仮想マシンでの出力（一部抜粋）です。 ``` $ hostnamectl Static hostname: colima Virtualization: apple Operating System: Ubuntu 24.04.4 LTS Kernel: Linux 6.8.0-117-generic Architecture: x86-64 Hardware Vendor: Apple Inc. ``` Architectureの表記は`x86-64`とハイフンで、`uname -m`の`x86_64`とは違います。スクリプトで比較するなら、どちらのコマンドの値かをそろえてください。`--json=pretty`を付けると`KernelRelease`や`OperatingSystemPrettyName`をキーにしたJSONで出るので、監視ツールへ渡すときに扱いやすくなります。コンテナの中ではsystemdが動いていないため、AlmaLinux 10のイメージでは「System has not been booted with systemd as init system」で失敗しました。systemd自体の役割は[systemdの役割を解説した記事](/tech/details/8160/)を参照してください。 ### Ubuntu・Debianで導入済みカーネルと稼働中カーネルの差を確かめる手順 `apt upgrade`で新しいカーネルを入れても、再起動するまで`uname -r`は古い番号のままです。「カーネルを確認したのに番号が変わらない」というときは、導入済みのカーネルと稼働中のカーネルを並べて比べます。Ubuntu 24.04のコンテナに`linux-image-virtual`と`needrestart`を入れ、更新前後の差を擬似的に作った例です。コンテナでは稼働中のカーネルがホスト（ここではUbuntu 24.04.4の仮想マシン）のものになり、コンテナ内に入れたカーネルは起動に使われません。コマンドの使い方と出力の読み方を示すための例として見てください。 ``` $ uname -r # 稼働中 6.8.0-117-generic $ dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}' # 導入済み linux-image-6.8.0-147-generic 6.8.0-147.147 linux-image-virtual 6.8.0-147.147 $ cat /var/run/reboot-required *** System restart required *** $ sudo needrestart -b -k NEEDRESTART-VER: 3.6 NEEDRESTART-KCUR: 6.8.0-117-generic NEEDRESTART-KEXP: 6.8.0-147-generic NEEDRESTART-KSTA: 3 ``` `/var/run/reboot-required`は、update-notifier-commonが入っている環境でカーネル導入時に作られる目印です。より確実なのは`needrestart -b`の機械向け出力で、KCURが稼働中、KEXPが導入済みのうち起動されるはずのカーネルです。[needrestartのREADME](https://github.com/liske/needrestart/blob/master/README.batch.md)は、KSTAの値を0＝判定できない、1＝更新待ちなし、2＝ABI互換の更新待ち、3＝版の更新待ち、と定めています。監視でKSTAが2以上なら再起動の計画を立ててください。 ### RHEL系でrpm -q kernelとneeds-restarting -rを使う手順 Rocky Linux・AlmaLinux・RHELでは、導入済みのカーネルを`rpm -q kernel-core`で一覧にし、`uname -r`と見比べます。`--last`を付けると導入日時の新しい順に並びます。ただし、最後に導入したものが最高バージョンとは限らないため、版番号も確認してください。Rocky Linux 9.8のコンテナにkernel-coreとdnf-utilsを入れて取った出力で、上のUbuntuと同じく稼働中のカーネルはホストのものです。 ``` $ rpm -q --last kernel-core kernel-core-5.14.0-687.60.1.el9_8.x86_64 Tue Oct 27 00:05:33 2026 $ needs-restarting -r; echo "rc=$?" Core libraries or services have been updated since boot-up: * dbus * dbus-broker * systemd Reboot is required to fully utilize these updates. More information: https://access.redhat.com/solutions/27943 rc=1 ``` [needs-restartingの説明](https://dnf-plugins-core.readthedocs.io/en/latest/needs%5Frestarting.html)のとおり、`-r`は再起動が必要なら終了コード1、不要なら0を返します。判定は起動後に更新されたパッケージ名で行い、Rocky Linux 9.8の実装（`needs_restarting.py`の`NEED_REBOOT`）では、kernel・kernel-rt・glibc・linux-firmware・systemd・dbus系・microcode\_ctlが対象でした。kernel-coreだけを入れた上の例でカーネルが理由に挙がらず、systemdとdbusで再起動要と出たのはこのためです。通常の`dnf update`ではkernelパッケージも一緒に更新されるので、監視スクリプトでは終了コードで分岐させてください。 ### Linuxカーネルの最新バージョンとkernel.orgのLTS系列 「Linuxの最新バージョン」と聞かれたときに答える番号は、kernel.orgの系列表で決まります。2026年10月27日に取得した[releases.json](https://www.kernel.org/releases.json)の値です。 | 区分 | 版 | 保守終了の予定 | | -------- | ----------------- | ------------- | | mainline | 7.3 | － | | stable | 7.2.13 | 短期（数回の修正版で終了） | | longterm | 6.18.59 | 2028年12月 | | longterm | 6.12.114 | 2028年12月 | | longterm | 6.6.160 | 2027年12月 | | longterm | 6.1.190 | 2027年12月 | | longterm | 5.15.223・5.10.272 | 2026年12月 | 保守終了の予定は[kernel.orgのリリース一覧](https://www.kernel.org/category/releases.html)の表によります。ただし、この番号が意味を持つのはカーネルを自分でビルドする場合や、系列をそのまま使う組み込み機器の場合です。ディストリビューションの標準カーネルは配布元が保守するので、手元の`uname -r`がkernel.orgの最新より古くても、それだけで更新の必要は判断できません。6系の後半で何が変わったかは、[Linuxカーネル6.19の新機能とサポート終了を扱った記事](/tech/details/10935/)にまとめています。 ## コンテナとWSL2でLinuxのバージョン確認結果が食い違う原因と対処 開発環境でよく起きるのが、「os-releaseはUbuntuなのに、カーネル番号が見慣れない」という食い違いです。原因は、コンテナとWSL2のどちらも、中のディストリビューションと外のカーネルが別物である点にあります。 ### Dockerコンテナ内のunameがホストのカーネル番号を返す仕組み コンテナは仮想マシンと違い、ホストのカーネルを共有する仕組みです。そのためコンテナ内で`uname -r`を打つと、イメージの中身に関係なくホストのカーネルの番号が返ります。macOS上のColima（Ubuntu 24.04の仮想マシン）で試すと、Rocky LinuxやAlpineのイメージでも全て同じ番号でした。 ``` $ for img in ubuntu:24.04 rockylinux/rockylinux:9 alpine:3.22; do docker run --rm "$img" sh -c '. /etc/os-release; echo "$ID $VERSION_ID $(uname -r)"' done ubuntu 24.04 6.8.0-117-generic rocky 9.8 6.8.0-117-generic alpine 3.22.7 6.8.0-117-generic ``` Rocky Linux 9の標準カーネルは5.14系なのに、コンテナの中では6.8が返る、ということです。Mac上のDockerがどの仮想マシンで動くかは[Colimaの導入手順と設定を扱った記事](/tech/details/17842/)で触れています。コンテナの中からホストのOSを知りたい場合、os-release(5)は、実行環境がホストのos-releaseを`/run/host/os-release`として渡してよいと定めていますが、Dockerの既定では置かれません。 ### WSL2のmicrosoft-standard表記とホスト側OS情報の見分け方 WSL2では、Microsoftが配布する専用カーネルの上で各ディストリビューションが動きます。[WSL2-Linux-Kernelのリリース一覧](https://github.com/microsoft/WSL2-Linux-Kernel/releases)で2026年10月27日にLatestと表示されていたのは6.18.54.1で、公式のビルド設定ではリリース文字列の末尾に`-microsoft-standard-WSL2`が付きます。インストールしたUbuntuやFedoraの標準カーネルではありません。WSL1との構造の違いは[WSL2の仕組みとWSL1との違いをまとめた記事](/tech/details/3410/)で扱っています。 WSL2のカーネルはWindows側の`wsl --update`で更新され、中のディストリビューションで`apt upgrade`をしても変わりません。カーネル起因の不具合を調べるときは、Windows側の`wsl --version`でカーネルの版を確かめるのが先です。 ### systemd-detect-virtによる仮想マシン・コンテナ・WSLの判定 版の食い違いを見たら、まず「自分がどこで動いているか」を確かめると原因が早く絞れます。[systemd-detect-virt](https://www.freedesktop.org/software/systemd/man/latest/systemd-detect-virt.html)は仮想化の技術を短い名前で表示し、何も検出しなければ`none`を出して0以外の終了コードを返します。Colimaの仮想マシンでの結果です。 ``` $ systemd-detect-virt apple $ systemd-detect-virt --container || echo "not in container" none not in container ``` 識別子は、Dockerが`docker`、Podmanが`podman`、WSLが`wsl`、KVMが`kvm`、EC2のNitroが`amazon`です。入れ子の環境では原則として最も内側を返し、`--vm`を付けると仮想マシンだけを見ます。コンテナ内でだけ`uname -r`の値を「ホストのカーネル」として記録する、といった使い分けをスクリプトに組み込めます。軽量なコンテナイメージにはsystemdが入っていないので、その場合はホストや仮想マシンの側で実行してください。 ## シェルスクリプト・SSH・Python・Ansibleで複数サーバーのバージョンを集める実装 サーバーが数台を超えると、1台ずつログインして確かめる方法は続きません。版の確認を自動化する型を、規模の小さい順に示します。 ### os-releaseを読み込みID\_LIKEで分岐するシェルスクリプトの例 os-releaseの仕様にある読み込み方をもとに、OS・カーネル・アーキテクチャを1行で出し、系統で分岐するスクリプトです。os-releaseをシェルで読み込めるのは、書式がシェル変数と互換だからです。 ``` #!/bin/sh # OSとカーネルの版を1行で出し、apt系かdnf系かを判定する if [ -e /etc/os-release ]; then f=/etc/os-release; else f=/usr/lib/os-release; fi . "$f" echo "os=${ID} ${VERSION_ID} kernel=$(uname -r) arch=$(uname -m)" case " ${ID} ${ID_LIKE:-} " in *" debian "*) echo "family=debian" ;; *" rhel "*|*" fedora "*) echo "family=rhel" ;; *) echo "family=other" ;; esac ``` 空白で囲んでから比較しているのは、`ID_LIKE="rhel centos fedora"`のような複数値の中から単語単位で探すためです。`ID`自体も判定に含めているので、ID\_LIKEを持たないDebian本体やFedora本体も正しく分かれます。7種のイメージで実行すると、Ubuntu・Debianが`family=debian`、Rocky・AlmaLinux・Fedora・Amazon Linux 2023が`family=rhel`、Alpineが`family=other`になりました。Amazon Linux 2023はID\_LIKEがfedoraだけなので、「RHEL互換」ではなく「dnfを使う系統」として扱われる点に注意してください。Alpineのbusybox shでもこのスクリプトはそのまま動きました。 ### SSHで数台のOSとカーネルの版を1行ずつ集めるループの書き方 Ansibleを入れるほどでもない数台なら、手元からSSHでコマンドを流すだけで一覧が作れます。公開鍵認証が通っている前提で、`BatchMode=yes`を付けてパスワード待ちで止まらないようにしています。鍵の設定は[SSH接続の仕組みと公開鍵認証の設定を扱った記事](/tech/details/13544/)を参照してください。 ``` for h in web01 web02 db01; do printf '%s ' "$h" ssh -o BatchMode=yes "$h" '. /etc/os-release; echo "$ID $VERSION_ID $(uname -r) $(uname -m)"' done ``` リモート側のコマンドを単引用符で囲んでいるのは、`$ID`や`$(uname -r)`を手元ではなく接続先で展開させるためです。出力はホスト名・ID・版・カーネル・アーキテクチャの順に空白区切りで並ぶので、そのまま表計算ソフトに貼れます。 ### Pythonのplatformモジュールでos-releaseを辞書として読む実装例 監視や棚卸しのツールをPythonで書くなら、os-releaseを自前で解析する必要はありません。[Python公式のplatformモジュール](https://docs.python.org/3/library/platform.html)には3.10で`platform.freedesktop_os_release()`が追加され、`/etc/os-release`、無ければ`/usr/lib/os-release`を読んで辞書で返します。どちらも読めないときは`OSError`を送出します。 ``` import platform info = platform.freedesktop_os_release() ids = [info["ID"]] + info.get("ID_LIKE", "").split() print(info["ID"], info.get("VERSION_ID", ""), platform.release(), platform.machine()) print("family=rhel" if "rhel" in ids or "fedora" in ids else "family=debian" if "debian" in ids else "family=other") ``` `python:3.12-slim`のイメージ（中身はDebian 13）で実行すると、1行目は`debian 13 6.8.0-117-generic x86_64`、2行目は`family=debian`でした。DebianにはID\_LIKEが無いので、`info["ID_LIKE"]`と添字で書くとKeyErrorになります。`get()`で既定値を渡しているのはそのためです。 ### Ansibleのsetupモジュールで全台の版とカーネルを一覧化する手順 構成管理にAnsibleを使っているなら、新しいスクリプトは要りません。[ansible.builtin.setupモジュール](https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/setup%5Fmodule.html)の`filter`は、シェルと同じワイルドカードで返す項目を絞れます。 ``` $ ansible all -m ansible.builtin.setup -a 'filter=ansible_distribution*' $ ansible all -m ansible.builtin.setup -a 'filter=ansible_kernel' ``` Playbookの中で条件分岐に使うときは、[Ansibleのfacts解説](https://docs.ansible.com/projects/ansible/latest/playbook%5Fguide/playbooks%5Fvars%5Ffacts.html)のとおり`ansible_facts['distribution']`・`ansible_facts['distribution_major_version']`・`ansible_facts['kernel']`のように、`ansible_`接頭辞を外して参照します。結果を台帳に取り込めば手作業の転記を減らせます。応答しなかったホストは結果に出ないので、台帳の台数と突き合わせて取得漏れを確かめてください。 ## 確認した版からサポート期限を判定し更新計画へつなげる判断基準 版を確かめる目的の多くは、「このサーバーはいつまで修正を受けられるか」を知ることです。期限は必ず配布元の公式表で照合してください。 ### 主要ディストリビューションの標準サポート終了日の早見表 2026年10月27日時点で、各配布元の公式表から取った期限です。Ubuntuは[リリースサイクルの公式ページ](https://ubuntu.com/about/release-cycle)、RHELは[Red Hatの製品ライフサイクルAPI](https://access.redhat.com/product-life-cycles/api/v1/products?name=Red+Hat+Enterprise+Linux)、Debianは[Debianのリリース一覧](https://www.debian.org/releases/)、CentOSは[CentOSのダウンロードページ](https://www.centos.org/download/)によります。 | OS | 標準の保守終了 | 延長の終了 | | ---------------- | ---------------- | ------------------- | | Ubuntu 22.04 LTS | 2027年5月 | 2032年5月（ESM） | | Ubuntu 24.04 LTS | 2029年5月 | 2034年5月（ESM） | | Ubuntu 26.04 LTS | 2031年5月 | 2036年5月（ESM） | | RHEL 8 | 2029年5月31日 | 2033年5月31日（ELS・別契約） | | RHEL 9 | 2032年5月31日 | 2036年5月31日（ELS・別契約） | | RHEL 10 | 2035年5月31日 | 2039年5月31日（ELS・別契約） | | Debian 12 | 2026年7月11日（終了済み） | 2028年6月30日（LTS） | | Debian 13 | 2028年8月9日 | 2030年6月30日（LTS） | | CentOS Stream 9 | 2027年5月31日 | － | | CentOS Stream 10 | 2030年5月31日 | － | 表に無いもののうち、CentOS Linux 7は2024年6月30日、Amazon Linux 2は2026年6月30日にサポートが終わっています。os-releaseの`ID`が`centos`でVERSION\_IDが7、または`amzn`でVERSION\_IDが2のサーバーが見つかったら、更新の対象です。移行先の選び方は[CentOS終了後の後継OSへの移行判断を扱った記事](/tech/details/15403/)と[Amazon Linux 2からAL2023へ移す手順の記事](/tech/details/18024/)にまとめています。Ubuntu 26.04への更新で変わる点は[Ubuntu 26.04 LTSの新機能とアップグレードの記事](/tech/details/10901/)が詳しいです。 os-releaseには期限を`SUPPORT_END=YYYY-MM-DD`で書く項目も定義されています。実測した10イメージでは、Rocky Linux 9が`2032-05-31`、AlmaLinux 10が`2035-06-01`、Amazon Linux 2023が`2029-06-30`、Fedora 43が`2026-12-02`を書いていた一方、Ubuntu・Debian・Alpineには項目自体がありませんでした。`grep SUPPORT_END /etc/os-release`で値が出ればそれを目安にし、出なければ上の公式表を見に行ってください。 ### 期限切れのOSを放置してよい場面と更新作業を外部へ任せるべき条件 延長保守まで終わったOSを残してよいのは、外部・社内ネットワークから隔離し、認証情報やホストとの共有領域を持たせず、用途と廃棄日を決めた検証用の仮想マシンに限る、というのがこの記事の推奨です。この条件を満たすなら、更新するより作り直すほうが手間は小さく済みます。 一方、外部に公開しているWebサーバーや、個人情報を扱う業務システムの土台で標準保守が切れているなら、更新計画を先送りしてはいけません。Debian 12のように標準保守が終わってLTSに移った版は、修正の対象パッケージが絞られます。[bookwormのリリース情報](https://www.debian.org/releases/bookworm/)によるとLTSの対象はi386・amd64・armhf・arm64・ppc64elだけで、それ以外のアーキテクチャは保守が終わっています。残り期間は移行の準備に充ててください。同じ台帳の中にRHEL系とUbuntu系が混ざり、アプリの動作確認まで含めた移行が必要な場合は、社内の担当者1人で抱えると止まりがちです。OSの更新とアプリの移行を一体で計画し、クラウド上に作り直す選択肢まで比べたいときは、[一創のインフラ構築（AWS・Google Cloud・Azure）](/service/system/aws/)で、現行の版の棚卸しから移行後の保守まで相談できます。 ## よくある質問 ### LinuxのOSを確認するコマンドは何を使えばよいですか？ ディストリビューションの名前と版は`cat /etc/os-release`、カーネルの版は`uname -r`で確認します。systemdが動いているサーバーなら`hostnamectl`で、OSの名前、カーネルの版、アーキテクチャがまとめて表示されます。コンテナのようにsystemdが無い環境では、`cat /etc/os-release; uname -r`と2つを続けて打ってください。 ### CentOSやAlmaLinuxのバージョンはどう確認しますか？ `cat /etc/os-release`で`VERSION_ID`を見てください。RHEL系はAlmaLinuxの10.2のようにマイナー版まで入ります。`/etc/redhat-release`や`/etc/almalinux-release`でも1行で表示できますが、ディストリビューションごとにファイル名が違うので、手順書にはos-releaseを書くほうが後から困りません。CentOS Linux 7・8はサポートが終わっているので、表示されたら移行を検討してください。 ### uname -rとuname -aの違いは何ですか？ `uname -r`はカーネルのリリース番号だけを表示します。`uname -a`はカーネル名、ホスト名、リリース番号、ビルド情報、アーキテクチャなどを1行に並べます。スクリプトで版を比較するなら、余分な情報が無い`-r`を使ってください。どちらもディストリビューションの版は表示しません。 ### Linuxの最新バージョンはいくつですか？ カーネルは2026年10月27日時点でkernel.orgのmainlineが7.3です（系列表は本文のkernel.orgの章）。OSの最新はそれとは別の番号で、Ubuntuの最新LTSが26.04、AlmaLinuxが10.2、Debianが13（13.7）です。どれも更新が続くので、最新の番号は各公式ページで確かめてください。 ### FreeBSDのバージョンはどう確認しますか？ FreeBSDでは`freebsd-version`を使います。[freebsd-version(1)のマニュアル](https://raw.githubusercontent.com/freebsd/freebsd-src/main/bin/freebsd-version/freebsd-version.1)によると、`-k`がインストール済みカーネル、`-u`がインストール済みユーザーランド、`-r`が稼働中カーネルの版とパッチレベルです。`-k`と`-r`が違えば、更新後に再起動していない状態です。`uname -r`も使えますが、ユーザーランドだけを更新したときの版は分かりません。 ## 関連記事 - [Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点](/tech/details/2754/) - [Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能と24.04からのアップグレード【26.04.1対応】](/tech/details/10901/) - [CentOSとは？RHEL互換OSの終了とCentOS Stream・後継OSへの移行判断を実装目線で解説【2026年版】](/tech/details/15403/) - [Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所](/tech/details/18024/) - [Linuxカーネル6.19の新機能とサポート終了｜リリース日・6.19.14・7.0以降への移行](/tech/details/10935/) --- 出典: [Linuxのバージョン確認コマンド｜OSはos-release、カーネルはuname -rで見る]()（株式会社一創）