رفع مشکل شکست ارتقای Ubuntu 24.04 به 26.04

شکست در ارتقای Ubuntu: ابتدا علائم را بررسی کنید

شکست در ارتقای نسخه Ubuntu از 24.04 به 26.04، سرور را در یکی از چهار وضعیت قرار می‌دهد و هر وضعیت راهکار متفاوتی دارد. ممکن است فرآیند ارتقا همچنان در یک نشست screen که ارتباط شما با آن قطع شده، در حال اجرا باشد. ممکن است dpkg در حین پیکربندی ناقص یک بسته متوقف شده باشد و به همین دلیل apt از نصب، حذف یا ارتقای هر بسته دیگری خودداری کند، اگرچه apt update و دستورات فقط‌خواندنی مانند apt show همچنان اجرا می‌شوند. ممکن است منابع apt به نسخه 26.04 اشاره کنند در حالی که بسته‌های نصب‌شده همچنان مربوط به 24.04 هستند. یا ممکن است سرور اصلاً بوت نشود. پیش از تایپ هر دستوری، مشخص کنید در کدام وضعیت هستید، زیرا راهکار یک وضعیت ممکن است وضعیت دیگر را وخیم‌تر کند.

یک قانون کلی برای هر چهار وضعیت وجود دارد: تا زمانی که از وضعیت dpkg مطلع نشده‌اید، سیستم را reboot نکنید. reboot کردن در میانه جایگزینی بسته‌ها، همان عاملی است که یک وقفه قابل‌حل در dpkg را به وضعیت «عدم بوت» در انتهای این راهنما تبدیل می‌کند. همچنین، تا زمانی که احتمال می‌دهید فرآیند اول زنده باشد، فرآیند دوم apt یا dpkg را شروع نکنید، زیرا نوشتن همزمان دو فرآیند روی دیتابیس بسته‌ها باعث خرابی دیتابیس می‌شود.

این راهنما فرض می‌کند که شما راهنمای ارتقا از 24.04 به 26.04 را دنبال کرده‌اید و پیش از شروع، یک snapshot تهیه کرده‌اید. اگر این کار را انجام نداده‌اید، بخش مربوط به بوت را با در نظر گرفتن این موضوع مطالعه کنید، چرا که snapshot پاسخ نهایی برای بدترین سناریو است.

آیا ارتقا هنوز در حال اجراست؟

بسیاری از ارتقاهایی که به عنوان شکست‌خورده گزارش می‌شوند، در واقع هنوز در حال اجرا هستند. نشست SSH قطع شده، ترمینال خالی مانده و ابزار ارتقا بدون حضور شما به کار خود ادامه داده است.

do-release-upgrade برای همین منظور ساخته شده است. وقتی این ابزار با رابط متنی خود اجرا می‌شود (که در سرورها پیش‌فرض است)، خود را درون یک نشست GNU screen قرار می‌دهد تا ارتقا از قطع شدن ترمینالی که آن را آغاز کرده، جان سالم به در ببرد. همچنین، وقتی تشخیص دهد که از یک نشست SSH آغاز شده، پیشنهاد می‌دهد که یک sshd دوم روی پورت دیگری (به‌طور پیش‌فرض 1022) باز کند تا اگر سرویس اصلی SSH در حین تعویض بسته‌ها دچار مشکل شد، همچنان بتوانید وارد سیستم شوید. هر دوی این موارد اکنون اهمیت دارند.

از طریق SSH دوباره متصل شوید و به دنبال نشست screen بگردید. ابزار ارتقا تحت sudo اجرا شده است، بنابراین نشست screen آن متعلق به root است و دستور screen -ls ساده با کاربری معمولی شما آن را فهرست نمی‌کند.

sudo screen -ls

screen -ls هر نشست را به عنوان متصل (attached) یا جداشده (detached) علامت‌گذاری می‌کند. اگر نشستی فهرست شد، دوباره به آن متصل شوید. اگر به دلیل قطع شدن اتصال SSH، نشست همچنان به عنوان متصل علامت‌گذاری شده است، -d ابتدا آن اتصال قدیمی را جدا می‌کند.

sudo screen -d -r

اگر بیش از یک نشست فهرست شده است، نام نشست را از screen -ls بعد از -r وارد کنید. برای اتصال مجدد به sudo do-release-upgrade تکیه نکنید. کدی که نشست screen موجود را پیدا می‌کند در همان ابزار ارتقایی است که دانلود می‌شود، و پیش از دانلود هر چیزی، do-release-upgrade هر زمان که بسته‌ای با ارتقای معلق پیدا کند (به‌جز به‌روزرسانی‌های مرحله‌بندی‌شده)، با پیام "Please install all available updates for your release before upgrading" خارج می‌شود؛ این دقیقاً وضعیت سیستمی است که در نیمه راه تعویض بسته‌ها قرار دارد. پس از اتصال مجدد، به محیط ارتقای در حال اجرا بازمی‌گردید که معمولاً منتظر پاسخ شما درباره یک فایل پیکربندی تغییریافته یا راه‌اندازی مجدد یک سرویس است. به آن پاسخ دهید و اجازه دهید کار به پایان برسد.

اگر ارتقا را درون tmux آغاز کرده‌اید (همان‌طور که راهنمای ارتقا توصیه می‌کند)، ابتدا با tmux attach به tmux متصل شوید. نشست screen درون آن پنل tmux در حال اجراست، بنابراین ارتقا را مستقیماً مشاهده می‌کنید. اگر پنل فقط یک اعلان shell را نشان می‌دهد، ابزار ارتقا دیگر در آنجا در حال اجرا نیست و sudo screen -ls بررسی بعدی است.

اگر پورت اصلی SSH اتصال را رد کرد، پورت جایگزین را امتحان کنید: ssh -p 1022 user@host. آن daemon فقط تا پایان عمر ارتقا وجود دارد، بنابراین اگر نتوانستید از هیچ‌کدام از پورت‌ها وارد شوید، از کنسول ارائه‌دهنده خود استفاده کنید. از طریق کنسول، sudo ss -ltnp نشان می‌دهد که یک پروسه sshd روی چه پورت‌هایی گوش می‌دهد و sudo ufw status به شما می‌گوید که آیا فایروال اجازه عبور از پورت جایگزین را داده است یا خیر.

وقتی هیچ نشست screen وجود ندارد و چیزی در کنسول منتظر پاسخ نیست، ارتقا واقعاً متوقف شده است. پیش از دست زدن به پایگاه داده بسته‌ها، مطمئن شوید که هیچ چیزی در حال کار نیست:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

نتیجه خالی به این معنی است که dpkg بیکار است و می‌توانید برای تعمیر آن اقدام کنید. یک پروسه dpkg یا apt با زمان اجرای طولانی که هیچ نشست screen برای اتصال مجدد ندارد، هنگ کرده است. چند دقیقه صبر کنید، کنسول را برای یافتن سوال debconf که کسی به آن پاسخ نداده بررسی کنید و تنها پس از آن، پروسه را بکشید. هرگز فایل‌های قفل را در /var/lib/dpkg/ یا /var/lib/apt/lists/ در حالی که پروسه‌ای آن‌ها را در اختیار دارد، حذف نکنید. این قفل تنها مانع موجود برای جلوگیری از نوشتن همزمان دو پروسه و خرابی پایگاه داده بسته‌هاست.

وقفه در اجرای dpkg و امتناع apt از ادامه کار

هنگامی که اجرای dpkg بین مرحله بازگشایی (unpacking) یک بسته و اجرای اسکریپت پیکربندی آن متوقف می‌شود، آن بسته در وضعیت «نیمه‌کاره» باقی می‌ماند و ورودی‌های ناتمامی در ژورنال آن در مسیر /var/lib/dpkg/updates/ ایجاد می‌شود. هر دستور apt که قفل dpkg را در اختیار می‌گیرد—یعنی هر دستوری که برای نصب، حذف یا ارتقا استفاده می‌شود—ابتدا آن ژورنال را بررسی کرده و با خطای dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. متوقف می‌شود. دستوراتی که این قفل را نمی‌گیرند، مانند apt update، apt list، apt show و apt-cache، همچنان کار می‌کنند و می‌توانید از طریق آن‌ها وضعیت سیستم را بررسی کنید. فارغ از اینکه apt چه پیام خطایی نمایش می‌دهد، اولین قدم همیشه یکسان است.

sudo dpkg --configure -a

این دستور مرحله پیکربندی را برای تمام بسته‌هایی که بازگشایی شده اما پیکربندی نشده‌اند، به پایان می‌رساند. این دستور اسکریپت‌های نگهدارنده (maintainer scripts) را به ترتیب وابستگی اجرا می‌کند و ممکن است در سیستم‌هایی که ارتقای آن‌ها نیمه‌کاره مانده، زمان زیادی طول بکشد؛ بنابراین تا زمانی که دستور به پایان نرسیده، آن را متوقف نکنید. اگر روند روی یک بسته متوقف شد، نام بسته و اسکریپتی که با خطا مواجه شده نمایش داده می‌شود. آن نام را یادداشت کنید. این همان بسته‌ای است که مانع ارتقای شما شده و بخش بعدی نحوه خواندن خطای آن را توضیح می‌دهد.

سپس اجازه دهید apt وابستگی‌هایی را که به دلیل این وقفه ناقص مانده‌اند، تعمیر کند؛ زیرا برخی بسته‌ها ارتقا یافته‌اند اما بسته‌های وابسته به آن‌ها ارتقا نیافته‌اند.

sudo apt --fix-broken install

سپس ارتقایی را که در میانه آن وقفه ایجاد شده بود، به پایان برسانید:

sudo apt update
sudo apt full-upgrade

از full-upgrade به جای upgrade استفاده کنید، زیرا ارتقای نسخه (release upgrade) نیاز به حذف بسته‌ها دارد و دستور ساده upgrade از حذف هرگونه بسته خودداری می‌کند. پیش از تأیید، خلاصه‌ای که apt نمایش می‌دهد را مطالعه کنید. وجود یک لیست کوتاه از موارد حذفی طبیعی است. اما لیستی که شامل ubuntu-server، systemd، openssh-server یا بسته هسته (kernel) شما باشد، طبیعی نیست؛ در این صورت باید پاسخ منفی دهید و پیش از ادامه، دلیل اصرار apt بر حذف آن‌ها را بررسی کنید.

پیش از انجام هر کار دیگری، نتیجه را بررسی کنید:

sudo dpkg --audit
sudo apt-get check

دستور dpkg --audit تمام بسته‌هایی که هنوز در وضعیت خراب هستند را لیست می‌کند و apt-get check وابستگی‌های برآورده‌نشده را گزارش می‌دهد. هر دو دستور باید خروجی خالی داشته باشند. پس از اطمینان، دستور sudo apt autoremove را اجرا کنید تا وابستگی‌هایی که به‌طور خودکار نصب شده‌اند و دیگر به آن‌ها نیازی نیست حذف شوند (بسته‌هایی که به‌صورت دستی نصب شده‌اند باقی می‌مانند، حتی اگر هیچ بسته‌ای از آن‌ها استفاده نکند). سپس نسخه را با cat /etc/os-release تأیید کنید، دستورات sudo update-initramfs -u -k all و sudo update-grub را اجرا کنید و تنها پس از آن سیستم را reboot کنید.

نحوه خواندن /var/log/dist-upgrade برای یافتن بسته‌ای که باعث توقف شده است

ابزار ارتقا تمام وقایع را در /var/log/dist-upgrade/ می‌نویسد. اگر بیش از یک بار آن را اجرا کرده باشید، لاگ‌های تلاش‌های قبلی به زیرپوشه‌ای با نام زمان‌بندی (timestamp) منتقل می‌شوند؛ بنابراین ابتدا ls -la /var/log/dist-upgrade/ را بررسی کنید و دایرکتوری مربوط به اجرای ناموفق را بخوانید.

فایل main.log دفترچه خاطرات خودِ ابزار ارتقا است. این فایل ثبت می‌کند که ارتقا در کدام مرحله بوده و چه تصمیمی درباره مخازن (sources) شما گرفته است. اگر خودِ ابزار ارتقا کرش کرده باشد، ردپای خطای پایتون (traceback) نیز در اینجا قرار دارد. آن را از انتها بخوانید: خطوط آخر به شما می‌گویند که در زمان توقف، ارتقا در چه مرحله‌ای بوده است. وجود traceback در اینجا به معنای خرابی خودِ ابزار است، نه یک بسته خاص.

فایل apt.log حاوی استدلال‌های حل‌کننده وابستگی (dependency resolver) است. این فایل بسیار پرجزئیات است و زمانی اهمیت دارد که apt از محاسبه ارتقا امتناع کرده باشد، که این یعنی شکست پیش از دست‌کاری هر بسته‌ای. اگر ارتقای شما تا مرحله نصب بسته‌ها پیش رفته است، معمولاً می‌توانید از این فایل صرف‌نظر کنید.

فایل apt-term.log فایلی است که برای خطای بسته‌ها به آن نیاز دارید. این فایل خروجی ترمینال dpkg را در طول ارتقا ضبط می‌کند، همان متنی که در صفحه نمایش شما عبور کرده است. آخرین بسته‌ای که پیش از پایان فایل ذکر شده، همان بسته‌ای است که در زمان توقف ارتقا در حال اجرا بوده است. اگر اسکریپت نگهدارنده با خطا مواجه شده باشد، شکایت dpkg از آن اسکریپت دقیقاً در همان‌جا و درست بالای خطای خودِ اسکریپت قرار دارد.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

این اطلاعات را با /var/log/dpkg.log تطبیق دهید که تغییرات وضعیت و اقداماتی که dpkg انجام می‌دهد را به همراه زمان‌بندی ثبت می‌کند. فایل tail -n 30 /var/log/dpkg.log آخرین بسته‌ای که dpkg با آن کار کرده و عملیاتی که روی آن انجام داده را نشان می‌دهد. این پاسخ از منبع دوم تنها در صورتی معتبر است که پس از بروز خطا، هیچ دستور دیگری dpkg را اجرا نکرده باشد. به محض اینکه dpkg --configure -a یا apt --fix-broken install را اجرا کنید، ورودی‌های آن‌ها در انتها قرار می‌گیرند، بنابراین به خطوطی برگردید که زمان‌بندی آن‌ها با زمان توقف ارتقا مطابقت دارد.

بیشتر خرابی‌ها در این مرحله روی سرور، ناشی از چند دلیل محدود است. سرویسی که بسته در مرحله postinst مجدداً راه‌اندازی می‌کند، به دلیل فایل پیکربندی که شما شخصی‌سازی کرده‌اید بالا نمی‌آید؛ دستورات systemctl status و journalctl -xeu روی آن سرویس، خطی که مورد پذیرش نیست را مشخص می‌کنند. دیسک پر شده است، که معمولاً به دلیل /boot با هسته‌های قدیمی یا /var با کش بسته‌های apt است؛ دستور df -h / /boot /var این موضوع را نشان می‌دهد. دستور sudo apt clean کش را حتی زمانی که apt در وضعیت گیر کرده قرار دارد، خالی می‌کند و دیسکی که با وجود فضای خالی، پر گزارش می‌شود توضیح خاص خود را دارد. بسته‌ای از یک مخزن شخص ثالث که توسط ابزار ارتقا غیرفعال شده، به کتابخانه‌ای وابسته است که در نسخه 26.04 دیگر ارائه نمی‌شود. یک بسته نگه‌داشته‌شده (apt-mark showhold) مانع از تغییر یک وابستگی شده است. دلیل را رفع کنید و سپس دوباره sudo dpkg --configure -a را اجرا کنید. این دستور از همان‌جایی که متوقف شده، ادامه می‌دهد.

اگر یک بسته با وجود تمام تلاش‌ها پیکربندی نمی‌شود و هیچ بسته مهمی به آن وابسته نیست، آن را حذف کرده و پس از تکمیل ارتقا، دوباره نصب کنید:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

از این دستور فقط برای بسته‌ای استفاده کنید که نام آن را می‌دانید و دلیل حذفش را می‌فهمید. هرگز آن را برای یک کتابخانه یا هر چیزی که در زنجیره وابستگی ubuntu-server قرار دارد به کار نبرید، زیرا حذف اجباری (forced removal) بررسی‌هایی که به شما می‌گوید چه چیز دیگری ممکن است خراب شود را نادیده می‌گیرد.

منابع تغییر کرده‌اند اما بسته‌ها به‌روز نشده‌اند

ابزار ارتقا، منابع apt شما را در مراحل اولیه و پیش از دانلود هرگونه بسته‌ای بازنویسی می‌کند. اگر فرایند پس از این مرحله متوقف شود، منابع به نسخه 26.04 اشاره می‌کنند در حالی که بسته‌های نصب‌شده ترکیبی از دو نسخه هستند. این ترکیب ابزارها را دچار سردرگمی می‌کند و به همین دلیل است که do-release-upgrade ممکن است اکنون اصرار داشته باشد که هیچ نسخه جدیدی وجود ندارد.

دو مکانی که نسخه فعلی سیستم شما را توصیف می‌کنند، با هم مقایسه کنید. /etc/apt/sources.list.d/ubuntu.sources فایل منابع deb822 است که در 24.04 معرفی شد و خطوط Suites: آن حاوی نام رمز (codename) نسخه هستند. فایل /etc/os-release توسط بسته base-files نوشته می‌شود و نشان می‌دهد که در حال حاضر کدام نسخه نصب شده است.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

سه ترکیب اهمیت دارند. منابع هنوز به 24.04 (نام رمز noble) اشاره دارند و os-release نیز 24.04 را نشان می‌دهد: ارتقا هرگز از بررسی‌های اولیه عبور نکرده است؛ می‌توانید پس از مطالعه main.log برای یافتن علت توقف، دوباره sudo do-release-upgrade را اجرا کنید. این ابزار تا زمانی که به‌روزرسانی معلقی برای 24.04 وجود داشته باشد، یا /var/run/reboot-required.pkgs به libc6، linux-base یا یک بسته linux-image اشاره کند، از شروع کار خودداری می‌کند؛ بنابراین ابتدا sudo apt full-upgrade را اجرا کرده و در صورت درخواست فایل، سیستم را ریبوت کنید. منابع به نام رمز 26.04 اشاره دارند و os-release هنوز 24.04 را نشان می‌دهد: فرایند جایگزینی بسته‌ها آغاز شده و قطع شده است؛ تعمیر dpkg در بخش قبلی که با apt full-upgrade پایان می‌یابد، راه تکمیل آن است. در این وضعیت، ابزار ارتقا را دوباره اجرا نکنید؛ زیرا با وجود بسته‌های 26.04 در انتظار، متوقف شده و از شما می‌خواهد ابتدا تمام به‌روزرسانی‌های موجود را نصب کنید. منابع به 26.04 اشاره دارند و os-release نیز 26.04 را نشان می‌دهد: base-files یکی از بسته‌هایی بوده که با موفقیت نصب شده و سیستم اکنون خود را 26.04 می‌نامد، حتی اگر بخش بزرگی از آن هنوز ارتقا نیافته باشد.

ترکیب آخر یک تله است. do-release-upgrade نسخه سیستم شما را بر اساس همان اطلاعاتی تعیین می‌کند که در os-release وجود دارد. اگر این فایل از قبل 26.04 را نشان دهد، ابزار به دنبال نسخه‌ای جدیدتر از 26.04 می‌گردد، چیزی پیدا نمی‌کند و گزارش می‌دهد که نسخه جدیدی در دسترس نیست. ابزار در حال پاسخ به سوالی درباره os-release است و os-release اشتباه می‌کند. از اجرای مجدد ابزار ارتقا دست بردارید و کار را با apt تمام کنید: ابتدا sudo apt update و سپس sudo apt full-upgrade، که بسته‌های باقی‌مانده در نسخه 24.04 را (به جز موارد در حالت hold که apt-mark showhold آن‌ها را فهرست می‌کند) ارتقا می‌دهد و ممکن است برخی را حذف کند؛ بنابراین خلاصه آن را بخوانید و سپس sudo apt autoremove را اجرا کنید. سایر دلایلی که باعث می‌شود do-release-upgrade گزارش دهد نسخه جدیدی وجود ندارد، مانند اعلان LTS که منتظر اولین نسخه نقطه‌ای (point release) می‌ماند، در صورتی که os-release هنوز 24.04 را نشان می‌دهد، ارزش بررسی دارند.

ابزار ارتقا همچنین منابع شخص ثالث را در /etc/apt/sources.list.d/ غیرفعال می‌کند و یک نسخه پشتیبان از هر فایلی که تغییر داده، با افزودن یک پسوند به نام اصلی نگه می‌دارد. برای مشاهده دقیق تغییرات، ls -la /etc/apt/sources.list.d/ را اجرا کرده و هر فایل اصلی را با نسخه پشتیبان آن در diff مقایسه کنید. ورودی‌های شخص ثالث را تا زمانی که بسته‌های Ubuntu یکپارچه شوند غیرفعال بگذارید، سپس تنها پس از اطمینان از اینکه فروشنده بسته‌هایی برای 26.04 منتشر کرده است، هر کدام را دوباره فعال کنید. اگر apt update هشدار داد که یک منبع بیش از یک بار پیکربندی شده است، به این معناست که یک ورودی قدیمی sources.list و ورودی جدید ubuntu.sources هر دو یک مجموعه (suite) را توصیف می‌کنند و خطای منبع تکراری deb822 توضیح می‌دهد که کدام یک را باید حذف کنید.

سرور پس از ارتقا بوت نمی‌شود

ری‌بوت (reboot) زمانی است که هزینه یک ارتقای ناقص مشخص می‌شود. دلایل احتمالی در یک VPS عبارتند از: نصب هسته (kernel) بدون initramfs مربوطه، پیکربندی GRUB که بازسازی نشده است، بسته‌ای که در وضعیت نیمه‌پیکربندی باقی مانده و یک unit زمان بوت به آن وابسته است، یا پر شدن دیسک در حین نوشتن توسط dpkg.

پیش از انجام هر کاری، کنسول ارائه‌دهنده (provider) خود را باز کنید. این کنسول به شما نشان می‌دهد که بوت در کجا متوقف می‌شود: منوی GRUB، یک kernel panic، بررسی فایل‌سیستم که منتظر پاسخ است، یا یک shell اضطراری systemd که رمز عبور root را می‌خواهد. همین یک مشاهده، گام بعدی شما را تعیین می‌کند.

اگر GRUB ظاهر شد، هسته 24.04 قبلی را از زیرمنوی گزینه‌های پیشرفته (advanced options) بوت کنید. هسته قدیمی معمولاً تا زمانی که autoremove اجرا نشود، نصب باقی می‌ماند. هنگامی که سیستم با هسته قدیمی بالا آمد، sudo dpkg --configure -a و بقیه مراحل تعمیر را از بخش قبل اجرا کنید، سپس پیش از تلاش مجدد برای استفاده از هسته جدید، sudo update-initramfs -u -k all و sudo update-grub را اجرا نمایید. بازیابی یک VPS که پس از به‌روزرسانی هسته بوت نمی‌شود جزئیات مربوط به GRUB و initramfs را به‌طور کامل پوشش می‌دهد.

اگر به یک shell اضطراری هدایت شدید، فایل‌سیستم root معمولاً به‌صورت فقط‌خواندنی (read-only) مونت شده است. آن را دوباره مونت کنید و همان تعمیرات را انجام دهید:

mount -o remount,rw /
dpkg --configure -a

اگر سیستم اصلاً به shell نمی‌رسد، image نجات (rescue image) ارائه‌دهنده خود را بوت کنید، دیسک VPS را مونت کرده و از طریق chroot تعمیر را انجام دهید. پارتیشن root را با lsblk پیدا کنید و از حدس زدن نام آن خودداری کنید.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

پیش از آنکه یک ساعت وقت خود را در آن chroot صرف کنید، آن را با snapshot مقایسه کنید. شما پیش از شروع کار یک snapshot گرفته‌اید و بازیابی آن در اکثر ارائه‌دهنده‌ها تنها چند دقیقه زمان می‌برد. سپس ارتقا را دوباره اجرا می‌کنید که در یک VPS کمتر از یک ساعت طول می‌کشد و این بار می‌دانید کدام بسته را باید از قبل اصلاح کنید. بازیابی سریع‌ترین مسیر است هرگاه یکی از موارد زیر صادق باشد: دسترسی به کنسول یا image نجات ندارید، نمی‌توانید نام بسته‌ای که ارتقا را متوقف کرده تشخیص دهید، بیش از یک بسته دچار مشکل شده است، یا سرور سرویسی را اجرا می‌کند که کاربران منتظر آن هستند. اصلاح دستی تنها زمانی سریع‌ترین مسیر است که دقیقاً بدانید چه چیزی خراب شده و راه‌حل آن تنها یک دستور باشد.

پیش از بازیابی، /var/log/dist-upgrade/ را از روی سرور کپی کنید؛ اگر تنها راه دسترسی، image نجات است، از همان‌جا این کار را انجام دهید. بازیابی، آن لاگ‌ها را پاک می‌کند و اگر متوجه نشوید چرا تلاش اول شکست خورده است، تلاش دوم نیز دقیقاً به همان شکل شکست خواهد خورد. خواندن آنچه یک snapshot می‌تواند و نمی‌تواند بازیابی کند پیش از تکیه بر آن ارزشمند است. یک snapshot کل دیسک را به عقب برمی‌گرداند، از جمله هر داده‌ای که از زمان گرفتن snapshot نوشته شده است؛ این موضوع در میانه یک ارتقا مشکلی ایجاد نمی‌کند اما یک هفته بعد می‌تواند دردسرساز باشد.

سه نشانه برای اینکه سیستم باید از نو ساخته شود

برخی ارتقاها ارزش صرف وقت برای نجات دادن را ندارند. بازگردانی یک snapshot و اجرای مجدد ارتقا کم‌هزینه است، اما اگر شکست ناشی از وضعیت خودِ سرور باشد، اجرای دوم نیز با شکست مواجه می‌شود. در این حالت، راهکار صادقانه استفاده از یک image تازه از نسخه 26.04 و بازگردانی داده‌ها از نسخه پشتیبان است. سه نشانه وجود دارد که به شما می‌گوید به این مرحله رسیده‌اید.

نخست، دیتابیس داخلی dpkg آسیب دیده است. اگر dpkg --audit یا apt-get check به جای گزارش بسته‌های شکسته، اصلاً قادر به خواندن /var/lib/dpkg/status نباشند، یعنی سوابق آنچه نصب شده از بین رفته است. اوبونتو نسخه‌های روزانه‌ای را در /var/backups/ (ls -la /var/backups/dpkg.status*) نگهداری می‌کند و جایگزین کردن جدیدترین نسخه سالم گاهی اوقات مشکل را حل می‌کند. اما به محض اینکه آن نسخه با آنچه واقعاً روی دیسک وجود دارد مغایرت پیدا کند، شما در حال حدس زدن هستید و هر اجرای بعدی apt بر پایه همین حدس‌های نادرست بنا می‌شود.

دوم، ابزارهایی که برای تعمیر سیستم نیاز دارید، خودشان خراب هستند. وقتی apt یا dpkg به دلیل حذف یا جایگزینی ناقص یک کتابخانه اشتراکی اجرا نمی‌شوند، یا systemd نمی‌تواند unitها را به دلیل ناقص بودن پیکربندی بسته خودش شروع کند، دیگر هیچ مدیر بسته سالمی برای تعمیر مدیر بسته وجود ندارد. ldd /usr/bin/apt به شما می‌گوید که آیا کتابخانه‌های apt همگی موجود هستند یا خیر. گاهی اوقات می‌توانید با استفاده از chroot در یک rescue image از این وضعیت خارج شوید، اما زمانی که این کار می‌گیرد معمولاً بیشتر از ساخت مجدد سیستم است.

سوم، لیست بسته‌های شکسته کوچک نمی‌شود. اگر dpkg --configure -a و apt --fix-broken install را بیش از یک ساعت به صورت حلقه‌ای اجرا کرده‌اید و هر بار به جای پاکسازی بسته‌های قبلی، یک بسته جدید به عنوان مشکل‌دار شناسایی می‌شود، سیستم مشکلاتی را از قبل به ارتقا منتقل کرده که خودِ ارتقا عامل آن‌ها نبوده است: فایل‌هایی در /usr که دستی ویرایش شده‌اند، بسته‌هایی که pin یا hold شده‌اند، مخازن شخص ثالثی که کتابخانه‌های اصلی را جایگزین کرده‌اند، یا ارتقای قبلی که هرگز به پایان نرسیده است. یک image تازه این مشکلات را ندارد و بازگردانی داده‌ها روی آن، زمان کمتری نسبت به پیدا کردن این مشکلات می‌گیرد.

ساخت مجدد سیستم تنها زمانی کم‌هزینه است که داده‌ها در جایی غیر از همان سرور نگهداری شوند. این تفاوت بین snapshot و backup است و دلیلی است که راهنمای ارتقا، داشتن هر دو را توصیه می‌کند.

FAQ

آیا می‌توانم پس از قطع شدن فرایند، دوباره دستور do-release-upgrade را اجرا کنم؟

خیر، این اولین اقدام نیست. اگر پروسه ارتقادهنده هنوز در session مربوط به screen فعال است، با دستور sudo screen -d -r به آن متصل شوید؛ اجرای دوم do-release-upgrade پیش از رسیدن به کد اتصال مجدد متوقف می‌شود، زیرا تا زمانی که بسته‌ای در انتظار ارتقا باشد، اجازه اجرا نمی‌دهد. اگر پروسه ارتقادهنده متوقف شده است، ابتدا sudo dpkg --configure -a و sudo apt --fix-broken install را اجرا کنید. اگر فایل‌های sources در حال حاضر به 26.04 اشاره دارند، کار را با sudo apt full-upgrade به جای ارتقادهنده اصلی به پایان برسانید. اگر هنوز به 24.04 اشاره دارند، sudo apt full-upgrade را اجرا کنید، اگر /var/run/reboot-required.pkgs مواردی مانند libc6، linux-base یا هسته (kernel) را فهرست کرد، سیستم را reboot کنید و سپس ارتقادهنده را دوباره شروع کنید. همچنین اگر Prompt=never در فایل /etc/update-manager/release-upgrades تنظیم شده باشد، یا سرور Ubuntu پیام "Release upgrade not possible right now" را گزارش دهد، ارتقادهنده اجرا نخواهد شد.

چرا پس از شکست ارتقا، do-release-upgrade می‌گوید نسخه جدیدی وجود ندارد؟

زیرا base-files، بسته‌ای که فایل /etc/os-release را می‌نویسد، یکی از بسته‌هایی بوده که پیش از وقفه ارتقا یافته است. این ابزار اکنون فایل مذکور را می‌خواند، نتیجه می‌گیرد که شما روی نسخه 26.04 هستید و نسخه جدیدتری برای ارائه پیدا نمی‌کند. محتوای grep VERSION_ID /etc/os-release را با grep Suites /etc/apt/sources.list.d/ubuntu.sources مقایسه کنید و سپس کار را با sudo apt update && sudo apt full-upgrade به پایان برسانید.

آیا reboot کردن سرور Ubuntu که نیمه‌کاره ارتقا یافته، ایمن است؟

خیر، تا زمانی که sudo dpkg --audit خروجی خالی برنگرداند، این کار ایمن نیست. reboot کردن در حالی که هسته (kernel) استخراج شده اما پیکربندی نشده است، یا GRUB بازسازی نشده، رایج‌ترین دلیلی است که باعث می‌شود یک ارتقای قابل‌حل در ده دقیقه، به یک عملیات نجات با استفاده از rescue-image تبدیل شود. تعمیر dpkg و apt full-upgrade را کامل کنید، update-initramfs -u -k all و update-grub را اجرا کنید و تنها پس از آن سیستم را reboot کنید.

چگونه بفهمم کدام بسته باعث توقف ارتقا شده است؟

انتهای فایل /var/log/dist-upgrade/apt-term.log را بخوانید که خروجی ترمینال dpkg را در خود نگه می‌دارد. آخرین بسته‌ای که پیش از پایان لاگ نام برده شده، همان بسته‌ای است که در حال اجرا بوده و اسکریپت maintainer که با خطا مواجه شده، پیام خطای خود را درست بالای شکایت dpkg چاپ کرده است. فایل /var/log/dpkg.log منبع دوم است: خطوط آن که زمان توقف ارتقا را ثبت کرده‌اند، همان بسته را نام می‌برند، اما هر دستوری که پس از آن از طریق dpkg اجرا کرده باشید نیز در آن ثبت می‌شود، بنابراین ممکن است آخرین خطوط آن مربوط به بسته مشکل‌ساز نباشد. اگر فایل main.log به یک Python traceback ختم شود، به این معنی است که خودِ ارتقادهنده دچار کرش شده و هیچ بسته‌ای مقصر نیست.

آیا باید snapshot را بازیابی کنم یا به تعمیر ادامه دهم؟

زمانی که نمی‌توانید بسته‌ای که با خطا مواجه شده را شناسایی کنید، وقتی بیش از یک بسته گیر کرده است، وقتی دسترسی کنسول ندارید، یا زمانی که سرور باید سریعاً در دسترس قرار گیرد، snapshot را بازیابی کنید. تنها زمانی به تعمیر ادامه دهید که دقیقاً می‌دانید چه چیزی خراب شده و راه حل آن تنها یک دستور ساده است. پیش از بازیابی، فایل /var/log/dist-upgrade/ را از روی سرور کپی کنید، در غیر این صورت تلاش دوم نیز به همان دلیل شکست خواهد خورد.