Как узнать версию Linux: дистрибутив, ядро, архитектура и окружение

«Версия Linux» может означать дистрибутив, ядро, архитектуру, образ контейнера или релиз виртуального хоста. Для поддержки и обновления нужно собрать несколько независимых признаков, не полагаясь на один баннер входа.

1. Какая именно версия нужна для вашей задачи

Слово «версия» означает несколько независимых величин

В заявке «у меня Linux 6.1» не хватает главного: это может быть номер ядра, но приложение зависит от библиотек дистрибутива. У системы одновременно есть имя производителя, редакция, релиз userspace, кодовое имя, номер установленного пакета, запущенное ядро и архитектура. Для контейнера добавляется идентификатор образа, а для appliance — версия продукта производителя.

Номер в таблице является примером формата, а не указанием самого нового поддерживаемого выпуска. Срок поддержки и доступность конкретной архитектуры проверяют отдельно.

Стандартный источник сведений о системе — /etc/os-release, а резервный — /usr/lib/os-release. Используйте поля ID, VERSION_ID, ID_LIKE и PRETTY_NAME.

cat /etc/os-release
. /etc/os-release
printf 'ID=%s VERSION_ID=%s PRETTY=%s\n' "$ID" "$VERSION_ID" "$PRETTY_NAME"

Файл предназначен для машинного чтения, но значения нужно корректно разбирать как shell-переменные.

Почему одного названия недостаточно

Для обращения в поддержку подготовьте четыре значения: релиз userspace, работающее ядро, архитектуру пакетов и тип окружения. На Debian13 можно вручную поставить новое ядро; от этого Debian не станет Ubuntu. В контейнере Ubuntu userspace работает поверх ядра хоста, а у rolling-дистрибутива может отсутствовать VERSION_ID вообще. Это нормальные различия, а не причина отредактировать os-release «для порядка».

Чтение выполняется без sudo. /etc/os-release имеет приоритет, /usr/lib/os-release используется только при его отсутствии; объединять их значения нельзя. Для доверенной собственной установленной системы shell-разбор допустим. Чужой файл из тикета не следует выполнять через . file: он может содержать команды. Сначала просмотрите его как текст.

if [ -r /etc/os-release ]; then
  cat /etc/os-release
elif [ -r /usr/lib/os-release ]; then
  cat /usr/lib/os-release
else
  printf 'os-release not available\n'
fi

PRETTY_NAME удобно человеку; ID и VERSION_ID — автоматизации. ID_LIKE подсказывает родство, но не гарантирует полной совместимости репозиториев.

2. Таблица: 35 дистрибутивов и платформ

Большая таблица дистрибутивов и специальных платформ

В первом столбце — система, в остальных — доступные способы прочитать её идентичность и особенности интерпретации. Файл выпуска может отсутствовать в минимальном образе: наличие проверяют через test -r, отсутствие не исправляют его ручным созданием. Общий формат os-release описан в спецификации.

Команда emerge --info, pveversion -v или сведения платы могут выдавать больше, чем нужно публичному отчёту. Просмотрите результат перед передачей. Для RPM-образа отсутствие dnf возможно и нормально: образ может содержать только runtime. Не устанавливайте пакетный менеджер в работающий контейнер ради строки версии.

На системах с systemd команда показывает ОС, ядро, архитектуру, hostname и тип виртуализации.

hostnamectl
hostnamectl status --json=short 2>/dev/null || true

Отсутствие hostnamectl не означает, что система повреждена: минимальный контейнер может не использовать systemd.

Что делать без systemd и D-Bus

hostnamectl обращается к systemd-hostnamed через системную шину. Ошибка «System has not been booted with systemd» в контейнере не означает потерю версии ОС. Используйте os-release и uname. Не устанавливайте и не запускайте полноценный init только ради получения отчёта.

ps -p 1 -o comm=
readlink /proc/1/exe

Эти команды показывают первый процесс видимого PID namespace, а не всегда init физического хоста. В контейнере им может быть приложение. Некоторые версии hostnamectl не поддерживают JSON-режим, поэтому штатный текстовый status остаётся более переносимым. При недоступной шине диагностика продолжается другими независимыми источниками.

3. Запущенное ядро, установленные ядра и backport

Почему «поставили новое ядро», а uname показывает старое

Установка пакета записывает файлы на диск, но работающий kernel продолжает исполняться в памяти до загрузки другого ядра. На сервере могут одновременно храниться несколько версий для возврата. Поэтому сравнивают запущенное ядро, установленные пакеты и выбранную загрузочную конфигурацию.

uname -r
# Debian/Ubuntu: установленные пакеты ядра, не обязательно активное ядро
dpkg-query -W -f='${binary:Package} ${Version}\n' 'linux-image-*' 2>/dev/null
# RPM-система: пакеты ядра по фактически используемой ветке
rpm -q kernel kernel-core 2>/dev/null
# Arch: основная и LTS-ветка могут отсутствовать по отдельности
pacman -Q linux linux-lts 2>/dev/null

Ошибки «пакет не установлен» означают отсутствие названной ветки, а не отсутствие ядра. Ubuntu HWE, облачные ядра, Oracle UEK и ядра производителя appliance могут иметь другие имена. Сначала прочитайте реально установленный список, затем выберите загрузочную ветку.

Строка 6.12.x-amd64 включает базовую версию и суффикс сборки дистрибутива. Номер ядра не обязан совпадать с upstream kernel.org. Производитель может переносить исправления в старшую поддерживаемую ветку без смены её основного номера. Решение об уязвимости принимают по установленному пакету и advisory производителя, а не только по сравнению чисел.

uname -r показывает release запущенного ядра, а не релиз Ubuntu или Debian. После обновления ядра без перезагрузки установленное и работающее ядро могут различаться.

uname -srmo
cat /proc/version

Работающее ядро и установленные пакеты

После установки нового ядра до перезагрузки uname -r продолжает показывать старое. Для Debian-family получите список установленных пакетов, для RPM-family — аналогичный перечень; выполняйте только свою ветку.

# Debian / Ubuntu
dpkg-query -W -f='${Package}\t${Version}\t${Status}\n' 'linux-image*'

# RPM-система с соответствующими kernel-пакетами
rpm -q kernel kernel-core

Строка «пакет не установлен» может означать другое семейство или имя пакета, а не отсутствие работающего ядра. Сравните uname -r с доступными образами и выбором bootloader. Не объявляйте перезагрузку безопасной до проверки консоли, резервной копии, зависимостей и окна. Vendor backport позволяет старшему номеру выглядеть «старым» при наличии исправлений; проверяйте security advisory дистрибутива.

4. Архитектура ядра и пакетного окружения

Архитектура машины, ядра и пакета

x86_64 и amd64 обычно относятся к одной 64-битной архитектуре в разных системах обозначений. aarch64 и arm64 — ещё один частый пример. Но процессор с поддержкой 64 бит может исполнять 32-битный userspace, а контейнер может использовать эмуляцию. Название архитектуры ядра не является автоматическим ответом, какой пакет скачать.

uname -m
getconf LONG_BIT
# Только в Debian-семействе:
dpkg --print-architecture
dpkg --print-foreign-architectures

getconf LONG_BIT относится к окружению утилиты и ABI, а не к модели процессора. Foreign architecture показывает дополнительные пакетные архитектуры, например для совместимости. Она не означает, что вся ОС установлена в этом формате.

Архитектура ядра и пакетной системы важна для выбора репозитория и бинарников.

uname -m
getconf LONG_BIT
dpkg --print-architecture 2>/dev/null || rpm --eval '%{_arch}' 2>/dev/null

Три архитектуры в одной системе

uname -m сообщает архитектуру работающего ядра: x86_64, aarch64 и другие. getconf LONG_BIT характеризует среду исполнения утилиты/libc и не заменяет пакетную архитектуру. Debian называет x86-64 amd64, а ARM64 arm64; эти названия отличаются от uname, но могут описывать одну платформу.

dpkg --print-architecture
dpkg --print-foreign-architectures

Дополнительная архитектура показывает возможность устанавливать пакеты другого ABI, например i386 на amd64, а не изменение ядра. В контейнере с эмуляцией CPU и multiarch нужно отдельно проверить архитектуру image и целевых бинарников. При выборе пакета ориентируйтесь на требования менеджера пакетов, а не на маркетинговое название процессора.

5. Версии программ, библиотек и пакетов

Версия приложения и версия пакета могут выглядеть по-разному

Пакет содержит версию upstream, ревизию упаковки, иногда epoch и суффикс производителя. У Debian это может быть строка вида 1:2.3.4-1+vendor1: epoch влияет на сравнение версий, 2.3.4 описывает исходную ветку, остальное — сборку. Это учебный формат, не реальная рекомендация пакета.

# Debian/Ubuntu: версия и источник выбора конкретного пакета
dpkg-query -W -f='${Package} ${Version} ${Architecture}\n' openssl
apt-cache policy openssl
# RPM: версия, выпуск и архитектура
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' openssl
# Проверка запускаемой программы
command -v openssl
openssl version

command -v помогает заметить вручную установленный бинарник в /usr/local, который не соответствует пакету из базы. Для контейнеров и приложений в виртуальном окружении это особенно важно. Обновление системного пакета не обновляет автоматически отдельный контейнерный образ или Python venv.

Пакет LSB установлен не везде. Его отсутствие не мешает читать os-release.

command -v lsb_release && lsb_release -a

Не устанавливайте пакет только ради одной проверки на аварийном сервере.

Дополнительные release-файлы и их ограничения

На старой Debian-системе пригодится /etc/debian_version, в RPM-системах — /etc/redhat-release или аналог производителя. Эти файлы дают подсказку, но могут принадлежать совместимому форку. /etc/issue, MOTD и баннер SSH редактируются администратором и не являются авторитетным источником релиза.

for release_file in /etc/debian_version /etc/redhat-release /etc/alpine-release; do
  if [ -r "$release_file" ]; then
    printf '\n%s\n' "$release_file"
    cat "$release_file"
  fi
done

При противоречиях сохраните оба результата, уточните историю major upgrade и пакет владения файлом. Не исправляйте идентификационные файлы вручную, чтобы утилита обновления «увидела нужную версию». Это не меняет реально установленные библиотеки.

6. Репозитории и проверка обновлений

Проверить наличие обновлений — не то же самое, что обновить ОС

Для обновления индексов нужен доступ к сети и изменение кеша. Для установки обновлений — отдельное решение с проверкой совместимости. В rolling-системах частичное обновление может создать несогласованный набор библиотек; не обновляйте один случайный пакет по чужой инструкции. Особенности менеджеров описаны в pacman, apk, Void Handbook и NixOS Manual.

ID_LIKE и наличие менеджера пакетов помогают выбрать инструкцию, но форки могут менять команды и репозитории.

command -v apt
command -v dnf
command -v zypper
command -v apk

Перед изменениями сверяйте официальную документацию конкретного дистрибутива.

Репозитории не определяются только наличием apt

На Debian/Ubuntu посмотрите источники APT, включая современный deb822-формат .sources:

find /etc/apt -maxdepth 2 -type f \( -name '*.list' -o -name '*.sources' \) -print
apt-cache policy

Просмотрите подходящий файл перед передачей: URL закрытого репозитория может содержать идентификатор клиента или токен. Наличие apt в контейнере означает доступность утилиты, но не подтверждает, что репозитории соответствуют релизу. При смешении stable/testing или старого и нового codename остановитесь до установки пакетов.

В RPM-системе read-only запрос dnf repolist --enabled позволяет увидеть включённые источники. Проверьте origin и vendor подписей. Установка Webmin или другого стороннего репозитория не меняет основную идентичность ОС, но меняет цепочку доверия к обновлениям.

7. Контейнер, VM, WSL и специализированная платформа

Четыре типичных сочетания, которые не являются противоречием

Контейнер Debian на Ubuntu-хосте показывает Debian в /etc/os-release и Ubuntu-сборку ядра в uname. VM Fedora на том же хосте обычно показывает собственное ядро Fedora. WSL2 использует ядро своей среды исполнения. Appliance на Debian может показывать Debian base, хотя обновлять его нужно процедурой производителя продукта.

Поэтому в отчёте пишите «userspace: Debian, environment: container, running kernel: …», а не делайте выбор одного «правильного» номера. Для OpenWrt снимите сведения system board через ubus; правильный номер прошивки без target и модели платы недостаточен для выбора образа обновления.

В контейнере os-release относится к образу, а kernel — к хосту. Поэтому сочетание «Ubuntu userspace + ядро другой системы» нормально.

systemd-detect-virt 2>/dev/null || true
cat /proc/1/cgroup
test -f /.dockerenv && echo container

Контейнер, виртуальная машина, WSL и chroot

VM имеет собственное ядро; контейнер обычно разделяет ядро хоста; chroot заменяет корень файлового дерева, но сам по себе не создаёт namespace. WSL1 и WSL2 отличаются архитектурой исполнения. Признаки в /proc/version, systemd-detect-virt и служебные файлы помогают, но один /.dockerenv не гарантирован для всех контейнерных платформ.

В Docker на управляющем хосте, имея согласованное право, сравните image и контейнер:

docker inspect --format '{{.Config.Image}} {{.Image}}' container-name
docker exec container-name cat /etc/os-release

Имя container-name замените своим. Tag вроде latest может перемещаться; для воспроизводимости важен digest/image ID. Доступ к Docker socket часто даёт полномочия уровня хоста, поэтому эти команды не предлагаются случайному пользователю контейнера как способ повысить права.

8. Поддержка релиза и условия производителя

После определения ID и VERSION_ID откройте официальный lifecycle дистрибутива. Не делайте вывод о поддержке только по номеру ядра: vendor может backport исправления.

Где проверить срок поддержки

Откройте официальный lifecycle именно производителя и редакции. Для Ubuntu различайте стандартное обслуживание, расширенное обслуживание и конкретные пакеты; для Debian — обычную поддержку, LTS и архитектурные ограничения. SUPPORT_END, если есть в os-release, полезен, но не универсален и не заменяет условия подписки.

Не пишите «ядро 5.x значит система небезопасна»: предприятия часто получают исправления с сохранением ABI. И обратный вывод «самое новое ядро значит всё поддерживается» неверен: userspace может уже быть EOL. Ubuntu — цикл релизов, Debian — информация о релизах.

9. Сбор воспроизводимого отчёта

Для заявки достаточно ОС, версии, ядра, архитектуры, виртуализации и времени загрузки. Не прикладывайте весь env, конфигурацию сети, токены или список пользователей.

printf '%s\n' "OS: $(. /etc/os-release; echo "$PRETTY_NAME")" "Kernel: $(uname -r)" "Arch: $(uname -m)"
uptime -s

Небольшой отчёт с fallback и явными неизвестными

Этот Bash-фрагмент читает только доверенный локальный os-release, не собирает окружение или конфигурации с секретами:

(
  ID=unknown; VERSION_ID=unknown; PRETTY_NAME=unknown
  if [ -r /etc/os-release ]; then
    . /etc/os-release
  elif [ -r /usr/lib/os-release ]; then
    . /usr/lib/os-release
  fi
  printf 'Captured UTC: %s\n' "$(date -u '+%Y-%m-%dT%H:%M:%SZ')"
  printf 'Distribution: %s\nID: %s\nVersion: %s\n' "$PRETTY_NAME" "$ID" "$VERSION_ID"
  printf 'Running kernel: %s\nKernel architecture: %s\n' "$(uname -r)" "$(uname -m)"
)

Скобки создают subshell: прочитанные переменные не меняют текущий интерактивный shell. unknown означает отсутствие поля, а не нулевую версию. Прикладной отчёт дополняют пакетной архитектурой и подтверждённым типом окружения. Не прикладывайте весь /proc или env только ради версии.

10. Применяем результат к установке и обслуживанию

Как должен выглядеть готовый ответ в заявке

Дистрибутив: из PRETTY_NAME и ID.
Релиз userspace: VERSION_ID или «rolling/поле отсутствует».
Кодовое имя: VERSION_CODENAME, если присутствует.
Запущенное ядро: uname -r.
Архитектура ядра и пакетов: указаны отдельно.
Окружение: physical / VM / container / WSL; основание проверки.
Версия приложения: бинарник и пакет, если задача относится к приложению.
Репозитории и поддержка: проверенный источник, дата, неизвестные условия.
Обновление: не выполнялось в рамках сбора отчёта.

Такой набор позволяет выбрать актуальную инструкцию, увидеть различия слоёв и не потерять важный факт за общим словом Linux. Если VERSION_ID отсутствует в rolling-системе, не нужно придумывать релиз по номеру ядра.

Сопоставьте релиз с репозиториями, требованиями приложения и политикой обновлений. Перед upgrade сделайте backup, проверьте место и план возврата. Точная версия — вход в план, а не разрешение на обновление.

Как применить результат и что не надо менять

Выберите руководство под найденный ID/VERSION_ID и редакцию. Перед установкой проверяйте поддерживаемую ветку, архитектуру пакета, совместимость библиотек и origin репозитория. Для major upgrade нужна отдельная процедура с backup, тестом восстановления, местом и консолью; эта статья собирает исходные факты.

Проверка версии ничего не изменяет, поэтому rollback не требуется. Если разные источники спорят, остановите зависимую установку и разберите причину: незавершённый upgrade, контейнер, повреждение пакета идентификации или кастомный image. Не подменяйте os-release. os-release — документация systemd в Debian.

Источники: os-release(5), hostnamectl(1), uname(1).