Ubuntu 24.04 → 26.04 на серверах

В четверг, 27 августа 2026 года, Canonical выпускает Ubuntu 26.04.1, и вместе с ним для всех открывается путь обновления LTS → LTS с 24.04.^[schedule] Любое руководство, которое вы найдёте на той неделе, проведёт вас через do-release-upgrade и на этом закончится. Но эта команда — не сложная часть. Сложная часть в том, что между Noble Numbat и Resolute Raccoon Ubuntu заменила шесть кусков базовой системы, на которые тихо опирается вся серверная автоматизация, добавила два условия, при которых апгрейдер вообще откажется запускаться, и выпустила две известные серверные регрессии, которые задокументированы, но о них почти нигде не говорят.

Это тот чек-лист, по которому я иду на живых машинах. Он написан для тех, кто держит Ubuntu как сервер: без десктопа, без GNOME, без snap store. Все факты здесь взяты из официальных release notes Canonical и документации апстрим-проектов, а там, где официальные заметки не называют номер версии — интересный случай тут OpenSSL, — я его не выдумывал. Все команды только читают состояние, если в комментарии не сказано обратное.

Почему 27 августа — это дата, которая имеет значение

Ubuntu не предлагает вам следующий LTS в день его выхода. Она ждёт первого точечного релиза, который выходит примерно через четыре месяца и вбирает в себя худшие из ранних регрессий. Для 26.04 это 26.04.1 от 27 августа 2026 года. До этой даты сервер на 24.04 со стандартной политикой Prompt=lts совершенно правильно ответит вам, что обновляться не на что, — это не баг и не то, что нужно обходить.^{[schedule][upgradedoc]}

# Ubuntu does NOT offer one LTS to the next until the first point release.
# For 26.04 that is 26.04.1, scheduled for Thursday 27 August 2026. Before that
# date `do-release-upgrade` on a 24.04 box correctly answers "No new release".

lsb_release -a
# Description:  Ubuntu 24.04.4 LTS
# Codename:     noble

# The policy that decides what you are offered. On servers it should be `lts`.
grep -v '^#' /etc/update-manager/release-upgrades
# [DEFAULT]
# Prompt=lts

# Prompt=lts     -> next LTS, but only after ITS point release. Correct for servers.
# Prompt=normal  -> every 6-month interim release. Wrong for almost all servers.
# Prompt=never   -> never offered. Use this to pin a fleet during a change freeze.

sudo do-release-upgrade -c          # -c = check only, changes nothing
# Checking for a new Ubuntu release
# No new release found.

# You CAN force it before 27 August with `-d`, which targets the development
# upgrade path. Do not do this on a production server: -d is how you end up
# being the person who finds the release-upgrader bug, and the point release
# exists precisely to absorb the first four months of regressions.

Именно поэтому календарь давит куда меньше, чем кажется. У Ubuntu 24.04 LTS стандартная поддержка безопасности идёт до апреля 2029 года. Вас не сталкивают с обрыва 27 августа — вам открывают дверь. Единственный настоящий дедлайн тот, который вы поставите себе сами, и разумный вариант — до выхода следующего релиза, а не в ту неделю, когда о нём спросит аудитор.^{[releasecycle]}

Если нужен запас побольше, Ubuntu Pro продлевает 24.04 расширенной поддержкой ESM до апреля 2034 года. Это законная стратегия для парка, который вы сознательно замораживаете: аппаратный комплекс, изолированный контур, что-то, что и так выводится из эксплуатации. И это плохая стратегия для парка, под который вы продолжаете разрабатывать, — потому что ваш собственный тулчейн уезжает вперёд, и вы кончаете тем, что бэкпортируете вообще всё.^[pro]

Инвентаризация перед стартом, и почему она только на чтение

Всё, что ниже, выполняется на машине с 24.04, до того как вы что-либо трогаете. Скрипт ничего не пишет. Смысл не в том, чтобы получить красивый отчёт, а в том, чтобы получить вывод, который вы после обновления сравните с выводом того же скрипта, — и фраза «оно поднялось» превратится в утверждение, которое можно реально проверить.

#!/usr/bin/env bash
# noble-preflight.sh - read-only. Run it BEFORE the upgrade, save the output,
# and diff it against the same script run afterwards. Nothing here changes state.
set -uo pipefail
echo "=== identity ==="
lsb_release -ds; uname -r; systemctl --version | head -1

echo "=== 1. third-party repositories (the usual cause of a stuck upgrade) ==="
# do-release-upgrade disables these and does NOT re-enable them for you.
grep -rhs --include='*.list'    -E '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/
grep -rhs --include='*.sources' -E '^URIs' /etc/apt/sources.list.d/

echo "=== 2. packages not from the Ubuntu archive ==="
# Do NOT filter on the suite name: Docker's repo suite is literally `noble` and
# PGDG's is `noble-pgdg`, so grepping the codename hides exactly the two vendors
# you care about. Ask apt-cache policy where each package actually came from -
# in ONE invocation, because per-package calls reload the cache each time and
# turn this section into several minutes on a normal server.
#
# Set MIRROR to your own archive host if you run a local mirror, otherwise
# every package on the box gets reported as third-party and the output is noise.
# [.] rather than \. - awk processes escapes in a -v assignment and would warn.
MIRROR='archive[.]ubuntu[.]com|security[.]ubuntu[.]com|ports[.]ubuntu[.]com|archive[.]canonical[.]com'

apt-cache policy $(dpkg-query -f '${binary:Package} ' -W) 2>/dev/null | awk -v m="$MIRROR" '
  /^[a-zA-Z0-9]/ { pkg = $0; sub(/:$/, "", pkg) }
  /\*\*\*/     { getline; if ($2 !~ m && $2 != "/var/lib/dpkg/status")
                     printf "%-40s %s\n", pkg, $2 }'

echo "=== 3. held and manually installed packages ==="
apt-mark showhold
apt-mark showmanual | wc -l

echo "=== 4. locally modified config files you will be asked about ==="
# Every one of these produces a "keep or replace?" prompt mid-upgrade. Decide
# NOW, in writing, not at 02:00 with the package manager waiting on you.
debsums -ec 2>/dev/null || echo "install debsums to get this list"

echo "=== 5. services that must come back up ==="
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'

echo "=== 6. disk headroom - /boot is the one that bites ==="
df -h / /boot /var 2>/dev/null

echo "=== 7. cgroup hierarchy - a HARD upgrade blocker (see the cgroup section) ==="
stat -fc %T /sys/fs/cgroup/
# The parameter is a systemd boolean: 0/false/no/off all mean v1. Do not match
# only [01] or you will report "fine" on a host that is explicitly forced to v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline || echo "cmdline: default (v2)"

echo "=== 8. CPU capability for the AMD64v3 cloud images ==="
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo || echo "  MISSING: $f"
done

echo "=== 9. anything still using System V init scripts ==="
ls -1 /etc/init.d/ | grep -v README

Четыре раздела из этого списка стоят там не просто так: именно они превращают сорокаминутное обновление в плохую ночь:

• Сторонние репозитории. do-release-upgrade отключает каждый не-Ubuntu репозиторий перед стартом и обратно их не включает. Это правильное поведение, и оно означает, что всё, поставленное из вендорского репозитория — Docker, PGDG для PostgreSQL, Node, агент APM, — перестаёт получать обновления в ту же секунду, как вы закончили, молча, пока вы не переведёте его на суффикс resolute. Отдельно проверьте локальные зеркала: у российских и региональных зеркал ветка resolute может появиться не в день релиза, а через несколько суток после синхронизации.
• Локально изменённые конфиги. Каждый из них даст интерактивный вопрос «оставить или заменить» посреди транзакции. Решите заранее и письменно. Ответ по умолчанию оставляет вашу версию — это безопасный выбор для конфигурации приложений и неправильный для всего, что относится к безопасности и за два года получило апстримное закручивание гаек.
• Свободное место на диске. На / нужно несколько гигабайт; классический провал — отдельный маленький /boot, потому что dracut и несколько ядер его забьют, и обновление упадёт на середине с полунастроенной системой.
• Иерархия cgroup и флаги CPU. Оба пункта подробно разобраны ниже. Оба вы хотите обнаружить сейчас, а не с serial-консоли.

Что на самом деле сдвинулось между двумя релизами

Сначала заголовочные цифры, потому что они задают ожидания по всему остальному. Два года разработки Ubuntu — это длинный прыжок, а не сервис-пак.^[ltssummary]

Одна из строк таблицы тихо оказывается самой интересной. Переход с OpenSSH 9.6 на 10.2 означает, что гибридное постквантовое согласование ключей mlkem768x25519-sha256 доступно и предпочитается по умолчанию — но не гарантируется: пир на 9.6 всё равно договорится о классическом обмене, — а поддержка DSA убрана полностью. OpenSSL в 26.04 получает ML-KEM, ML-DSA и SLH-DSA — стандарты NIST. Если вы откладывали разговор про постквантовую криптографию, то это обновление приносит с собой добрую часть той миграции — независимо от того, планировали вы её или нет.^{[openssh][openssl35][fips203]}

Шесть умолчаний, которые поменяли без вас

Это тот раздел, которого нет ни в одном другом руководстве, и ради него статья и написана. Ubuntu не просто подняла версии: она заменила реализацию под шестью вещами, которые вы набираете руками или на которые полагаетесь каждый день. Большинство из них — улучшения. Только одно из них наглухо останавливает обновление. Остальные просто собьют с толку кого-то из вашей команды в три часа ночи, если никто не записал их на бумаге.^[ltssummary]

sudo — это теперь sudo-rs

Самая неожиданная строка во всех release notes 26.04: sudo-rs теперь провайдер sudo по умолчанию, а оригинальный sudo авторства Todd C. Miller переименован в пакет sudo.ws. sudo-rs — это переписанная с гарантиями безопасности памяти реализация, покрывающая то подмножество sudoers, которым реально пользуются почти все. Задокументированное поведение при встрече с тем, что она не поддерживает, — отказать с внятной ошибкой, а не проигнорировать. Направление правильное, и именно поэтому аудит нужен до, а не после: неподдерживаемая директива останавливает работу sudo — на машине, где sudo и есть способ чинить всё остальное. Отдельный короткий перечень, наоборот, принимается и игнорируется — env_reset, visiblepw, verifypw, mail_badpass, always_set_home, log_denied и ещё пара, — и ни одна из них не ослабляет доступ.^[sudors]

# 26.04 makes sudo-rs the default sudo provider. The original sudo by
# Todd C. Miller is still packaged, renamed to `sudo.ws`.

sudo --version
update-alternatives --display sudo    # which implementation is actually selected

# sudo-rs implements the sudoers subset that essentially everyone uses:
# user/group specs, host specs, NOPASSWD, Cmnd_Alias, %group, includedir.
# Its documented behaviour on something it does NOT support is to fail closed
# with a clear error, not to ignore it. That is the safe direction - but it
# means an unsupported directive stops sudo from working rather than quietly
# degrading it, so you want to find those directives before the upgrade, not
# from a locked-out root account afterwards. A short enumerated set is accepted
# and ignored instead (env_reset, visiblepw, verifypw, mail_badpass,
# always_set_home, log_denied among them); none of those loosen access.

# Resource limits and umask move to PAM; sendmail integration is simply gone.
grep -rEn 'Defaults.*(umask|rlimit|mailto|mailerpath|env_keep|logfile|SELinux|role|type)' \
     /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# Whatever you change, validate with the checker that matches your provider.
# visudo uses it automatically; run it by hand after any scripted edit.
sudo visudo -c

# --- If you find something sudo-rs will not honour ---
# Both implementations coexist; the provider is chosen through alternatives,
# so installing the package is only half the job:
sudo apt install sudo.ws
sudo update-alternatives --config sudo
# Treat this as a migration window rather than a destination: fix the sudoers
# file so you do not depend on the fallback staying available.

# --- One removal has no fallback ---
# The `sudo-ldap` package is gone. If your sudoers rules live in LDAP you must
# move that authorisation to PAM before upgrading, not after:
dpkg -l sudo-ldap 2>/dev/null | grep '^ii' && echo "ACTION REQUIRED: sudo-ldap is removed in 26.04"

Два практических замечания. Первое: обе реализации сосуществуют, а провайдер выбирается через update-alternatives, так что установить sudo.ws — это только половина отката. Второе: есть одно удаление вообще без запасного варианта — пакет sudo-ldap исчез. Если ваши правила авторизации sudo живут в LDAP, их нужно перенести на LDAP-аутентификацию через PAM до обновления — иначе вы окажетесь в системе, где правил просто нет, и, в зависимости от того, как устроены ваши пути повышения привилегий, возможно, в такой, которую не починить без консольного доступа.

ls, sort и date теперь написаны на Rust

Второй сюрприз: базовые утилиты теперь берутся из Rust-реализации rust-coreutils. GNU-бинарники по-прежнему установлены, но с префиксом gnu — gnuls, gnudate, gnusort. Примечательно, что cp, mv и rm внутри Rust-пакета остались GNU-шными: их придержали из-за нерешённых багов. Это верное решение, и оно означает, что утилиты, наиболее способные уничтожить данные, — это ровно те, которые не менялись. И то, что стоит знать до того, как вы составите мнение: в release notes 26.04 раскрыты двадцать известных CVE в rust-coreutils. Раскрыто — гораздо лучше, чем скрыто, и повода для паники здесь нет, но это значит, что базовые утилиты теперь относятся к тому, за чем вы следите при патчинге, а не к категории вещей, которые никогда не меняются.^[uutils]

# Core utilities now come from rust-coreutils (the uutils project). The GNU
# binaries are still installed, prefixed with `gnu`: gnuls, gnudate, gnusort...

ls --version | head -1        # uutils
gnuls --version | head -1     # GNU

# Worth knowing before you decide: the 26.04 release notes ship a list of
# twenty known CVEs against rust-coreutils (CVE-2026-35341 through -35377).
# That is disclosed, not hidden, and none of it is a reason to panic - but it
# is a reason to keep this package on your patching radar rather than assuming
# core utilities are the boring part of the system.

# cp, mv and rm are STILL the GNU implementations inside rust-coreutils, held
# back over unresolved bugs. So the utilities most likely to destroy data are
# the ones that did not change - which is the right call, and worth knowing
# before you go hunting for a regression in the wrong place.

# Where this actually bites: scripts that parse output, or lean on a GNU-only
# flag. Behaviour is close, not identical, and error text differs.
# Test the parsers, not the interactive use:
sort --help | grep -c . ; date --help | grep -c .

# --- Reverting, if a script you cannot change depends on GNU behaviour ---
sudo apt install coreutils-from-gnu --allow-remove-essential
# ...and back again:
sudo apt install coreutils-from-uutils --allow-remove-essential
# `--allow-remove-essential` is required because coreutils is Essential:yes.
# Read that flag as the warning it is: run it from a console you can recover,
# not over the SSH session you are about to need.

chrony вместо systemd-timesyncd — но не на вашей машине

Третье, и то, что я вижу пропущенным чаще всего: демоном времени по умолчанию вместо systemd-timesyncd стал chrony — но только для свежих установок. Ваш обновлённый сервер сохраняет timesyncd, продолжает работать и тихо перестаёт соответствовать документации, baseline'ам харденинга и любому ранбуку, написанному под 26.04. Canonical документирует ручную миграцию; за вас её никто не выполнит.^[chrony]

# Chrony replaces systemd-timesyncd as the default time daemon - but ONLY for
# fresh installs. An upgraded 24.04 server keeps timesyncd and will not tell
# you it is now off the default path. This is the change most likely to be
# missed, because nothing breaks: you just quietly stop matching the docs.

timedatectl show --property=NTP --property=NTPSynchronized
systemctl is-active systemd-timesyncd chrony 2>/dev/null

# --- The migration Canonical documents for upgraded systems ---
sudo apt-mark auto systemd-timesyncd     # demote it to an automatic dependency
sudo apt install chrony                  # installing chrony displaces timesyncd

# Verify you have exactly one time daemon running, not zero and not two:
systemctl is-active chrony
chronyc tracking
chronyc sources -v

# --- The trap, if you had ever edited chrony.conf ---
# Ubuntu's NTS-authenticated pool now lives in a separate drop-in file. If your
# old chrony.conf still lists servers, you will poll the same pool twice.
grep -E '^(server|pool)' /etc/chrony/chrony.conf
cat /etc/chrony/sources.d/ubuntu-ntp-pools.sources
# Keep the drop-in, comment out the duplicates in chrony.conf, then:
sudo systemctl restart chrony && chronyc sources -v

У миграции есть ловушка на другом берегу. Пул Ubuntu с аутентификацией NTS теперь лежит в /etc/chrony/sources.d/ubuntu-ntp-pools.sources. Если вы когда-либо правили chrony.conf и оставили там строки pool или server, вы будете опрашивать одни и те же серверы дважды. Это не смертельно, но именно из такого через полгода рождается непонятный вывод chronyc, когда кто-то придёт разбираться с расхождением часов.

dracut вместо initramfs-tools

Четвёртое: dracut стал инфраструктурой initramfs по умолчанию вместо initramfs-tools. Release notes здесь формулируют аккуратно, и нам стоит так же — initramfs-tools остаётся поддерживаемым, и между двумя реализациями можно переключаться. Что именно окажется на обновлённом хосте — это не то, что стоит додумывать по статье в блоге, включая эту. Проверьте, а потом действуйте по факту:^{[dracut][dracutconf]}

• Спросите машину, а не выводите логически. dpkg -l dracut initramfs-tools покажет, что установлено, а dracut --version — работает ли оно. Учтите, что у lsinitrd нет флага --version, так что очевидный однострочник для определения dracut даёт неверный ответ — используйте dracut --version.
• Конфигурация лежит в другом месте. Если вы всё-таки переезжаете, /etc/initramfs-tools/ перестаёт быть тем местом: dracut читает /etc/dracut.conf.d/, и любой ваш кастомный хук, список модулей или принудительно добавленный драйвер придётся переписать под него. Именно этот переписанный конфиг и есть настоящая работа, и за вас её никто не сделает.
• Осмотрите образ, а не пересобирайте его. Выведите содержимое и убедитесь, что драйверы хранилища и сети на месте — NVMe, virtio, megaraid, mpt3sas, что там нужно вашему железу или гипервизору. Пересобирать initramfs сразу после обновления релиза, на хосте, который вы ещё не перезагрузили дважды, — самое рискованное действие из всего, что описано на этой странице.

cgroup v1 больше нет, и это блокирует обновление

В systemd 259 из состава 26.04 нет cgroup v1 вообще. Апстрим удалил legacy- и гибридную иерархии ещё в systemd 258; при загрузке монтируется только cgroup v2. Canonical превратила это в жёсткие ворота, а не в сюрприз — в их формулировке: «установкам Ubuntu, работающим на cgroup v1, не будет позволено обновиться до Ubuntu 26.04 LTS». То есть режим отказа здесь — отклонённое обновление, а не убитый хост. Это хороший исход, и о нём стоит говорить точно, потому что немалая часть публикаций про это изменение намекает на обратное.^{[systemd258][cgroupv2]}

# systemd 259 in 26.04 has NO cgroup v1. The legacy and hybrid hierarchies
# were removed upstream in systemd 258; only cgroup v2 is mounted at boot.
#
# Canonical turned that into a hard gate rather than a surprise: "Ubuntu
# installations running cgroup v1 will not be allowed to upgrade to Ubuntu
# 26.04 LTS." So the failure mode is a REFUSED upgrade, not a bricked host -
# which is the good outcome, and the reason to check now is that you would
# otherwise discover it inside your maintenance window.

stat -fc %T /sys/fs/cgroup/
# cgroup2fs   -> v2, the upgrade will proceed
# tmpfs       -> v1 or hybrid, the upgrader will refuse. Fix it first.

# The parameter is a systemd boolean: 0, false, no and off all select v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline
grep -o 'systemd.legacy_systemd_cgroup_controller=[^ ]*' /proc/cmdline

# --- Fix it on 24.04, reboot, and confirm the workload still works ---
sudoedit /etc/default/grub
#   remove systemd.unified_cgroup_hierarchy=0 from GRUB_CMDLINE_LINUX*
sudo update-grub && sudo reboot
# after the reboot:
stat -fc %T /sys/fs/cgroup/     # must print cgroup2fs

# Two related consequences that are easy to miss, both from the release notes:
#   - a 26.04 CONTAINER will not run on a host still booted with cgroup v1
#   - a 26.04 HOST will not run containers that require v1 (e.g. images based
#     on Ubuntu older than 18.04). Check your base images, not just your hosts.

# --- The other systemd deadline, and it is closer than you think ---
# 26.04 is the LAST release that runs System V init scripts. systemd 260 has
# already dropped the support upstream, so the release that loses it is 26.10
# - October 2026, not some comfortable date in 2028.
ls -1 /etc/init.d/ | grep -v README
systemctl list-units --type=service --no-pager | grep -i 'LSB:'

Искать надо параметр командной строки ядра, обычно systemd.unified_cgroup_hierarchy=0, добавленный годы назад ради старого Docker, старой ноды Kubernetes или JVM-агента мониторинга — и с тех пор так и не убранный, потому что никто и ничто о нём не напоминало. Найти его лучше сейчас, а не в ночь работ, по простой причине: отказ внутри вашего окна обслуживания всё равно съедает это окно. Два побочных эффекта легко упустить: контейнер на 26.04 не запустится на хосте, всё ещё загруженном с cgroup v1, а хост на 26.04 не запустит контейнеры, которым нужен v1, — например, всё, что собрано на базе Ubuntu старше 18.04. Проверяйте базовые образы, а не только хосты. Отдельно отметьте: 26.04 — последний релиз, который вообще запускает System V init-скрипты, и этот дедлайн ближе, чем кажется: systemd 260 уже выбросил поддержку в апстриме, так что релиз, который её теряет, — это 26.10, октябрь 2026 года, а вовсе не какая-то далёкая дата в 2028-м.^{[since2510][mobycgroup][systemd260]}

APT 3 и удаление apt-key

APT переезжает с 2.7 на 3.1, и изменение, которое ломает автоматизацию, — это удаление apt-key. Он был deprecated годами, и никакой прослойки не оставили: проверка подписей теперь идёт напрямую в gpgv, и каждый репозиторий обязан назвать свой ключ. Любой скрипт провижининга, который всё ещё вызывает apt-key add, на 26.04 падает — и, поскольку этот вызов обычно стоит в начале бутстрапа, падает до того, как произойдёт хоть что-то полезное.^{[aptsecure][aptsources]}

# APT 3 in 26.04 removes `apt-key` entirely. Verification goes straight to
# gpgv, and every repository must name its key explicitly.

apt --version                       # apt 3.1.x
command -v apt-key || echo "apt-key: gone, as expected"

# Find repositories that still rely on the deleted trusted keyring. These are
# what break: not the tool, the repositories that assumed it.
ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/ 2>/dev/null

# --- The replacement: one key per repository, referenced by path ---
# Create the directory explicitly. It exists on a normal install and does NOT
# on a minimal container image, which is exactly where bootstrap scripts run.
sudo install -m 0755 -d /etc/apt/keyrings
# Dearmor the key into its own file (note .gpg for binary, .asc for armoured):
curl -fsSL https://example.com/repo.asc \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg

# Then point the repository at it. Modern deb822 format, /etc/apt/sources.list.d/example.sources:
#   Types: deb
#   URIs: https://example.com/apt
#   Suites: resolute
#   Components: main
#   Signed-By: /etc/apt/keyrings/example.gpg
#
# Or the one-line form, if you still use it:
#   deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt resolute main

sudo apt update                     # any repo you missed fails loudly here

# --- Worth knowing about, not worth planning around ---
# APT 3 adds transaction history. It replays package operations; it does not
# restore data, and it cannot undo a release upgrade.
apt history-list
sudo apt history-undo <ID>

APT 3 также приносит новый решатель зависимостей, который включается автоматически, когда классический не находит решения, и историю транзакций с apt history-undo и apt history-rollback. Прочитайте про эту историю внимательно, прежде чем на неё полагаться: она проигрывает обратно операции с пакетами. Она не восстанавливает данные, ничего не знает про вашу базу и не может отменить обновление релиза.

Python 3.12 → 3.14 проходит через «мёртвые батарейки»

Ubuntu 24.04 поставляется с Python 3.12, 26.04 — с 3.14. То есть это обновление пересекает 3.13, релиз, в котором удалили девятнадцать модулей стандартной библиотеки по PEP 594. Никакого предупреждения об устаревании вы уже не поймаете, потому что период предупреждений пришёлся на 3.11 и 3.12. Вместо него вы получаете ImportError в рантайме — в том cron-джобе, хуке или обработчике запроса, который первым дойдёт до этого импорта.^{[py313][pep594]}

# 24.04 shipped Python 3.12. 26.04 ships 3.14 as the system interpreter - so
# this upgrade crosses 3.13, the release that deleted nineteen standard-library
# modules under PEP 594. Nothing warns you: the import simply fails at runtime,
# in whichever cron job or handler happens to reach that line first.

python3 --version                   # Python 3.14.x

# Scan everything you own for the removed modules, before the upgrade. Note
# the module name is matched anywhere on an import line, not just directly
# after the keyword - otherwise `import os, cgi` slips straight through.
grep -rInE '^[[:space:]]*(import|from)[[:space:]].*\b(aifc|audioop|cgi|cgitb|chunk|crypt|imghdr|mailcap|msilib|nis|nntplib|ossaudiodev|pipes|sndhdr|spwd|sunau|telnetlib|uu|xdrlib)\b' \
  --include='*.py' /opt /srv /usr/local/lib /home 2>/dev/null

# The three that actually turn up on servers, and what to do about each:
#   cgi / cgitb -> old WSGI shims and form parsing. Move to the framework's
#                  parser, or `pip install standard-cgi` as a stopgap.
#   crypt       -> /etc/shadow hashing in provisioning scripts.
#                  Replace with `passlib` or a libxcrypt binding.
#   telnetlib   -> network-device automation. Replace with `netmiko`/`pexpect`,
#                  or better, stop using telnet.
# Pure-Python removals are republished on PyPI under `standard-*` names, which
# buys you a release cycle. It does not fix the code.

# Do not forget the interpreter under your virtualenvs: a venv created against
# 3.12 keeps pointing at a binary the upgrade removes. -xdev keeps this out of
# /proc, /sys and network mounts; -print0 survives paths with spaces.
find / -xdev -name pyvenv.cfg -print0 2>/dev/null \
  | xargs -0 -r grep -H 'version'   # rebuild every one of these afterwards

Три модуля из девятнадцати встречаются на серверах с завидной регулярностью: cgi и cgitb в старых WSGI-прослойках и хелперах разбора форм, crypt в скриптах провижининга, которые пишут хеши в /etc/shadow, и telnetlib в автоматизации сетевого оборудования. Чисто питоновские из удалённых переопубликовали на PyPI под именами с префиксом standard-, что покупает вам один релизный цикл на то, чтобы починить код по-человечески. И не забудьте про virtualenv: окружение, созданное под бинарником 3.12, продолжит указывать на интерпретатор, который обновление удаляет.^[py314]

Ваш облачный инстанс может больше не поддерживаться

Облачные образы Ubuntu 26.04 для AMD64 собраны под уровень микроархитектуры x86-64-v3. Прочитайте это слово внимательно, потому что во многих публикациях его теряют: сдвинулись именно готовые образы, а не архив. x86-64-v3 — это базовый уровень v2 плюс AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE и OSXSAVE; процессор без них попросту не может выполнить эти инструкции, так что никакого параметра ядра, который бы это смягчил, не существует.^{[ltssummary][x86levels]}

# Ubuntu 26.04 cloud IMAGES for AMD64 are built for the x86-64-v3
# microarchitecture level. Read that word carefully: it is the prebuilt images
# that moved, not the archive. The archive stays baseline x86-64, so an
# in-place upgrade still pulls baseline packages. What you lose on an old
# instance family is SUPPORT and a launchable image - not, by itself, the boot.
# That is a smaller problem than "it will not come back", and still one you
# want to solve before you build anything else on top of it.

# x86-64-v3 is the v2 baseline plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT,
# MOVBE and OSXSAVE. AVX2 is a decent proxy; the loop is the real check.
# Note `abm`: Linux exposes LZCNT under that capflag, and there is no `lzcnt`
# string in /proc/cpuinfo - grep for the obvious name and every host on earth
# reports a missing feature it actually has.
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo && echo "  $f yes" || echo "  $f MISSING"
done

# --- AWS: previous-generation families are out ---
# M1 M2 M3 M4 / C1 C3 C4 / R3 R4 / I2 / G3 / P2 P3 P3dn are no longer supported
# from 26.04. Note the [a-z]* before the dot: without it you miss p3dn and g3s,
# which are precisely two of the families you are hunting for.
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{Id:InstanceId,Type:InstanceType}' \
  --output text | grep -E '^\S+[[:space:]]+(m[1-4]|c[134]|r[34]|i2|g3|p[23])[a-z]*\.'
# The fix is a migration, not a config change: resize onto a current family
# (m6i/m7i, c6i/c7i, r6i/r7i) FIRST, then upgrade the OS.

# --- Google Cloud: N1 on Sandy Bridge or Ivy Bridge is out ---
gcloud compute instances list --format='table(name,zone,machineType,cpuPlatform)'

# --- Bare metal / on-prem: opt in only after you have checked every host ---
# The archive itself stays baseline x86-64; the v3 build is opt-in:
echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update && sudo apt upgrade

На практике всё это гораздо у́же панической версии — и всё равно требует действий. Семейства AWS предыдущих поколений больше не поддерживаются начиная с 26.04, и ни одного образа 26.04 под них не собирают. Обновление на месте через do-release-upgrade тянет базовые пакеты amd64 из архива, так что это проблема поддержки, а не автоматически проблема загрузки, — но держать неподдерживаемую комбинацию под боевой нагрузкой, на железе, против которого никто не тестирует, — не та позиция, которую выбирают осознанно. Если у вас на M3 крутится что-то важное — а у удивительно многих крутится, потому что оно исправно работает десять лет, — сначала переезжайте на актуальное семейство, и только потом обновляйте ОС. На железе и в собственных стойках руку вам никто не выкручивает вовсе: архив остаётся базовым x86-64, а сборка под v3 строго опциональна.^[awsprev]

Сервис за сервисом: у кого настоящая миграция

Подъём версий обычно проходит незаметно. Здесь собраны те случаи, где мейнтейнеры поменяли что-то, требующее действий от вас, — примерно в порядке того, насколько плохо будет, если действий не будет:

RabbitMQ заслуживает верхней строки по совокупности: из-за feature flags он напрямую через этот прыжок не обновляется, и Canonical документирует для него ручные шаги. Dovecot 2.4 переписал формат конфигурации целиком — планируйте это как отдельное изменение, а не как побочный эффект обновления ОС. HAProxy уходит с ветки 2.x на 3.2, где отвергается ключевое слово enabled для динамических серверов, строже разбираются нестандартные URI, а tune.ssl.ocsp-update переименован в tune.ocsp-update.^{[rabbitmq][dovecot24][haproxy32]}

Остальное обыденно, но не автоматично. PostgreSQL 18 требует pg_upgrade с 16-й версии; MySQL 8.0 → 8.4 LTS выбрасывает давно устаревшие опции и убирает поддержку 32-битного сервера. SSSD теперь работает от непривилегированного пользователя sssd, а не от root, — проверьте, что он по-прежнему читает свои секреты и keytab-файлы. Postfix больше не работает в chroot по умолчанию. А если у вас контроллер домена Samba Active Directory, но пакет samba-ad-dc не установлен явно, поставьте его до обновления — иначе функциональность контроллера домена не переживёт переход, а компоненты, нужные для починки, — это ровно те, которые не установились.^{[postgres18][mysql84][sssd]}

Две известные проблемы, которые реально бьют по серверам

Вместе с release notes Canonical публикует список известных проблем, и два пункта в нём конкретнее почти всего, что вообще написано про 26.04. Ни один из них не блокирует обновление. Оба меняют поведение сервера после — тихо, и так, что вы спишете это на что-то другое, если не знаете, куда смотреть. Первый — это apache2: его systemd-юнит теперь выставляет MemoryDenyWriteExecute=yes как меру харденинга, а это запрещает память, одновременно доступную на запись и на исполнение, — ровно то, что нужно JIT-компилятору. Под libapache2-mod-php это ломает JIT в PHP: в логах появляется Allocation of JIT memory failed, а падение производительности никто не связывает с обновлением ОС.^{[since2510][apachebug]}

# Both of these are in Canonical's own known-issues list for 26.04, and both
# are more concrete than most of what gets written about this release. Neither
# stops the upgrade; both change how your server behaves afterwards.

# --- 1. apache2 + mod-php: the PHP JIT stops working ---
# The apache2 systemd unit now sets MemoryDenyWriteExecute=yes as hardening.
# That forbids memory that is writable and executable at once, which is exactly
# what a JIT needs. Symptom:
#   Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled.
dpkg -l 'libapache2-mod-php*' 2>/dev/null | grep '^ii'

# Recommended fix: move to php-fpm, which is not affected. Note the a2dismod -
# without it apache2 keeps loading mod_php and the JIT stays broken, which is
# the most common way this "fix" gets applied and then reported as not working.
sudo apt install php-fpm
sudo a2dismod php8.5 && sudo a2dismod mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif && sudo a2enconf php8.5-fpm
sudo systemctl restart apache2 php8.5-fpm

# If you must stay on mod-php, override the hardening deliberately - and
# understand that you are turning off a mitigation, not fixing a bug:
sudo systemctl edit apache2
#   [Service]
#   MemoryDenyWriteExecute=no
sudo systemctl restart apache2

# --- 2. PostgreSQL on the 7.0 kernel: throughput and latency regression ---
# A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
# Systems using huge pages are NOT affected, so this is a configuration
# question rather than a wait-for-a-patch question.
sudo -u postgres psql -tAc 'SHOW huge_pages;'      # want: on

# huge_pages=try (the default) silently falls back to normal pages, which is
# how you end up affected without any error telling you so.
#
# Size the pool FIRST. PostgreSQL will compute the number for you - no
# arithmetic, no guessing at shared_buffers overhead:
sudo -u postgres postgres -D /var/lib/postgresql/18/main \
     -C shared_memory_size_in_huge_pages
# 3170
grep -E 'Hugepagesize|HugePages_Total' /proc/meminfo
sudo sysctl -w vm.nr_hugepages=3170                # use YOUR number, then
                                                   # persist it in /etc/sysctl.d/
# ...and only now turn it on:
sudo -u postgres psql -c "ALTER SYSTEM SET huge_pages = 'on';"
sudo systemctl restart postgresql
# huge_pages=on means PostgreSQL REFUSES TO START if the pages are not
# available. That is the point - it fails loudly instead of quietly slowly -
# but it means you size the pool before you flip the setting, not after.

Второй — PostgreSQL, и это тот случай, на неверный диагноз по которому я бы поставил деньги. Изменение в Linux 7.0 способно вызвать существенную регрессию пропускной способности и задержек — но системы, использующие huge pages, не затронуты, а значит это вопрос конфигурации, а не ожидания патча. Подвох в том, что дефолтное huge_pages=try молча откатывается на обычные страницы, поэтому затронутый сервер не сообщает вообще ничего: ни ошибки, ни предупреждения, просто цифры хуже, чем были на прошлой неделе. Выставьте huge_pages=on осознанно — и сначала рассчитайте размер пула huge pages, потому что on означает, что без этих страниц PostgreSQL откажется стартовать. Это правильный размен — падать громко, а не тихо тормозить, — но переключать такое в конце длинного окна обслуживания не стоит.^{[pghugepages][pgkernel][systemdexec]}

Запускаем обновление

Ничего умного ниже нет. Вся ценность — в порядке шагов и в отказе пропустить нулевой.^[upgradedoc]

# Nothing below is clever. The value is entirely in the order and in refusing
# to skip step 0.

# --- 0. A rollback you have actually tested ---
# Snapshot the VM, or take a filesystem-level backup you have restored from at
# least once. `do-release-upgrade` has no undo, and neither does apt history.
# If you cannot roll back, you are not upgrading, you are gambling.

# --- 1. Land on a fully patched 24.04 first ---
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove
sudo reboot                        # boot the newest 24.04 kernel BEFORE upgrading
uname -r

# --- 2. Survive a dropped connection ---
# The upgrade takes 20-60 minutes and will kill your shell if the link drops
# mid-transaction. do-release-upgrade opens a standby sshd on 1022 by itself;
# run it inside tmux or screen anyway.
sudo apt install tmux
tmux new -s upgrade
# detach with Ctrl-b d, reattach after a disconnect with: tmux attach -t upgrade

# --- 3. Run it ---
sudo do-release-upgrade
# Answer the config-file prompts from the list you produced in the pre-flight.
# Default is "keep your currently-installed version" (N). For sshd_config and
# anything security-relevant, take the maintainer's version and re-apply your
# changes as a drop-in afterwards - your 2019 hardening file is not better
# than the 2026 defaults.

# --- 4. Reboot and verify, in this order ---
sudo reboot
lsb_release -ds                    # Ubuntu 26.04.1 LTS
uname -r                           # 7.x
systemctl --failed                 # must be empty
journalctl -p err -b --no-pager | head -50
ss -tlnp                           # every listener you expect, and nothing new

# --- 5. Clean up what the upgrade left behind ---
sudo apt --purge autoremove        # read the list before confirming
ls /etc/apt/sources.list.d/        # re-enable third-party repos, resolute suites
dpkg -l | grep '^rc' | wc -l       # removed-but-not-purged leftovers

Одно решение стоит проговорить вслух, потому что ответ по умолчанию не всегда правильный. Когда обновление спрашивает про изменённый конфиг, оставить свою версию — безопасный выбор для конфигурации приложений и обычно неправильный для всего, что касается безопасности: ваш харденинг sshd_config от 2019 года не лучше умолчаний 2026-го. Но принимайте этот совет вместе с очевидной оговоркой. Согласившись на sshd_config мейнтейнера, вы выбрасываете заодно и свои кастомные Port, AllowUsers, PermitRootLogin или блок Match, которые жили в этом файле, — а sshd перезапустится до того, как вы их вернёте, поверх того самого соединения, через которое вы обновляетесь. Держите открытой резервную сессию на порту 1022, верните свои настоящие локальные правки отдельным файлом в sshd_config.d/, где следующее обновление их не тронет, и только после этого закрывайте первую оболочку.

Проверяем после, по-нормальному

«Оно загрузилось» — это не проверка. Этот раздел — пара к предполётному скрипту, и здесь надо быть точным в том, как ими пользоваться: два скрипта намеренно печатают разные разделы, поэтому не диффайте один против другого целиком. Напрямую сравнивать стоит два блока — список включённых сервисов и ss -tlnp: те же юниты включены, те же порты слушают. Если сервис был включён, а теперь нет, вы узнаете об этом здесь, а не когда в понедельник кто-то заведёт тикет.

#!/usr/bin/env bash
# noble-postflight.sh - the counterpart to the pre-flight script. The two print
# DIFFERENT sections on purpose, so do not diff them against each other
# wholesale. The blocks that are directly comparable are the enabled-services
# list and `ss -tlnp`: same units enabled, same ports listening.
# "It booted" is not a verification; "the same 41 services are enabled and
# listening on the same ports" is.
set -uo pipefail

echo "=== the defaults that changed under you ==="
sudo --version | head -1                    # sudo-rs, unless you reverted
update-alternatives --display sudo | head -2
ls --version | head -1                      # uutils, unless you reverted
systemctl is-active chrony systemd-timesyncd 2>/dev/null   # exactly one active
stat -fc %T /sys/fs/cgroup/                 # cgroup2fs

echo "=== which initramfs generator is this host ACTUALLY using? ==="
# Both are supported in 26.04 and either can be in place after an upgrade, so
# do not assume - ask. (lsinitrd has no --version; dracut does.)
dpkg -l dracut initramfs-tools 2>/dev/null | grep '^ii' || true
command -v dracut >/dev/null && dracut --version

echo "=== crypto, which moved a long way in two years ==="
ssh -V                                      # OpenSSH 10.2p1 in 26.04, from 9.6p1
ssh -Q kex | grep -c mlkem                  # post-quantum key agreement offered
# OpenSSL spells these with hyphens - ML-KEM-768, not mlkem - so grep for both
# or you will "prove" that a correctly configured box has no PQ support.
openssl list -kem-algorithms | grep -ciE 'ml-?kem'

echo "=== DSA host keys are gone; make sure nothing still expects one ==="
ls /etc/ssh/ssh_host_*_key 2>/dev/null
sudo sshd -t && echo "sshd config: valid"

echo "=== services ==="
systemctl --failed --no-pager
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'
ss -tlnp

echo "=== rebuild every virtualenv that pointed at python3.12 ==="
find / -xdev -name pyvenv.cfg 2>/dev/null

echo "=== the two server known-issues from the release notes ==="
# 1. apache2 now sets MemoryDenyWriteExecute=yes, which breaks the PHP JIT
#    under libapache2-mod-php. php-fpm is unaffected and is the recommendation.
dpkg -l libapache2-mod-php\* 2>/dev/null | grep -q '^ii' && \
  echo "mod-php present -> move to php-fpm, or: systemctl edit apache2 (MemoryDenyWriteExecute=no)"
# 2. A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
#    Systems using huge pages are not affected.
command -v psql >/dev/null && sudo -u postgres psql -tAc 'show huge_pages'
#    Anything other than `on` here is worth fixing before you call this done.

echo "=== boot integrity: inspect, do not regenerate ==="
# READ ONLY on purpose. Regenerating the initramfs immediately after a release
# upgrade is the riskiest thing you could do on this page; look first.
# /boot/initrd.img-* is mode 0600 root:root, hence the sudo on both branches.
if command -v lsinitrd >/dev/null; then
  sudo lsinitrd | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
elif command -v lsinitramfs >/dev/null; then
  sudo lsinitramfs /boot/initrd.img-"$(uname -r)" | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
else
  echo "neither lsinitrd nor lsinitramfs present - install the tool matching your generator"
fi

Две вещи, которые скрипт за вас не проверит. Первая — конфигурация netplan: в 26.04 едет Netplan 1.2, включая собственный systemd-networkd-wait-online, который ждёт появления маршрутизируемого интерфейса, так что хост с поздно поднимающейся сетевой картой может грузиться иначе, чем раньше. Вторая — каждый сторонний репозиторий из предполётного списка: переведите его на ветку resolute с ключом через Signed-By и убедитесь, что apt update отрабатывает чисто. Парк, который молча перестал получать обновления безопасности от вендоров, — самый тихий способ провалить это обновление.^[netplan]

Итог: сейчас, в ноябре или в 2027-м?

Мой честный совет, после того как я делал это и на аккуратных, и на запущенных парках:

1. Не обновляйтесь 27 августа. Точечный релиз существует, чтобы поглотить регрессии, но те, которые он не поймал, всплывают в следующие две недели — их находят люди с бо́льшим аппетитом к риску, чем допустимо для прода.
2. Обновите один некритичный сервер в начале сентября. Что-то достаточно настоящее, чтобы было интересно — сборочный агент, внутренний инструмент, — но за что вас не поднимут ночью. Прогоните предполётный и послеполётный скрипты и сохраните дифф. Этот дифф и есть ваш документ миграции для всего остального.
3. Сначала и везде уберите две блокировки обновления. Хосту, всё ещё загруженному на cgroup v1, и всему, что работает на IBM Z z14 или старше, апгрейдер откажет — найдите их до того, как планировать вокруг них работы. Добавьте в тот же обход семейства инстансов без AMD64v3: они не заблокированы, но держать неподдерживаемую комбинацию — это выбор, и он должен быть осознанным. Все три проверяются на 24.04 сегодня, независимо от любого решения об обновлении.
4. Остальное прогоняйте пачками в октябре и ноябре. К этому моменту у сторонних репозиториев, от которых вы зависите, появятся ветки resolute, а региональные зеркала успеют синхронизироваться — и большая часть оставшегося трения исчезнет.

И читайте страницу известных проблем, а не только сводку. Её обновляют уже после релиза — а это ровно то свойство, которое от неё и требуется: сводка говорит, что задумывалось, а список известных проблем — что случилось на самом деле.^[since2510]

Если вы всё равно лезете в init и планировщик, таймеры systemd против cron разбирает миграцию, которую этот релиз делает окончательно назревшей. SSH- и TLS-сторона обновления — тема постквантовые SSH и TLS, где речь идёт о том, что проверять на соединениях, а не в пакетах. А если после этой статьи вам в основном захотелось, чтобы обновлять приходилось меньше движущихся частей, — это ровно тот аргумент, который изложен в скучные облачные архитектуры.

Частые вопросы

Можно ли обновиться с Ubuntu 24.04 до 26.04 раньше 27 августа 2026 года?

Технически да, командой do-release-upgrade -d, которая нацелена на путь обновления для разработки. На боевом сервере так делать не нужно. Точечный релиз существует именно для того, чтобы поглотить четыре месяца послерелизных регрессий, и, форсируя обновление раньше, вы становитесь тем человеком, который находит баги в самом release-upgrader. На ноутбуке, который вы восстановите за час, это разумная затея; на сервере под реальным трафиком — нет.

Обязательно ли вообще обновляться? Сколько ещё поддерживается 24.04?

У Ubuntu 24.04 LTS стандартная поддержка безопасности идёт до апреля 2029 года, а Ubuntu Pro продлевает её через ESM до апреля 2034-го. Никакой срочности в августе 2026 года нет. Причина обновляться в том, что вперёд уезжает ваш собственный тулчейн — более новый Python, более новый PostgreSQL, более новые рантаймы языков, — и, оставаясь на месте, вы рано или поздно начинаете бэкпортировать всё самостоятельно. Заморозка — законный выбор для аппаратного комплекса или парка, который выводится из эксплуатации, и плохой выбор для платформы, на которой вы продолжаете строить.

Какое одно изменение с наибольшей вероятностью съест мне окно обслуживания?

Забытый параметр ядра systemd.unified_cgroup_hierarchy=0. В systemd 259 нет cgroup v1 вообще, и Canonical сделала из этого жёсткие ворота: хосту, всё ещё загруженному на cgroup v1, обновляться не позволено. Вы получаете не сломанную машину — вы получаете отказ ровно в тот момент, когда заложили час простоя. Второе место занимает регрессия PostgreSQL на ядре Linux 7.0, потому что она, в отличие от первой, вообще не выдаёт ошибки — просто цифры хуже. И то и другое проверяется меньше чем за минуту на 24.04 уже сегодня, до того как вы зафиксируете дату.

Безопасно ли использовать sudo-rs в продакшене?

Да — для той конфигурации sudoers, которая реально есть у подавляющего большинства систем: спецификации пользователей и групп, спецификации хостов, NOPASSWD, алиасы команд, includedir. Аккуратность нужна на краях. sudo-rs реализует не весь набор записей Defaults; лимиты ресурсов и umask переезжают в PAM, интеграция с sendmail отсутствует. Задокументированное поведение при встрече с неподдерживаемой директивой — отказать с внятной ошибкой, а не проигнорировать её: направление безопасное, но это значит, что непроверенная директива может остановить работу sudo на машине, где sudo и есть способ чинить всё остальное. Отдельный короткий перечень, наоборот, принимается и игнорируется, и ни один пункт в нём не ослабляет доступ. Проверьте файл до обновления. Если откатиться всё-таки нужно, обе реализации сосуществуют: поставьте sudo.ws и выберите его через update-alternatives --config sudo — установка одного пакета провайдера не меняет.

Будут ли мои Docker-контейнеры работать после обновления?

Почти во всех случаях да, потому что Ubuntu 24.04 уже по умолчанию использует cgroup v2, а современный Docker поддерживает v2 много лет. Исключение — хост, где кто-то раньше выставил systemd.unified_cgroup_hierarchy=0 в командной строке ядра ради старого Docker или ноды Kubernetes: такому хосту в обновлении отказывают напрямую. Проверьте stat -fc %T /sys/fs/cgroup/ — он должен вывести cgroup2fs. Два смежных ограничения легко упустить. Контейнер на 26.04 не запустится на хосте, всё ещё загруженном с cgroup v1, а хост на 26.04 не запустит контейнеры, которым нужен v1, — например, образы на базе Ubuntu старше 18.04. Так что проверяйте не только хосты, но и свои базовые образы.

Почему мой Python-скрипт перестал работать после обновления?

Скорее всего, это ImportError на модуле, удалённом в Python 3.13. В Ubuntu 24.04 был Python 3.12, в 26.04 — 3.14, поэтому обновление пересекает релиз, в котором по PEP 594 удалили девятнадцать модулей стандартной библиотеки. Чаще всего на серверах встречаются три: cgi, crypt и telnetlib. Чисто питоновские удалённые модули переопубликовали на PyPI под именами с префиксом standard- как временное решение. Отдельно: любое виртуальное окружение, созданное под 3.12, нужно пересоздать, потому что интерпретатора, на который оно указывает, больше нет.

Нужно ли переходить с systemd-timesyncd на chrony?

Строго говоря, нет: timesyncd работает, и обновлённый сервер его сохраняет. Но chrony — умолчание для свежих установок 26.04, поэтому, если ничего не делать, обновлённые хосты и новые хосты начнут расходиться, а каждый ранбук или baseline харденинга, написанный под 26.04, перестанет совпадать с реальностью. Canonical описывает миграцию как apt-mark auto systemd-timesyncd, затем apt install chrony. Если мигрируете, проверьте, что серверы, оставшиеся в chrony.conf, не дублируются drop-in файлом /etc/chrony/sources.d/ubuntu-ntp-pools.sources.

Можно ли откатиться, если обновление пошло не так?

Штатными средствами Ubuntu — нет. У do-release-upgrade нет отмены, а новая команда apt history-undo проигрывает обратно операции с пакетами, а не восстанавливает систему: она ничего не знает про ваши данные и не может обратить обновление релиза. Ваш откат — это снапшот виртуальной машины или бэкап на уровне файловой системы, из которого вы хотя бы раз реально восстанавливались. Если такого нет, вы не обновляетесь, а играете в игру с хорошим матожиданием и неограниченным убытком.

Контейнерный рантайм под всем этим тоже сдвинулся: в статье про что ломается при переходе на Docker Engine 29 разобраны минимальная версия API, хранилище образов и лимит файловых дескрипторов, который изменился без единого сообщения об ошибке.

Источники

Каждое утверждение выше восходит к одному из этих источников. Release notes и график релизов Canonical — авторитет по всему, что специфично для Ubuntu; документация апстрим-проектов — по всему остальному. Там, где официальные заметки не называют версию, статья описывает возможность, а не угадывает номер.

1. Canonical — Ubuntu 26.04 LTS (Resolute Raccoon) release notes; released 23 April 2026, supported until April 2031
2. Canonical — Ubuntu 26.04 LTS summary for LTS users: the authoritative list of changes since 24.04, and the source for every default swap described here
3. Canonical — Ubuntu 26.04 LTS changes since 25.10, including the known-issues list and the cgroup v1 removal detail
4. Canonical — Resolute Raccoon release schedule; the 26.04.1 point release is listed for Thursday 27 August 2026
5. Ubuntu Server documentation — How to upgrade your release (do-release-upgrade, the -d flag, and the LTS-to-LTS point release rule)
6. Canonical — Ubuntu 24.04 LTS (Noble Numbat) release notes, the baseline this article upgrades from
7. Canonical — Ubuntu release cycle: LTS cadence, five years of standard support, ESM through Ubuntu Pro
8. Canonical — Ubuntu Pro documentation (ESM, Livepatch, and the ten-year maintenance window on 24.04)
9. Trifecta Tech Foundation — sudo-rs, the memory-safe sudo and su implementation that is now Ubuntu's default sudo provider
10. uutils/coreutils — the Rust reimplementation of the GNU core utilities shipped as rust-coreutils
11. systemd v258 release notes — removal of cgroup v1 (legacy and hybrid hierarchies) and the raised kernel baseline
12. systemd NEWS — the upstream changelog covering v256 through v259, including the System V compatibility deprecation
13. Linux kernel documentation — Control Group v2, the only hierarchy systemd still mounts
14. moby/moby #51111 — Docker's cgroup v1 deprecation discussion and support timeline
15. apt-secure(8) — repository signing after the removal of apt-key, and the Signed-By mechanism that replaces it
16. sources.list(5) — the deb822 .sources format and the Signed-By field
17. dracut(8) — the initramfs infrastructure that replaces initramfs-tools as Ubuntu's default
18. dracut.conf(5) — configuration in /etc/dracut.conf.d/, including hostonly and the drivers to force-include
19. chrony.conf(5) — the configuration file, source directories and NTS options for Ubuntu's new default time daemon
20. What's New In Python 3.13 — the release that removed the nineteen PEP 594 'dead battery' standard-library modules
21. PEP 594 — Removing dead batteries from the standard library; the full list of removed modules and their replacements
22. What's New In Python 3.14 — the interpreter Ubuntu 26.04 ships as the system Python
23. OpenSSL 3.5 series release notes — ML-KEM, ML-DSA and SLH-DSA support and the default hybrid TLS groups
24. OpenSSH release notes index — covers the 9.6 to 10.2 range that this upgrade crosses, including DSA removal
25. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), the algorithm behind the new OpenSSL and OpenSSH defaults
26. AWS — previous generation EC2 instances; the families that lose Ubuntu support because of the AMD64v3 cloud image baseline
27. x86-64 microarchitecture levels — what x86-64-v3 requires (AVX2, BMI1/2, FMA, MOVBE)
28. RabbitMQ — upgrade documentation and feature flags, the reason RabbitMQ is not directly upgradable across this release
29. Dovecot — upgrading from 2.3 to 2.4, the release that rewrote the configuration format (26.04 ships 2.4.2)
30. HAProxy 3.2 configuration manual — the breaking changes since the 2.x series shipped in 24.04
31. PostgreSQL 18 release notes — the major version 26.04 ships, requiring pg_upgrade from 16
32. MySQL 8.4 LTS release notes — the series replacing 8.0, including removed deprecated options
33. Netplan 1.2 documentation — the series shipped in Ubuntu 26.04
34. SSSD 2.10 release notes — the change that makes the daemon run as the unprivileged sssd user rather than root
35. systemd v260 release notes — System V service script support already dropped upstream, which is why 26.10 is the release that loses it
36. PostgreSQL documentation — the huge_pages configuration parameter, the documented mitigation for the Linux 7.0 regression
37. PostgreSQL documentation — configuring Linux huge pages for the server
38. LP #2144455 — apache2's MemoryDenyWriteExecute hardening breaking the PHP JIT under libapache2-mod-php
39. systemd.exec(5) — MemoryDenyWriteExecute=, the hardening directive apache2 now sets by default