نقطه انتشار (point release) در اوبونتو چیست؟

نقطه انتشار (point release) در اوبونتو چیست

یک نقطه انتشار اوبونتو، مانند 26.04.1، همان نسخه‌ای است که هم‌اکنون در اختیار دارید، با این تفاوت که تمامی به‌روزرسانی‌های منتشرشده از زمان عرضه، در رسانه نصب جدید ادغام شده‌اند. این یک نسخه جدید نیست. آرشیوی که نصب از آن انجام می‌شود تغییر نمی‌کند و نام suite در منابع apt شما نیز ثابت می‌ماند؛ بنابراین، سروری که نصب و پچ شده است، هنگام انتشار یک نقطه انتشار جدید، هیچ فایلی برای دانلود ندارد.

در روز انتشار، دو اتفاق رخ می‌دهد. رسانه بازسازی می‌شود: فایل‌های ISO جدید و ایمیج‌های ابری جدید، بر اساس وضعیت آرشیو در آن هفته ساخته می‌شوند. همچنین رشته نسخه تغییر می‌کند: lsb_release -a شروع به گزارش 26.04.1 LTS می‌کند، در حالی که پیش از آن 26.04 LTS را گزارش می‌کرد.

همه موارد دیگر از قبل در اختیار شما بوده است. اوبونتو اصلاحات را به‌طور مداوم در مخازن -security و -updates از یک suite منتشر می‌کند، یعنی resolute برای 26.04 و noble برای 24.04. یک نقطه انتشار، در واقع تصویری لحظه‌ای از این جریان است. هیچ مقصد جداگانه‌ای برای مهاجرت وجود ندارد.

چرا سرور وصله‌شده شما چیزی برای دانلود ندارد

دلیل این است که شماره نسخه جزئی (point number) در یک بسته کوچک قرار دارد. این دستور را اجرا کنید:

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S به base-files: /etc/lsb-release پاسخ می‌دهد. بسته base-files فایل‌هایی را شامل می‌شود که رشته نسخه شما را نگه می‌دارند؛ بنابراین وقتی یک نسخه جزئی (point release) منتشر می‌شود، یک base-files جدید در مخزن -updates قرار می‌گیرد و دستور sudo apt upgrade بعدی شما آن را نصب می‌کند. آن یک بسته، تمام اثر قابل‌مشاهده یک نسخه جزئی روی ماشین در حال اجراست. هر چیز دیگری که درون آن است، هفته‌ها پیش به عنوان به‌روزرسانی‌های عادی نصب کرده‌اید.

یک روش رایج برای عقب ماندن از نسخه‌ها وجود دارد. تنظیمات پیش‌فرض /etc/apt/apt.conf.d/50unattended-upgrades، مبدأ -security را در بلوک Allowed-Origins فعال می‌کند و خط -updates را به صورت کامنت باقی می‌گذارد؛ بنابراین ماشینی که فقط از به‌روزرسانی‌های خودکار استفاده می‌کند، اصلاحات امنیتی را دریافت کرده و بقیه موارد را نادیده می‌گیرد. آن ماشین ماه‌ها شماره نسخه جزئی قدیمی‌تری را گزارش می‌دهد و این گزارش درست است، زیرا آن بسته‌ها را واقعاً در اختیار ندارد. فایل را باز کنید و ببینید کدام خطوط کامنت شده‌اند: نحوه پیکربندی unattended upgrades در اوبونتو آن بلوک را خط به خط بررسی می‌کند.

هنگامی که نسخه point release بعدی منتشر می‌شود

به‌جای تاریخ، چرخه انتشار را یاد بگیرید. اولین point release از یک نسخه LTS، چند ماه پس از انتشار نسخه اصلی در ماه آوریل عرضه می‌شود و نسخه‌های بعدی تقریباً با فواصل 6 ماهه، همگام با هر نسخه interim منتشر می‌شوند. تاریخ‌ها تغییر می‌کنند. شرکت Canonical اولین point release برای نسخه 26.04 را برای اوایل آگوست 2026 اعلام کرد و سپس آن را به تعویق انداخت؛ این یک روال عادی است و نشانه هشدار نیست. تاریخ دقیق را از صفحه چرخه انتشار Ubuntu یا یادداشت‌های انتشار 26.04 LTS دریافت کنید و به مقالات دیگر، از جمله همین مقاله، استناد نکنید.

چرا نسخه 24.04 تا زمان انتشار اولین point release به 26.04 ارتقا نمی‌یابد

زیرا اعلان ارتقا به‌گونه‌ای پیکربندی شده است که منتظر بماند؛ شما می‌توانید این پیکربندی را در سیستم خود مشاهده کنید.

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

توضیحات موجود در فایلی که همراه سیستم ارائه می‌شود، از این بخش طولانی‌تر است و ارزش خواندن کامل را دارد. مقدار Prompt=lts تنظیم پیش‌فرض در نصب LTS است و دو وظیفه دارد: پیشنهاد ارتقا را به نسخه‌های LTS محدود می‌کند و بررسی را به فهرست متفاوتی ارجاع می‌دهد.

آن فهرست در فایل دوم نام‌گذاری شده است:

cat /etc/update-manager/meta-release

مقدار URI به https://changelogs.ubuntu.com/meta-release اشاره دارد و URI_LTS به https://changelogs.ubuntu.com/meta-release-lts اشاره می‌کند. با وجود Prompt=lts، ابزار ارتقا فهرست LTS را می‌خواند و نسخه LTS جدید تا زمانی که اولین point release آن منتشر نشود، به عنوان مقصد ارتقا پیشنهاد نمی‌شود. فهرست را دریافت کنید و خودتان بررسی کنید:

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

هر نسخه شامل بلوکی از خطوط Dist:، Version:، Supported: و UpgradeTool: است. ابزار ارتقا پیش از آنکه بتواند پیشنهادی به شما ارائه دهد، به آن بلوک نیاز دارد. Canonical همین قانون را به زبان ساده در اعلامیه انتشار 26.04 LTS بیان کرده است: کاربران 24.04 LTS زمانی ارتقای خودکار را دریافت می‌کنند که 26.04.1 منتشر شود.

بنابراین در یک سرور 24.04 پیش از آن زمان:

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

این یک نتیجه سالم است، نه یک وضعیت خراب. هنگامی که مسیر باز شود، همان دستور نام نسخه را اعلام می‌کند و همان پیام در بنر ورود به سیستم ظاهر می‌شود:

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

دقت کنید که چه نسخه‌ای نام برده می‌شود. شما هرگز ابتدا به 26.04 و سپس دوباره به 26.04.1 ارتقا نمی‌دهید. شما یک‌بار ارتقا می‌دهید و مستقیماً به وضعیت فعلی 26.04 می‌رسید.

دو عامل دیگر نیز باعث می‌شوند که این بررسی نتیجه‌ای در بر نداشته باشد: Prompt=never که برخی ایمیج‌های ارائه‌دهندگان سرویس آن را تنظیم می‌کنند، و یک پروکسی یا آینه (mirror) که نمی‌تواند به changelogs.ubuntu.com دسترسی پیدا کند. پیام متفاوت Please install all available updates for your release before upgrading به این معنی است که بررسی با موفقیت انجام شده و ابزار ارتقا نیاز دارد که سیستم ابتدا کاملاً به‌روزرسانی شود. مطلب گزارش عدم یافتن نسخه جدید توسط do-release-upgrade سایر دلایل احتمالی را بررسی می‌کند. هنگامی که مسیر باز شد و شما آماده بودید، خودِ فرایند ارتقا از 24.04 به 26.04 یک کار مجزا با آمادگی‌های خاص خود است.

فلگ -d همان بررسی را به سمت فهرست توسعه (development list) هدایت می‌کند؛ این همان روشی است که افراد پیش از باز شدن مسیر رسمی، ارتقا را انجام می‌دهند. این انتظار به دلیلی وجود دارد: این بازه زمانی است که در آن مشکلات گزارش‌شده توسط کاربران پیشگام، برطرف می‌شوند. در سروری که اجاره کرده‌اید و به آن وابسته‌اید، این دلیلی برای اجازه دادن به طی شدن این دوره انتظار است.

معنای هسته Hardware Enablement در یک VPS

نسخه‌های LTS در تمام طول عمر خود از یک هسته واحد به نام GA (مخفف General Availability) استفاده می‌کنند و یک مسیر به‌روزرسانی مداوم به نام HWE (مخفف Hardware Enablement) نیز ارائه می‌دهند. مسیر HWE از طریق point releaseها عرضه می‌شود و تنها بخشی از یک point release است که واقعاً شامل کدهای جدید می‌شود، نه صرفاً بسته‌بندی مجدد آنچه قبلاً داشته‌اید.

نسخه 24.04 نمونه عملی این موضوع است. این نسخه با هسته 6.8 عرضه شد و در طول پنج سال پشتیبانی استاندارد خود، هسته 6.8 را در مسیر GA حفظ می‌کند. مسیر HWE از دومین point release آغاز شد: نسخه 24.04.2 هسته 6.11 را از Ubuntu 24.10 به همراه آورد و 24.04.3 هسته 6.14 را از Ubuntu 25.04 اضافه کرد. تا اوت 2026 این الگوی تثبیت‌شده است و 26.04 نیز از همین ساختار پیروی می‌کند.

اینکه در کدام مسیر قرار دارید، با نام یک بسته مشخص می‌شود:

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

بسته linux-generic مسیر GA است. بسته linux-generic-hwe-24.04 مسیر متغیر (rolling) است. نصب‌های دسکتاپ به‌صورت پیش‌فرض از HWE و نصب‌های سرور از GA استفاده می‌کنند، در حالی که ایمیج‌های ارائه‌دهندگان برای VPS اغلب از گزینه‌های محدودتری مانند linux-virtual یا یک نسخه خاص ابری مانند linux-kvm استفاده می‌کنند. به‌جای فرض کردن، بررسی کنید، زیرا پیش‌فرض به سازنده ایمیج شما بستگی دارد.

در سخت‌افزار مجازی اجاره‌ای، Hardware Enablement عمدتاً برای شما کاربردی ندارد. سرور شما دستگاه‌های virtio، رابط‌های شبکه و دیسک paravirtualized که هایپروایزر ارائه می‌دهد را می‌بیند و این درایورها بیش از یک دهه است که در هسته پایدار هستند. یک لپ‌تاپ جدید به HWE نیاز دارد، اما یک VPS تقریباً هرگز به آن نیاز ندارد. آنچه یک هسته جدیدتر در اینجا برای شما به ارمغان می‌آورد، قابلیت‌های هسته است: کارهای جدیدتر io_uring و eBPF، یا اصلاحاتی در سیستم فایل که دلیل خاصی برای نیاز به آن دارید. ویژگی‌های جدید در هسته لینوکس 7.1 راهی برای تصمیم‌گیری در مورد این است که آیا این تغییرات ارزش دردسرهایش را دارد یا خیر.

هزینه این کار، ریبوت‌های مکرر و ریسک است. بسته متا HWE تقریباً هر شش ماه یک هسته جدید از بالادست (upstream) دریافت می‌کند، بنابراین شما با این تناوب، یک جهش هسته و یک ریبوت را می‌پذیرید. ماژول‌های خارج از درخت (out-of-tree) که با DKMS ساخته شده‌اند، که ZFS رایج‌ترین آن‌هاست، ممکن است در ساخت با نسخه جدید شکست بخورند و شما این موضوع را هنگام بوت متوجه خواهید شد. هر هسته، نسخه قبلی خود را نیز باقی می‌گذارد که باعث پر شدن پارتیشن کوچک /boot می‌شود. پیش از آنکه به آن نیاز پیدا کنید، حذف هسته‌های قدیمی از یک پارتیشن /boot پر و انتخاب هسته‌ای که VPS شما با آن بوت می‌شود را مطالعه کنید.

انتقال به مسیر HWE تنها با یک دستور و یک ریبوت انجام می‌شود:

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

دستور uname -r پس از ریبوت باید نسخه جدیدتر را گزارش دهد. هسته قبلی را تا زمانی که هسته جدید را بوت نکرده‌اید و سرویس‌های خود را بررسی نکرده‌اید، نصب نگه دارید؛ زیرا مسیر بازیابی برای هسته‌ای که بوت نمی‌شود، انتخاب ورودی قدیمی‌تر در منوی بوت است و آن ورودی باید همچنان وجود داشته باشد. اگر وجود نداشته باشد، شما وارد محدوده بازیابی یک VPS که پس از به‌روزرسانی هسته بوت نمی‌شود خواهید شد.

یک نسخه -edge از بسته HWE نیز وجود دارد که هسته بعدی را پیش از point release دریافت می‌کند. این نسخه برای تست است. آن را روی سرور دست‌نخورده باقی بگذارید.

پاسخ پیش‌فرض برای یک سرور اجاره‌ای، هسته GA است: یک نسخه هسته برای پنج سال، با اصلاحات امنیتی که برای کل دوره به آن backport می‌شوند و بدون جهش نسخه‌ای برنامه‌ریزی‌شده. زمانی به HWE مهاجرت کنید که بتوانید دقیقاً نام قابلیتی که به آن نیاز دارید را بگویید.

چرا نصب تازه در امروز با نصب ماه گذشته متفاوت است

ایمیج‌ها (Images) بسیار بیشتر از انتشار نسخه‌های اصلی (point releases) بازسازی می‌شوند. اوبونتو ایمیج‌های ابری را با یک شماره سریال منتشر می‌کند و هر ارائه‌دهنده خدمات، قالب‌های اوبونتوی خود را طبق زمان‌بندی اختصاصی به‌روزرسانی می‌کند. بنابراین، دو سروری که با فاصله 6 ماه از یک گزینه منوی مشابه ایجاد کرده‌اید، ممکن است با نسخه‌های کرنل متفاوت بوت شوند و با نسخه‌های پکیج متفاوتی شروع به کار کنند. هیچ‌کدام از این دو وضعیت اشتباه نیست.

این موضوع اهمیت بیشتری از آنچه به نظر می‌رسد دارد. یک دستورالعمل (runbook) که می‌گوید پس از نصب، 5 دستور را اجرا کنید، به‌طور ضمنی فرض را بر وضعیتی می‌گذارد که دیگر برقرار نیست. به‌جای اعتماد به برچسبی که روی آن کلیک کرده‌اید، در هر سرور lsb_release -a و uname -r را بررسی کنید و سپس وضعیت نهایی را در قالب کد تعریف کنید تا وضعیت اولیه دیگر اهمیتی نداشته باشد. اولین Ansible playbook برای یک VPS کوچک‌ترین نسخه کاربردی از این رویکرد است.

آیا باید در زمان انتشار point release ارتقا دهید یا منتظر بمانید؟

• اگر در حال حاضر از نسخه 26.04 استفاده می‌کنید، نیازی به ارتقا نیست. به دریافت به‌روزرسانی‌ها ادامه دهید تا شماره point release به‌طور خودکار تغییر کند.
• اگر از نسخه 24.04 استفاده می‌کنید، پشتیبانی استاندارد تا آوریل 2029 ادامه دارد، بنابراین عجله‌ای برای ارتقا وجود ندارد. اولین point release یک فرصت است، نه یک ضرب‌الاجل.
• ابتدا یک نسخه کپی را ارتقا دهید. از سرور snapshot بگیرید یا همان stack را روی یک VPS موقت بازسازی کنید، ارتقا را در آنجا اجرا کنید و زمان مورد نیاز را اندازه‌گیری کنید.
• اگر به جای نسخه جدیدتر سیستم‌عامل، فقط به kernel جدیدتر نیاز دارید، مسیر HWE در نسخه 24.04 این امکان را بدون نیاز به ارتقای LTS فراهم می‌کند.

پرسش کلی‌تر درباره اینکه روی کدام نسخه باقی بمانید در بخش مقایسه LTS با نسخه‌های interim برای سرور پوشش داده شده است.

بررسی‌های لازم روی سیستم شخصی

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

یک خروجی سالم به این صورت است: lsb_release -a نسخه توزیع شما را به همراه شماره به‌روزرسانی فعلی نشان می‌دهد، uname -r با شاخه هسته‌ای که قصد استفاده از آن را دارید مطابقت دارد، Prompt=lts موجود است و بررسی یا موردی پیدا نمی‌کند یا نسخه جدیدی که ارائه خواهد شد را نام می‌برد. هر نتیجه دیگری بهتر است پیش از شروع عملیات ارتقا بررسی و درک شود، نه در حین انجام آن.

FAQ

آیا هنگام انتشار یک نسخه فرعی (point release) مانند 26.04.1 باید اقدام خاصی انجام دهم؟

خیر، تا زمانی که سرور روی آن نسخه باشد و به‌روزرسانی‌ها را دریافت کند، نیازی به اقدام نیست. یک نسخه فرعی، به‌روزرسانی‌های منتشرشده را در رسانه نصب جدید تجمیع می‌کند. یک ماشین در حال اجرا، همان محتوا را از طریق apt upgrade به‌محض انتشار دریافت می‌کند و رشته نسخه در lsb_release -a با به‌روزرسانی بسته base-files تغییر می‌یابد. هیچ نسخه جداگانه‌ای برای مهاجرت وجود ندارد و نیازی به نصب مجدد نیست.

چرا سرور من پس از اجرای apt upgrade همچنان شماره نسخه فرعی قدیمی‌تری را نشان می‌دهد؟

معمولاً به این دلیل که به‌روزرسانی‌های خودکار به اصلاحات امنیتی محدود شده‌اند. تنظیمات پیش‌فرض /etc/apt/apt.conf.d/50unattended-upgrades فقط مبدأ -security را فعال می‌کند و خط -updates را به‌صورت کامنت باقی می‌گذارد، در حالی که بسته base-files که حامل رشته نسخه است، از طریق -updates دریافت می‌شود. دستور sudo apt update && sudo apt full-upgrade را به‌صورت دستی اجرا کنید و بررسی کنید که آیا base-files در لیست ظاهر می‌شود یا خیر. اگر بسته در وضعیت kept back قرار دارد، احتمالاً چیزی مانع از به‌روزرسانی آن می‌شود (pinning یا hold).

چرا سرور 24.04 من پیشنهاد ارتقا به 26.04 را دریافت نمی‌کند؟

زیرا مقدار Prompt=lts در فایل /etc/update-manager/release-upgrades به‌صورت پیش‌فرض روی LTS تنظیم شده است و این تنظیم، لیست LTS را در https://changelogs.ubuntu.com/meta-release-lts بررسی می‌کند؛ جایی که نسخه LTS جدید تا زمان انتشار اولین نسخه فرعی (point release) به‌عنوان هدف ارتقا ارائه نمی‌شود. تا آن زمان، sudo do-release-upgrade -c عبارت No new release found. را چاپ می‌کند که رفتار درستی است. این انتظار عمدی است: این بازه زمانی برای رفع مشکلاتی است که توسط کاربران پیشگام شناسایی شده‌اند.

آیا باید هسته HWE را روی VPS خود نصب کنم؟

معمولاً خیر. هسته Hardware Enablement برای پشتیبانی از سخت‌افزارهای جدیدتر از زمان انتشار نسخه اصلی وجود دارد، در حالی که یک VPS از دستگاه‌های virtio استفاده می‌کند که درایورهای آن‌ها سال‌هاست در هسته اصلی موجود است. هسته GA در طول عمر نسخه LTS روی یک نسخه ثابت می‌ماند و اصلاحات به‌صورت backport به آن اضافه می‌شوند. زمانی هسته HWE را نصب کنید که دقیقاً بدانید به چه قابلیت خاصی در هسته نیاز دارید و بپذیرید که با این کار، تقریباً هر شش ماه یک‌بار با تغییر نسخه هسته و نیاز به reboot مواجه خواهید شد.