ترقية Ubuntu 24.04 إلى 26.04

في الخميس 27 أغسطس 2026 تُطلق Canonical إصدار أوبونتو 26.04.1، ومعه يُفتح للجميع مسار الترقية من إصدار دعم طويل الأمد إلى آخر انطلاقاً من 24.04.^[schedule] كل دليل ستجده في ذلك الأسبوع سيشرح لك أمر do-release-upgrade ثم يتوقف. وهذا الأمر ليس هو الجزء الصعب. الجزء الصعب أن أوبونتو، بين Noble Numbat وResolute Raccoon، استبدل ستة مكوّنات من النظام الأساسي تعتمد عليها أتمتة الخوادم بصمت، وأضاف شرطين ترفض أداة الترقية عندهما العمل من الأساس، وأطلق انحدارين معروفين على الخوادم موثّقين لكن لا يكاد أحد يذكرهما.

هذه هي قائمة الفحص التي أستخدمها على أجهزة حقيقية، مكتوبة لمن يشغّل أوبونتو كخادم: بلا سطح مكتب، وبلا GNOME، وبلا متجر snap. كل معلومة واقعية هنا مأخوذة من ملاحظات الإصدار الرسمية لدى Canonical ومن المشاريع الأصلية، وحيث لا تذكر الملاحظات الرسمية رقم إصدار — وحالة OpenSSL هي المثال المثير للاهتمام — لم أخترع رقماً. كل الأوامر للقراءة فقط ما لم يقل التعليق غير ذلك.

لماذا 27 أغسطس هو التاريخ المهم

لا يعرض عليك أوبونتو الإصدار التالي طويل الأمد يوم صدوره. إنه ينتظر أول إصدار نقطي لذلك الإصدار، وهو يصل بعد نحو أربعة أشهر ويمتصّ أسوأ الانحدارات المبكرة. وبالنسبة إلى 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.

ولهذا أيضاً فإن الرزنامة أقل إلحاحاً مما تبدو. يحظى أوبونتو 24.04 LTS بصيانة أمنية قياسية حتى أبريل 2029. أنت لا تُدفَع نحو حافة هاوية في 27 أغسطس؛ أنت يُفتح لك باب. الموعد النهائي الحقيقي الوحيد هو الذي تحدده لنفسك، والمعقول منه أن يكون قبل وصول الإصدار التالي، لا في الأسبوع الذي يسألك فيه مدقق الامتثال.^{[releasecycle]}

وإن كنت تحتاج إلى وقت أطول، فإن Ubuntu Pro يمدّد عمر 24.04 بصيانة أمنية موسّعة حتى أبريل 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 كل مستودع غير تابع لأوبونتو قبل أن يبدأ، ولا يعيد تفعيله بعد ذلك. هذا سلوك صحيح، ومعناه أن كل ما ثبّته من مستودع مورّد — Docker، أو PGDG الخاص بـ PostgreSQL، أو Node، أو وكيل مراقبة أداء — يتوقف عن تلقي التحديثات لحظة انتهائك، بصمت، إلى أن تعود وتوجّهه إلى توزيعة resolute.
• ملفات الإعداد المعدّلة محلياً. كل ملف منها ينتج سؤالاً تفاعلياً «أبقِ أم استبدل» في منتصف العملية. قرّر مسبقاً، وكتابةً. الإجابة الافتراضية تبقي نسختك، وهي الخيار الآمن لإعدادات التطبيقات، والخيار الخاطئ لأي شيء له علاقة بالأمن مرّ عليه عامان من التحصين في المنبع.
• المساحة الحرة على القرص. يحتاج / إلى عدة جيجابايتات حرة؛ ووجود قسم /boot صغير منفصل هو سبب الفشل الكلاسيكي، لأن dracut وعدة نوى ستملؤه فتفشل الترقية في منتصف الطريق وتترك نظاماً نصف مُعَدّ.
• هرمية cgroup ورايات المعالج. كلاهما مشروح بالتفصيل أدناه، وكلاهما شيء تريد اكتشافه الآن، لا من وحدة تحكم تسلسلية.

ما الذي تحرّك فعلياً بين الإصدارين

الأرقام العريضة أولاً، لأنها تحدد التوقعات لكل ما بعدها. عامان من تطوير أوبونتو قفزة طويلة — هذه ليست حزمة خدمة.^[ltssummary]

أحد تلك الصفوف هو الأكثر إثارة للاهتمام بهدوء. عبور OpenSSH من 9.6 إلى 10.2 يعني أن تبادل المفاتيح الهجين المقاوم للحوسبة الكمية mlkem768x25519-sha256 صار متاحاً ومفضَّلاً افتراضياً — لا مضموناً، إذ ما زال الطرف المقابل العامل بـ 9.6 يتفاوض على تبادل تقليدي — وأن دعم DSA اختفى تماماً؛ كما يكتسب OpenSSL في 26.04 دعم ML-KEM وML-DSA وSLH-DSA، وهي معايير NIST. فإن كنت تؤجّل نقاش ما بعد الكم، فهذه الترقية تحمل ذلك الترحيل في طيّاتها سواء خططت له أم لا.^{[openssh][openssl35][fips203]}

ستة إعدادات افتراضية تغيّرت من تحتك

هذا هو القسم الغائب عن كل دليل آخر، وهو سبب وجود هذا المقال. لم يكتفِ أوبونتو برفع أرقام الإصدارات: بل استبدل التطبيق البرمجي خلف ستة أشياء تكتبها أو تعتمد عليها يومياً. معظمها تحسينات. وواحد منها فقط هو الذي سيوقف الترقية توقفاً تاماً. أما البقية فستكتفي بإرباك أحد أفراد فريقك في الثالثة فجراً إن لم يدوّنها أحد.^[ltssummary]

أمر sudo صار الآن sudo-rs

أكثر سطر مفاجئ في ملاحظات إصدار 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-coreutils المكتوب بلغة Rust. لا تزال ثنائيات GNU مثبّتة تحت بادئة gnu — أي gnuls وgnudate وgnusort. والجدير بالذكر أن cp وmv وrm ما زالت من GNU داخل حزمة Rust، إذ أُبقيت كما هي بسبب علل لم تُحل بعد. وهذا هو القرار الصحيح، ومعناه أن الأدوات الأقدر على تدمير البيانات هي تحديداً التي لم تتغيّر. ويجدر أن تعرف هذا قبل أن تكوّن رأياً: تفصح ملاحظات إصدار 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 — لكن ليس على جهازك

ثالثاً، وهو الأكثر إفلاتاً من الانتباه فيما رأيت: صار chrony هو خادم الوقت الافتراضي بدلاً من systemd-timesyncd — في التثبيتات الجديدة فقط. أما خادمك المُرقّى فيحتفظ بـ timesyncd، ويستمر في العمل، ويتوقف بهدوء عن مطابقة الوثائق ومعايير التحصين وكل دليل تشغيل مكتوب بناءً على 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

وللترحيل فخّ على الضفة الأخرى. صار تجمّع خوادم الوقت الموثّق بـ NTS الخاص بأوبونتو يعيش في /etc/chrony/sources.d/ubuntu-ntp-pools.sources. فإن كنت قد حرّرت chrony.conf يوماً وتركت فيه أسطر pool أو server، فستستعلم من الخوادم نفسها مرتين — وهذا ليس قاتلاً، لكنه من النوع الذي ينتج مخرجات chronyc مربكة بعد ستة أشهر حين يحقق أحدهم في انحراف الساعة.

dracut يحلّ محل initramfs-tools

رابعاً: صار dracut هو البنية التحتية الافتراضية لصورة initramfs بدلاً من initramfs-tools. وملاحظات الإصدار دقيقة هنا، وينبغي أن نكون كذلك: يبقى 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 إطلاقاً. أزال المنبع الهرميتين القديمة والهجينة في systemd 258؛ ولا يُركَّب عند الإقلاع سوى cgroup v2. وقد حوّلت Canonical ذلك إلى بوابة صارمة بدل أن تتركه مفاجأة — وبعبارتها هي: «لن يُسمح لتثبيتات أوبونتو التي تعمل بـ 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 — أي شيء مبني على أوبونتو أقدم من 18.04 مثلاً. فافحص صور الأساس لديك، لا مضيفاتك وحدها. وبشكل منفصل، لاحظ أن 26.04 هو آخر إصدار يشغّل نصوص System V init، وهذا الموعد أقرب مما يبدو: فقد أسقط systemd 260 ذلك الدعم في المنبع بالفعل، ما يعني أن الإصدار الذي يفقده هو 26.10 في أكتوبر 2026 — لا تاريخاً مريحاً في 2028.^{[since2510][mobycgroup][systemd260]}

الإصدار الثالث من APT وإزالة apt-key

ينتقل APT من 2.7 إلى 3.1، والتغيير الذي يكسر الأتمتة هو إزالة apt-key. كان مهجوراً منذ سنوات ولا توجد طبقة توافق: التحقق من التواقيع صار يمر مباشرة عبر 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 يعبر البطاريات الميتة

يأتي أوبونتو 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 في أتمتة أجهزة الشبكات. أما الوحدات المكتوبة بلغة Python بالكامل فقد أُعيد نشرها على PyPI بأسماء تبدأ ببادئة standard-، وهذا يشتري لك دورة إصدار واحدة لإصلاح الشيفرة كما ينبغي. ولا تنسَ البيئات الافتراضية: بيئة أُنشئت مقابل ثنائي 3.12 تظل تشير إلى مفسّر تحذفه الترقية.^[py314]

قد لا يكون خادمك السحابي مدعوماً بعد الآن

تُبنى صور أوبونتو 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 الصف الأول عن جدارة: بسبب رايات الميزات فهو غير قابل للترقية مباشرة عبر هذه القفزة، وتوثّق 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]}

المشكلتان المعروفتان اللتان تعضّان الخوادم فعلاً

تنشر 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 في PostgreSQL تتراجع إلى الصفحات العادية بصمت، فالخادم المتأثر لا يبلّغ عن شيء إطلاقاً: لا خطأ ولا تحذير، مجرد أرقام أسوأ مما كانت الأسبوع الماضي. اضبط huge_pages=on عن قصد، وحدّد حجم مجمّع الصفحات الضخمة قبل ذلك، لأن 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]

وإن كنت ستمسّ نظام التهيئة والجدولة على أي حال، فإن مؤقتات systemd مقابل cron يغطي الترحيل الذي جعله هذا الإصدار متأخراً عن موعده. أما جانب SSH وTLS من الترقية فهو موضوع SSH وTLS في عصر ما بعد الكم، الذي يتعمّق فيما ينبغي التحقق منه على مستوى الاتصالات لا الحزم. وإن كان هذا المقال قد جعلك ترغب أساساً في أجزاء متحركة أقل تحتاج إلى ترقيتها، فتلك هي الحجة في معماريات سحابية مملة.

أسئلة شائعة

هل أستطيع الترقية من Ubuntu 24.04 إلى 26.04 قبل 27 أغسطس 2026؟

تقنياً نعم، عبر do-release-upgrade -d الذي يستهدف مسار الترقية التطويري. لكن لا ينبغي أن تفعل ذلك على خادم إنتاج. فالإصدار النقطي موجود تحديداً ليمتص أربعة أشهر من الانحدارات التالية للإطلاق، وفرض الترقية مبكراً يعني أنك أنت من سيكتشف علل أداة ترقية الإصدار. على حاسوب محمول تستطيع استعادته خلال ساعة، هذا تصرف معقول؛ أما على خادم يحمل حركة حقيقية فلا.

هل يجب أن أرقّي أصلاً؟ وإلى متى يُدعم 24.04؟

يحظى أوبونتو 24.04 LTS بصيانة أمنية قياسية حتى أبريل 2029، ويمدّدها Ubuntu Pro بالصيانة الأمنية الموسّعة حتى أبريل 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 في العمل بعد الترقية؟

في جميع الحالات تقريباً نعم، لأن أوبونتو 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 — كالصور المبنية على أوبونتو أقدم من 18.04 مثلاً. ففتّش في صور الأساس لديك كما تفتش في مضيفاتك.

لماذا توقف نص Python لدي عن العمل بعد الترقية؟

على الأرجح بسبب ImportError على وحدة أُزيلت في Python 3.13. فقد جاء أوبونتو 24.04 بـ Python 3.12 ويأتي 26.04 بـ 3.14، ما يعني أن هذه الترقية تعبر الإصدار الذي حذف تسع عشرة وحدة من المكتبة القياسية بموجب PEP 594. والثلاث الأكثر ظهوراً على الخوادم هي cgi وcrypt وtelnetlib. أما الوحدات المكتوبة بلغة Python بالكامل فقد أُعيد نشرها على PyPI بأسماء تبدأ ببادئة standard- كحل مؤقت. وبشكل منفصل، أي بيئة افتراضية أُنشئت مقابل ثنائي 3.12 تحتاج إلى إعادة بناء، لأن المفسّر الذي تشير إليه لم يعد موجوداً.

هل أحتاج إلى الترحيل من systemd-timesyncd إلى chrony؟

ليس بالضرورة — فـ timesyncd ما زال يعمل ويحتفظ به الخادم المُرقّى. لكن chrony هو الافتراضي في التثبيتات الجديدة لـ 26.04، فإن لم تفعل شيئاً تباعدت مضيفاتك المُرقّاة عن مضيفاتك المبنية حديثاً، وتوقف كل دليل تشغيل أو معيار تحصين مكتوب بناءً على 26.04 عن المطابقة. وتوثّق Canonical الترحيل بـ apt-mark auto systemd-timesyncd ثم apt install chrony. وإن رحّلت، فتأكد أن أي خوادم ما زالت مذكورة في chrony.conf غير مكرّرة في الملف الإضافي /etc/chrony/sources.d/ubuntu-ntp-pools.sources.

هل أستطيع التراجع إن ساءت الترقية؟

ليس بأي أداة من أدوات أوبونتو. فـ do-release-upgrade بلا تراجع، أما apt history-undo الجديد فيعيد تشغيل عمليات الحزم بدل استعادة نظام — وهو لا يعرف شيئاً عن بياناتك ولا يستطيع عكس ترقية إصدار. تراجعك الحقيقي هو لقطة للجهاز الافتراضي أو نسخة احتياطية على مستوى نظام الملفات سبق أن استعدت منها فعلاً مرة واحدة على الأقل. وإن لم تكن تملك ذلك، فأنت لا ترقّي؛ أنت تراهن برهان قيمته المتوقعة جيدة وخسارته غير محدودة.

زمن تشغيل الحاويات أسفل كل هذا تغيّر أيضًا: راجع ما الذي يتعطّل عند الانتقال إلى Docker Engine 29 للاطلاع على الحدّ الأدنى لإصدار الـ API ومخزن الصور وحدّ واصفات الملفات الذي تغيّر دون أي رسالة خطأ.

المصادر

كل ادّعاء أعلاه يعود إلى أحد هذه المصادر. ملاحظات الإصدار والجدول الزمني لدى Canonical هي المرجع لكل ما يخص أوبونتو تحديداً؛ ووثائق المشاريع الأصلية لكل ما عدا ذلك. وحيث لا تذكر الملاحظات الرسمية رقم إصدار، يصف هذا المقال القدرة الوظيفية بدل تخمين رقم.

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