Ubuntu upgrade lỗi giữa chừng: cách khôi phục

Nâng cấp Ubuntu bị lỗi giữa chừng: đọc triệu chứng trước

Một lần nâng cấp release Ubuntu từ 24.04 lên 26.04 bị lỗi sẽ để server ở một trong bốn trạng thái, và mỗi trạng thái có cách xử lý khác nhau. Trình nâng cấp có thể vẫn đang chạy trong một screen session mà bạn đã mất kết nối. dpkg có thể đã bị kill khi một package đang ở trạng thái half-configured, nên apt hiện từ chối mọi thao tác cài đặt, gỡ hoặc nâng cấp package, dù apt update và các lệnh chỉ đọc như apt show vẫn chạy. Các apt sources có thể đã ghi 26.04 trong khi các package đã cài vẫn là bản 24.04. Hoặc server có thể không boot được nữa. Hãy xác định bạn đang gặp trạng thái nào trước khi nhập bất kỳ lệnh nào, vì cách xử lý trạng thái này có thể làm trạng thái khác nặng hơn.

Một quy tắc áp dụng cho cả bốn trạng thái: không reboot cho đến khi biết dpkg đang ở trạng thái nào. Reboot giữa lúc package đang được thay thế là nguyên nhân biến một sự cố dpkg có thể sửa được thành trường hợp không boot được ở gần cuối hướng dẫn này. Đồng thời, không khởi chạy process apt hoặc dpkg thứ hai khi process đầu tiên có thể vẫn còn chạy, vì hai process cùng ghi vào package database có thể làm database bị hỏng.

Hướng dẫn này giả định bạn đã làm theo hướng dẫn nâng cấp từ 24.04 lên 26.04 và đã tạo snapshot trước khi bắt đầu. Nếu chưa tạo snapshot, hãy đọc phần boot với điều đó trong đầu, vì snapshot là cách xử lý trường hợp xấu nhất.

Nâng cấp vẫn đang chạy?

Nhiều lần nâng cấp bị báo lỗi thực ra vẫn đang chạy. Phiên SSH bị ngắt, terminal trống, nhưng trình nâng cấp vẫn tiếp tục chạy mà không cần bạn.

do-release-upgrade được thiết kế cho trường hợp này. Khi chạy với giao diện văn bản, là chế độ server sử dụng, nó tự chạy bên trong một phiên GNU screen. Vì vậy, quá trình nâng cấp vẫn tiếp tục khi terminal đã khởi chạy nó bị mất. Ngoài ra, khi phát hiện được khởi chạy từ một phiên SSH, nó đề nghị mở một sshd thứ hai trên cổng khác, mặc định là 1022. Nhờ đó, bạn vẫn có thể đăng nhập nếu SSH daemon chính bị lỗi trong lúc thay thế package. Cả hai thông tin này đều quan trọng lúc này.

Kết nối lại qua SSH và tìm phiên screen. Trình nâng cấp chạy dưới sudo, nên phiên screen của nó thuộc về root. Lệnh screen -ls chạy bằng user hiện tại sẽ không liệt kê được phiên này.

sudo screen -ls

screen -ls đánh dấu mỗi phiên là attached hoặc detached. Nếu có một phiên được liệt kê, hãy reattach vào phiên đó. Nếu phiên vẫn được đánh dấu là attached vì kết nối SSH đã mất chưa giải phóng nó, -d sẽ detach kết nối cũ đó trước.

sudo screen -d -r

Nếu có nhiều phiên được liệt kê, hãy đặt tên phiên từ screen -ls sau -r. Đừng trông chờ sudo do-release-upgrade tự reattach cho bạn. Code tìm phiên screen hiện có nằm trong trình nâng cấp mà nó tải xuống. Trước khi tải bất kỳ thứ gì, do-release-upgrade sẽ thoát với thông báo "Please install all available updates for your release before upgrading" nếu phát hiện một package đang chờ nâng cấp, ngoại trừ phased updates. Đây chính xác là trạng thái của hệ thống đang ở giữa quá trình thay thế package. Sau khi reattach, bạn sẽ quay lại quá trình nâng cấp đang chạy. Thông thường, nó đang chờ bạn trả lời prompt về file cấu hình đã thay đổi hoặc việc restart service. Hãy trả lời và để quá trình hoàn tất.

Nếu bạn bắt đầu nâng cấp bên trong tmux, như hướng dẫn nâng cấp khuyến nghị, trước tiên hãy reattach tmux bằng tmux attach. Phiên screen đang chạy bên trong pane tmux đó, nên bạn sẽ thấy trực tiếp quá trình nâng cấp. Nếu pane chỉ hiển thị shell prompt, trình nâng cấp không còn chạy ở đó nữa và sudo screen -ls là bước kiểm tra tiếp theo.

Nếu cổng SSH chính từ chối kết nối, hãy thử cổng dự phòng: ssh -p 1022 user@host. Daemon này chỉ tồn tại trong thời gian nâng cấp. Vì vậy, nếu không thể đăng nhập qua cả hai cổng, hãy dùng console của nhà cung cấp. Từ console, sudo ss -ltnp hiển thị các cổng mà một process sshd đang listen. sudo ufw status cho biết firewall có cho phép cổng dự phòng đi qua hay không.

Khi không có phiên screen và console cũng không hiển thị prompt nào đang chờ, quá trình nâng cấp thực sự đã dừng. Hãy xác nhận không còn process nào đang thao tác với package database trước khi xử lý:

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

Kết quả trống nghĩa là dpkg đang idle và bạn có thể chuyển sang sửa lỗi. Một process dpkg hoặc apt có thời gian chạy dài, nhưng không có phiên screen để reattach, là process bị treo. Hãy chờ vài phút, kiểm tra console để xem có câu hỏi debconf nào chưa được trả lời không, rồi chỉ sau đó mới kill process. Không bao giờ xóa các lock file bên dưới /var/lib/dpkg/ hoặc /var/lib/apt/lists/ khi vẫn có process đang giữ chúng. Lock là cơ chế duy nhất ngăn 2 process cùng ghi và làm hỏng package database.

dpkg bị gián đoạn và apt từ chối chạy

Khi dpkg bị kill giữa lúc unpack package và chạy configuration script, package đó sẽ bị đánh dấu là half done và để lại các entry chưa hoàn tất trong journal tại /var/lib/dpkg/updates/. Mọi lệnh apt lấy dpkg lock, tức là mọi lệnh install, remove hoặc upgrade, đều kiểm tra journal này trước rồi dừng với dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.. Các lệnh không lấy lock đó, như apt update, apt list, apt show và apt-cache, vẫn hoạt động, nên bạn vẫn có thể kiểm tra hệ thống. Dù apt in thêm gì, bước đầu tiên vẫn giống nhau.

sudo dpkg --configure -a

Lệnh này hoàn tất bước cấu hình cho mọi package đã được unpack nhưng chưa được configure. Nó chạy maintainer script theo thứ tự dependency. Trên hệ thống đang half-upgrade, quá trình này có thể mất nhiều thời gian, vì vậy hãy để lệnh chạy đến khi kết thúc. Nếu dừng ở một package, lệnh sẽ in tên package và script bị lỗi. Hãy ghi lại tên đó. Đây là package khiến quá trình upgrade dừng lại; phần tiếp theo hướng dẫn cách đọc lỗi của nó.

Sau đó để apt sửa các dependency còn thiếu do lần gián đoạn để lại, vì một số package đã được upgrade nhưng các package mà chúng phụ thuộc vào thì chưa.

sudo apt --fix-broken install

Tiếp theo, hoàn tất quá trình upgrade mà upgrader đang thực hiện dở:

sudo apt update
sudo apt full-upgrade

Dùng full-upgrade thay cho upgrade, vì release upgrade có thể remove package còn upgrade thông thường sẽ từ chối remove bất kỳ package nào. Đọc phần summary mà apt in ra trước khi xác nhận. Một danh sách ngắn các package bị remove là bình thường. Nếu danh sách đó remove ubuntu-server, systemd, openssh-server hoặc kernel package của bạn thì không bình thường. Hãy trả lời no và tìm hiểu lý do apt muốn làm vậy trước khi tiếp tục.

Kiểm tra kết quả trước khi làm việc khác:

sudo dpkg --audit
sudo apt-get check

dpkg --audit liệt kê mọi package vẫn ở trạng thái broken, còn apt-get check báo các dependency chưa được đáp ứng. Cả hai lệnh đều phải không in gì. Khi đạt được kết quả đó, chạy sudo apt autoremove để xóa các dependency được tự động install mà không còn package nào cần nữa. Các package được đánh dấu là manually installed vẫn được giữ lại, kể cả khi không có package nào sử dụng chúng. Sau đó xác nhận release bằng cat /etc/os-release, rồi chạy sudo update-initramfs -u -k all và sudo update-grub, chỉ sau đó mới reboot.

Cách đọc /var/log/dist-upgrade để tìm package khiến quá trình dừng lại

Upgrader ghi mọi thứ vào /var/log/dist-upgrade/. Nếu bạn đã chạy nó nhiều lần, log của lần trước sẽ được chuyển vào một subdirectory có tên là timestamp. Vì vậy, trước tiên hãy kiểm tra ls -la /var/log/dist-upgrade/ rồi đọc directory tương ứng với lần chạy bị lỗi.

main.log là nhật ký riêng của upgrader. Nó ghi lại run đang ở phase nào và upgrader đã quyết định xử lý các source của bạn ra sao. Nếu chính upgrader bị crash, Python traceback cũng nằm ở đây. Đọc file từ cuối lên: các dòng cuối cho biết run đang ở phase nào khi dừng. Nếu có traceback ở đó, lỗi nằm ở tool chứ không phải package.

apt.log chứa cách dependency resolver đưa ra quyết định. File này rất dài và chỉ quan trọng khi apt từ chối tính toán upgrade ngay từ đầu, tức là lỗi xảy ra trước khi package nào được xử lý. Nếu upgrade đã đi đến bước install package, bạn thường có thể bỏ qua file này.

apt-term.log là file cần xem khi package bị lỗi. Nó ghi lại output trên terminal của dpkg trong lúc upgrade, tức là chính phần nội dung đáng lẽ đã chạy qua màn hình của bạn. Package cuối cùng được nhắc đến trước khi file kết thúc là package đang được xử lý lúc upgrade dừng lại. Nếu maintainer script bị lỗi, thông báo của dpkg về lỗi đó nằm ngay tại đây, cùng với lỗi riêng của script ở ngay phía trên.

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

Đối chiếu với /var/log/dpkg.log. File này ghi lại các thay đổi trạng thái và action mà dpkg thực hiện, kèm timestamp. tail -n 30 /var/log/dpkg.log cho biết package cuối cùng dpkg xử lý và dpkg đang làm gì với package đó. Đây chỉ là cùng một kết quả từ nguồn thứ hai nếu chưa có lệnh nào chạy dpkg kể từ lúc lỗi xảy ra. Sau khi bạn chạy dpkg --configure -a hoặc apt --fix-broken install, entry của các lệnh đó sẽ nằm ở cuối. Khi đó hãy cuộn ngược đến các dòng có timestamp đúng lúc upgrade dừng lại.

Phần lớn lỗi ở giai đoạn này trên server xuất phát từ một vài nguyên nhân. Một service mà package restart trong postinst không khởi động được vì file cấu hình bạn đã tùy chỉnh. systemctl status cùng với journalctl -xeu trên service đó sẽ chỉ ra dòng mà service không chấp nhận. Disk có thể đã đầy, thường là /boot do kernel cũ hoặc /var do apt package cache; df -h / /boot /var sẽ hiển thị tình trạng này. sudo apt clean xóa cache ngay cả khi apt đang bị kẹt, còn disk báo đầy dù du cho biết disk chưa đầy có nguyên nhân riêng. Một package từ third-party repository mà upgrader đã disable có thể phụ thuộc vào một library mà release 26.04 không còn ship. Một package bị hold (apt-mark showhold) có thể đã chặn một dependency được upgrade. Hãy sửa nguyên nhân rồi chạy lại sudo dpkg --configure -a. Lệnh này sẽ tiếp tục từ vị trí đã dừng.

Nếu một package vẫn không chịu configure dù bạn đã thử mọi cách, và không có package quan trọng nào phụ thuộc vào nó, hãy remove package đó rồi reinstall sau khi upgrade hoàn tất:

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

Chỉ dùng cách này khi bạn xác định được package và giải thích được lý do cần remove. Không dùng với library hoặc bất kỳ package nào trong dependency chain của ubuntu-server, vì forced removal bỏ qua các kiểm tra vốn cho biết những thành phần nào khác sẽ bị hỏng.

Các source đã chuyển nhưng package chưa chuyển

Trình nâng cấp sửa các apt source từ sớm, trước khi tải package. Nếu quá trình bị gián đoạn sau bước đó, các source sẽ ghi 26.04 trong khi các package đã cài là một tập hợp lẫn lộn. Tình trạng này làm các công cụ bị nhầm, và đó là lý do do-release-upgrade hiện có thể khẳng định rằng không có bản phát hành mới.

Hãy so sánh hai nơi mô tả bản phát hành hiện đang dùng. /etc/apt/sources.list.d/ubuntu.sources là file source deb822 được giới thiệu từ 24.04, còn các dòng Suites: chứa codename của bản phát hành. /etc/os-release do package base-files ghi và cho biết bản phát hành nào thực sự đã được cài.

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

Có 3 tổ hợp cần chú ý. Nếu source vẫn ghi 24.04 (codename noble) và os-release vẫn ghi 24.04, quá trình nâng cấp chưa vượt qua các bước kiểm tra. Bạn có thể chạy lại sudo do-release-upgrade sau khi đọc main.log để biết lý do nó dừng. Lệnh này sẽ không khởi động khi còn bất kỳ bản cập nhật 24.04 nào đang chờ, hoặc khi /var/run/reboot-required.pkgs chỉ ra libc6, linux-base hay một package linux-image. Vì vậy, hãy chạy sudo apt full-upgrade và reboot nếu file đó yêu cầu trước.

Nếu source ghi codename của 26.04 nhưng os-release vẫn ghi 24.04, quá trình thay package đã bắt đầu rồi bị gián đoạn. Cách hoàn tất là sửa dpkg như phần trước, kết thúc bằng apt full-upgrade. Không chạy lại trình nâng cấp trong trạng thái này. Khi các package 26.04 đang chờ cài, trình nâng cấp sẽ dừng và yêu cầu bạn cài tất cả bản cập nhật hiện có trước.

Nếu source ghi 26.04 và os-release cũng ghi 26.04, base-files là một trong các package đã được cài xong. Hệ thống hiện tự nhận là 26.04, dù phần lớn hệ thống có thể vẫn chưa được nâng cấp.

Tổ hợp cuối cùng là trường hợp dễ mắc bẫy. do-release-upgrade xác định bản phát hành dựa trên chính thông tin mà os-release chứa. Nếu thông tin đó đã ghi 26.04, công cụ sẽ tìm bản mới hơn 26.04, không tìm thấy gì và báo rằng không có bản phát hành mới. Công cụ đang trả lời câu hỏi về os-release, nhưng os-release lại sai. Không tiếp tục hỏi trình nâng cấp nữa. Hãy hoàn tất bằng apt: chạy sudo apt update, sau đó chạy sudo apt full-upgrade. Lệnh này nâng cấp các package vẫn đang ở phiên bản 24.04, ngoại trừ những package đang bị hold (apt-mark showhold liệt kê các package đó), và có thể thay vào đó gỡ một số package. Vì vậy, hãy đọc phần summary rồi chạy sudo apt autoremove. Các lý do khác khiến do-release-upgrade báo không có bản phát hành mới, chẳng hạn prompt LTS chờ point release đầu tiên, cũng nên được loại trừ nếu os-release vẫn ghi 24.04.

Trình nâng cấp cũng vô hiệu hóa các source bên thứ ba trong /etc/apt/sources.list.d/ và giữ một bản backup của từng file đã sửa, bằng cách thêm suffix vào tên gốc. Chạy ls -la /etc/apt/sources.list.d/ và diff cho từng file gốc cùng với bản backup tương ứng để xem chính xác nó đã thay đổi gì. Hãy để các entry bên thứ ba ở trạng thái vô hiệu hóa cho đến khi các package Ubuntu nhất quán, sau đó chỉ bật lại từng entry khi đã xác nhận vendor có phát hành package cho 26.04. Nếu apt update báo một source được cấu hình nhiều hơn một lần, một entry sources.list cũ và entry ubuntu.sources mới đang mô tả cùng một suite. Lỗi source trùng trong deb822 giải thích cần xóa entry nào.

Máy chủ không khởi động sau khi upgrade

Reboot là lúc một lần upgrade chưa hoàn tất bắt đầu gây hậu quả. Trên VPS, các nguyên nhân thường gặp là kernel được cài nhưng không có initramfs, cấu hình GRUB chưa được tạo lại, một package bị bỏ dở ở trạng thái cấu hình chưa hoàn tất khiến một boot-time unit phụ thuộc vào nó, hoặc disk bị đầy khi dpkg đang ghi dữ liệu.

Mở console của provider trước khi làm bất kỳ việc gì khác. Console cho biết quá trình boot dừng ở đâu: menu GRUB, kernel panic, filesystem check đang chờ câu trả lời, hoặc systemd emergency shell yêu cầu root password. Chỉ một thông tin này cũng quyết định bước tiếp theo.

Nếu GRUB xuất hiện, hãy boot kernel 24.04 trước đó từ submenu advanced options. Kernel cũ thường vẫn được giữ lại cho đến khi autoremove chạy. Sau khi hệ thống đã lên bằng kernel cũ, chạy sudo dpkg --configure -a và thực hiện phần repair còn lại trong section ở trên, rồi chạy sudo update-initramfs -u -k all và sudo update-grub trước khi thử lại kernel mới. Khôi phục VPS không boot được sau khi update kernel trình bày chi tiết phần GRUB và initramfs.

Nếu bạn vào emergency shell, root filesystem thường được mount ở chế độ read-only. Remount filesystem rồi chạy quy trình repair tương tự:

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

Nếu hệ thống hoàn toàn không vào được shell, hãy boot rescue image của provider, mount disk của VPS và repair từ một chroot. Tìm root partition bằng lsblk thay vì đoán tên partition.

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

Trước khi dành cả giờ trong chroot đó, hãy cân nhắc snapshot. Bạn đã tạo snapshot trước khi bắt đầu, và việc restore thường chỉ mất vài phút trên hầu hết provider. Sau đó bạn chạy lại upgrade, thường mất chưa đến một giờ trên VPS, và lần này đã biết trước cần sửa package nào. Restore là phương án nhanh hơn khi có bất kỳ điều nào sau đây: bạn không truy cập được console hoặc rescue image, bạn không xác định được package khiến upgrade dừng lại, có nhiều hơn một package bị kẹt, hoặc máy chủ đang chạy dịch vụ mà người khác đang chờ. Tự patch là phương án nhanh hơn chỉ khi bạn biết chính xác một lỗi đã xảy ra và cách sửa chỉ cần một command.

Copy /var/log/dist-upgrade/ ra khỏi máy chủ trước khi restore, dùng rescue image nếu đó là cách duy nhất để truy cập. Restore sẽ xóa các log đó, và lần thử thứ hai sẽ thất bại đúng theo cách cũ nếu bạn chưa biết nguyên nhân lần đầu. Snapshot có thể và không thể khôi phục những gì đáng đọc trước khi bạn dựa vào snapshot. Snapshot đưa toàn bộ disk về trạng thái trước đó, bao gồm mọi dữ liệu được ghi kể từ lúc tạo snapshot. Điều này phù hợp khi đang upgrade nhưng không phù hợp nếu đã qua một tuần.

Ba dấu hiệu cho thấy nên rebuild hệ thống

Một số lần upgrade không đáng để cứu. Khôi phục snapshot rồi chạy lại thường không tốn nhiều công sức. Nhưng nếu lỗi bắt nguồn từ trạng thái của chính máy chủ, lần chạy thứ hai cũng sẽ fail. Khi đó, cách xử lý đúng là dùng image 26.04 mới và khôi phục dữ liệu từ backup. Có ba dấu hiệu cho thấy bạn đang ở tình huống này.

Thứ nhất, database của dpkg đã bị hỏng. Nếu dpkg --audit hoặc apt-get check không thể đọc /var/lib/dpkg/status, thay vì chỉ báo các package bị hỏng bên trong database, thì record về những gì đã được cài đặt đã mất. Ubuntu lưu các bản sao hằng ngày trong /var/backups/ (ls -la /var/backups/dpkg.status*), và đôi khi việc thay bản sao mới nhất còn tốt vào đúng vị trí có thể khắc phục được. Nhưng khi bản sao đó không còn khớp với những gì thực sự có trên disk, bạn đang phải đoán. Mọi lần chạy apt sau đó đều tiếp tục dựa trên phỏng đoán này.

Thứ hai, chính các tool cần để sửa hệ thống cũng đã bị hỏng. Khi apt hoặc dpkg không thể start vì một shared library đã bị xóa hoặc bị thay thế dở dang, hoặc systemd không thể start các unit vì package của chính nó đang được configure dở dang, hệ thống không còn package manager hoạt động để sửa package manager nữa. ldd /usr/bin/apt cho biết các library của apt có còn đầy đủ hay không. Đôi khi bạn có thể bootstrap hệ thống từ chroot trong rescue image. Nhưng cách này thường tốn nhiều thời gian hơn rebuild.

Thứ ba, danh sách package bị hỏng không giảm xuống. Nếu bạn đã chạy dpkg --configure -a và apt --fix-broken install theo vòng lặp hơn một giờ, nhưng mỗi lần chạy lại phát hiện thêm một package mới thay vì xử lý package trước đó, thì hệ thống đã mang các vấn đề vào quá trình upgrade và các vấn đề đó không phải do upgrade tạo ra: các file dưới /usr bị chỉnh sửa thủ công, package bị pin hoặc hold, một third-party repository đã thay thế các core library, hoặc một lần upgrade trước đó chưa bao giờ hoàn tất. Image mới không có các vấn đề này. Khôi phục dữ liệu lên image mới cũng tốn ít thời gian hơn việc truy tìm nguyên nhân.

Rebuild chỉ nhanh và đơn giản khi dữ liệu nằm ở nơi khác, không phải trên máy chủ. Đó là điểm khác nhau giữa snapshot và backup, cũng là lý do hướng dẫn upgrade yêu cầu bạn chuẩn bị cả hai.

FAQ

Tôi có thể chỉ cần chạy lại do-release-upgrade sau khi quá trình bị gián đoạn không?

Không nên làm vậy ngay. Nếu upgrader vẫn đang chạy trong screen session, hãy kết nối lại bằng sudo screen -d -r; lần chạy do-release-upgrade thứ hai sẽ dừng trước khi đến phần code kết nối lại của chính nó, vì nó từ chối khởi động khi còn package đang chờ upgrade. Nếu upgrader đã dừng, trước tiên hãy chạy sudo dpkg --configure -a và sudo apt --fix-broken install. Nếu các source đã ghi 26.04, hãy hoàn tất bằng sudo apt full-upgrade thay vì chạy upgrader. Nếu chúng vẫn ghi 24.04, hãy chạy sudo apt full-upgrade, reboot nếu /var/run/reboot-required.pkgs liệt kê libc6, linux-base hoặc một kernel, rồi khởi động lại upgrader. Upgrader cũng từ chối chạy khi Prompt=never được đặt trong /etc/update-manager/release-upgrades, hoặc khi server của Ubuntu trả về “Release upgrade not possible right now”.

Tại sao do-release-upgrade báo không có release mới sau khi upgrade thất bại?

Vì base-files, package ghi vào /etc/os-release, là một trong các package đã được upgrade trước khi quá trình bị gián đoạn. Công cụ hiện đọc file đó, kết luận rằng bạn đang dùng 26.04 và không tìm thấy release nào mới hơn để cung cấp. Hãy so sánh grep VERSION_ID /etc/os-release với grep Suites /etc/apt/sources.list.d/ubuntu.sources, rồi hoàn tất bằng sudo apt update && sudo apt full-upgrade.

Reboot một Ubuntu server đang upgrade dở có an toàn không?

Chưa, cho đến khi sudo dpkg --audit không trả về gì. Reboot khi một kernel đã được unpack nhưng chưa được configure, hoặc khi GRUB chưa được tạo lại, là nguyên nhân phổ biến nhất khiến một lần upgrade có thể sửa trong 10 phút trở thành công việc phục hồi từ rescue image. Hãy hoàn tất việc sửa dpkg và apt full-upgrade, chạy update-initramfs -u -k all và update-grub, rồi mới reboot.

Làm thế nào để biết package nào đã làm quá trình upgrade dừng lại?

Đọc phần cuối của /var/log/dist-upgrade/apt-term.log, nơi chứa output cuối của dpkg. Package cuối cùng được nêu tên trước khi log kết thúc là package đang được xử lý; nếu maintainer script thất bại, lỗi của nó sẽ nằm ngay phía trên thông báo lỗi của dpkg. /var/log/dpkg.log là nguồn thứ hai: các dòng có timestamp tại thời điểm upgrade dừng sẽ nêu cùng package đó, nhưng mọi lệnh bạn đã chạy qua dpkg sau thời điểm ấy cũng được ghi vào đây, nên các dòng cuối chưa chắc còn chỉ package đó. Nếu thay vào đó main.log kết thúc bằng một Python traceback, chính upgrader đã crash và không có package nào gây ra lỗi.

Tôi nên restore snapshot hay tiếp tục sửa?

Hãy restore khi bạn không xác định được package bị lỗi, khi có nhiều hơn một package bị kẹt, khi bạn không có quyền truy cập console hoặc khi server cần hoạt động trở lại nhanh. Chỉ tiếp tục sửa khi bạn biết chính xác một lỗi duy nhất và cách sửa chỉ cần một command. Hãy copy /var/log/dist-upgrade/ ra khỏi máy trước khi restore, nếu không lần thử thứ hai sẽ thất bại theo cùng cách.