Trước khi nâng cấp hệ thống, rất khuyên người dùng tạo một bản sao lưu hoàn toàn, hoặc ít nhất sao lưu bất kỳ dữ liệu hay thông tin cấu hình không nên mất. Các công cụ và quá trình nâng cấp vẫn hơi tin cậy, nhưng một sự thất bại phần cứng ở giữa việc nâng cấp có thể gây ra một hệ thống rất bị hại.

Dữ liệu chính nên sao lưu là nội dung của thư mục /etc, /var/lib/dpkg, /var/lib/aptitude/pkgstates và kết xuất của câu lệnh dpkg --get-selections "*" (hai dấu nháy kép vẫn đáng kể).

Quá trình nâng cấp chính nó không sửa đổi gì trong thư mục /home (thư mục chính của mỗi người dùng). Tuy nhiên, một số ứng dụng nào đó (v.d. thuộc về bộ ứng dụng Mozilla, và môi trường GNOME and KDE) được biết là ghi đè lên thiết lập người dùng đã tồn tại bằng giá trị mặc định mới khi một phiên bản mới của ứng dụng được khởi chạy đầu tiên bởi một người dùng. Để phòng ngừa, khuyên người dùng sao lưu các tập tin và thư mục bị ẩn (“tập tin chấm”) trong thư mục chính của mỗi người dùng. Bản sao lưu này có thể giúp phục hồi hoặc tạo lại thiết lập cũ. Quản trị cũng có thể muốn cho các người dùng biết về trường hợp này.

Mỗi thao tác cài đặt gói phải được chạy với quyền siêu người dùng: có nên đăng nhập dưới root (người chủ) hoặc sử dụng lệnh su hay sudo để lấy được quyền truy cập cần thiết.

Việc nâng cấp có một số điều kiện tiên quyết: người dùng nên kiểm tra trước khi thật thực hiện tiến trình nâng cấp.

Khuyên quản trị thông báo trước cho mọi người dùng biết về bất kỳ quá trình nâng cấp dự định, dù người dùng đang truy cập đến hệ thống thông qua một kết nối ssh nên thấy ít trong khi nâng cấp, và nên có thể tiếp tục làm việc.

Muốn thực hiện thêm bước phòng ngừa thì sao lưu hoặc tháo gắn kết phân vùng /home) trước khi nâng cấp.

Nâng cấp lên lenny thì rất có thể là cũng cần phải nâng cấp hạt nhân, do đó cần phải khởi động lại hệ thống (bình thường sau khi nâng cấp xong).

Do rất nhiều thay đổi trong hạt nhân (so etch với lenny) đối với trình điều khiển, phát hiện phần cứng và đặt tên và sắp đặt các tập tin thiết bị, thật sự rủi ro là người dùng có thể gặp khó khăn trong việc khởi động lại hệ thống sau khi nâng cấp. Rất nhiều vấn đề có thể gặp đã được diễn tả trong chương này, và những chương kế tiếp của Ghi chú Phát hành này.

Vì lý do đó hợp lý là người dùng hay quản trị đảm bảo có thể phục hồi nếu hệ thống không khởi động lại được hoặc, đối với hệ thống quản lý từ xa, không chạy mạng được.

Nếu quản trị nâng cấp từ xa qua một liên kết ssh, rất khuyên quản trị cũng thực hiện những bước phòng ngừa cần thiết để có khả năng truy cập đến máy phục vụ qua một thiết bị nối tiếp từ xa. Vẫn có thể là, sau khi nâng cấp hạt nhân và khởi động lại hệ thống, một số thiết bị sẽ bị thay tên (như diễn tả trong Phần 4.6.2, “Số thứ tự thiết bị khác”) thì quản trị cần phải sửa chữa cấu hình hệ thống thông qua một bàn giao tiếp cục bộ. Hơn nữa, nếu hệ thống bị tình nguyện cờ khởi động lại ở giữa quá trình nâng cấp, quản trị có thể cần phải phục hồi dùng một bàn giao tiếp cục bộ.

Cái hiển nhiện nhất để thử đầu tiên để khởi động lại bằng hạt nhân cũ. Tuy nhiên, vì các lý do khác nhau diễn tả ở nơi khác của tài liệu này, sự thử này không phải đảm bảo thành công.

Nếu nó không thành công, quản trị cần một phương pháp khác để khởi động hệ thống để truy cập và sửa chữa nó. Một lựa chọn là sử dụng một ảnh cứu đặc biệt hay một đĩa CD Linux Động. Sau khi khởi động từ đó, quản trị nên có khả năng gắn kết hệ thống tập tin gốc và chroot vào nó để xem xét và sửa chữa vấn đề.

Một lựa chọn khác có thể khuyến khích là sử dụng chế độ cứu của Bộ Cài Đặt Debian lenny. Lợi ích khi sử dụng bộ cài đặt là người dùng có thể chọn trong nhiều phương pháp cài đặt khác nhau một phương pháp riêng lẻ thích hợp nhất với trường hợp đó. Để tìm thêm thông tin, xem phần “Phục hồi một hệ thống bị hỏng” trong Chương 8 của Sổ tay Cài đặt (dịch sang tiếng Việt) vàHỏi Đáp Cài đặt Debian.

Việc nâng cấp bản phân phối nên được làm hoặc cục bộ từ một bàn giao tiếp ảo chế độ văn bản (hay một thiết bị cuối nối tiếp được kết nối trực tiếp), hoặc từ xa thông qua một liên kết ssh.

Để tăng hệ số an toàn khi nâng cấp từ xa, khuyên quản trị chạy tiến trình nâng cấp trên bàn giao tiếp ảo được chương trình screen cung cấp, mà hiệu lực chức năng tái kết nối an toàn và đảm bảo tiến trình nâng cấp không phải bị gián đoạn thậm chí nếu quá trình kết nối từ xa không thành công.

	Quan trọng
	Không nên nâng cấp dùng telnet, rlogin, rsh, hay một buổi hợp đăng nhập X được quản lý bởi xdm, gdm, kdm v.v. trên máy đang nâng cấp. Đó là vì mỗi dịch vụ như vậy sẽ bị chấm dứt trong quá trình nâng cấp, mà có thể gây ra một hệ thống không thể tới được mà chưa được nâng cấp hoàn toàn.

Người dùng có sử dụng bộ nạp khởi động LILO ghi chú rằng thiết lập mặc định về công cụ initramfs-tools giờ tạo một initramfs quá lớn để LILO nạp được. Người dùng như vậy nên chuyển đổi sang grub, hoặc tự chỉnh sửa tập tin /etc/initramfs-tools/initramfs.conf, sửa đổi dòng:

MODULES=most

thành

MODULES=dep

Tuy nhiên, ghi chú rằng thay đổi này sẽ gây ra initramfs-tools cài đặt vào initramfs chỉ những mô-đun cần thiết cho phần cứng riêng đó ; như thế, nếu quản trị muốn tạo vật chứa khởi động sẽ hoạt động được trên nhiều phần cứng hơn chỉ máy đó, có nên để lại dòng là

MODULES=most

và đảm bảo sẽ không dùng LILO.

Trong một số trường hợp nào đó, sử dụng apt-get thay cho aptitude để cài đặt gói có thể làm cho aptitude thấy một gói nào đó là “chưa dùng” và định thời nó bị gỡ bỏ. Thông thường, quản trị nên kiểm tra hệ thống vẫn “sạch” và được cập nhật hoàn toàn trước khi tiếp tục nâng cấp.

Do đó, quản trị nên kiểm tra có hành vi bị hoãn trong bộ quản lý gói aptitude. Vẫn có một gói định thời gỡ bỏ hay cập nhật trong bộ quản lý gói thì nó có thể ảnh hưởng âm đến quá trình nâng cấp. Ghi chú rằng chỉ có thể sửa chữa trường hợp này nếu tập tin liệt kê các nguồn sources.list vẫn còn chỉ tới etch;, không phải tới bản ổn định (stable) hay lenny; xem Phần A.2, “Kiểm tra danh sách nguồn”.

Để thực hiện thủ tục xem lại này, hãy khởi chạy aptitude trong “chế độ trực quan” và bấm phím g (“Đi”). Nếu nó hiển thị hành vi nào, quản trị nên xem lại và sửa chữa hoặc thực hiện chúng. Không có hành vi đề xuất thì chương trình hiển thị một thông điệp: “Không có gói nào được định cài đặt, gỡ bỏ hoặc nâng cấp”.

Nếu người dùng đã cấu hình APT để cài đặt một số gói nào đó từ một bản phát hành khác với bản ổn định (stable), v.d. từ bản thử (testing), thì có lẽ người dùng cần phải sửa đổi cấu hình ghim phiên bản trong APT (cất giữ trong /etc/apt/preferences) để cho phép nâng cấp gói lên phiên bản trong bản phát hành ổn định mới. Có thể tìm thêm thông tin về chức năng ghim phiên bản APT trong apt_preferences(5).

Bất chấp phương pháp dùng để nâng cấp, khuyên người dùng trước tiên kiểm tra trạng thái về tất cả các gói, và thẩm tra mọi gói đều có tình trạng có thể nâng cấp. Theo đây có câu lệnh sẽ hiển thị gói nào có trạng thái « Nửa cài đặt » hay « Lỗi cấu hình » hay bất cứ trạng thái lỗi nào.

# dpkg --audit

Cũng có thể kiểm tra trạng thái về tất cả các gói trên hệ thống dùng dselect, aptitude, hay câu lệnh như

# dpkg -l | pager

hay

# dpkg --get-selections "*" > ~/curr-pkgs.txt

Có nên gỡ bỏ bất kỳ tình trạng giữ lại trước khi nâng cấp. Nếu gói nào chủ yếu để nâng cấp vẫn còn bị giữ lại, thì việc nâng cấp sẽ không thành công.

Ghi chú rằng aptitude sử dụng một phương pháp khác để đăng ký các gói bị giữ lại, so với apt-get và dselect. Người dùng có thể tìm những gói bị giữ lại trong aptitude dùng câu lệnh

# aptitude search "~ahold" | grep "^.h"

Muốn kiểm tra những gói nào bị giữ lại trong apt-get thì dùng câu lệnh

# dpkg --get-selections | grep hold

Nếu người dùng đã sửa đổi và biên dịch lại gói nào một cách cục bộ, vẫn không thay đổi tên nó hoặc đặt thời điểm vào phiên bản, người dùng phải đặt tình trạng giữ lại cho nó, để ngăn cản nó được nâng cấp.

Trong aptitude, tình trạng gói “giữ lại” có thể được thay đổi dùng câu lệnh

# aptitude hold tên_gói

Thay thế từ hold (giữ lại) bằng unhold (bỏ giữ) để bỏ đặt tình trạng “giữ lại”.

Vẫn có gì cần sửa chữa thì người dùng nên kiểm tra tập tin sources.list vẫn còn tham chiếu đến etch như diễn tả trong Phần A.2, “Kiểm tra danh sách nguồn”.

Nếu tập tin /etc/apt/sources.list chứa phần proposed-updates, người dùng nên gỡ bỏ tập tin này trước khi thử nâng cấp hệ thống. Đây là một bước phòng ngừa để giảm sự có thể bị xung đột.

Nếu hệ thống chứa gói nào khác Debian, ghi chú rằng các gói như vậy có thể bị gỡ bỏ trong quá trình nâng cấp, do quan hệ phụ thuộc bị xung đột. Nếu những gói này đã được cài đặt bằng cách thêm một kho gói bổ sung vào tập tin /etc/apt/sources.list, người dùng nên kiểm tra nếu kho gói đó cũng cung cấp các gói được biên dịch cho lenny, và sửa đổi dòng nguồn một cách tương ứng, cùng lúc với sửa đổi các dòng nguồn về gói Debian.

Hệ thống etch có lẽ cũng chứa phiên bản “mới” chuyển ngược không chính thức của gói có phải thuộc về Debian. Gói như vậy rất có thể gây ra vấn đề trong quá trình nâng cấp, vì kết quả là hai tập tin bị xung đột nhau^[3]. Phần 4.5.8, “Vấn đề có thể gặp trong khi nâng cấp” có vài thông tin về cách giải quyết hai tập tin bị xung đột (nếu trường hợp này xảy ra).

Cấu hình mặc định được thiết lập để cài đặt từ các máy phục vụ Debian chính, nhưng người dùng cũng có thể sửa đổi tập tin /etc/apt/sources.list để sử dụng máy nhân bản khác, tốt hơn một máy nhân bản gần chỗ người dùng trên mạng.

Có thể tìm các địa chỉ máy nhân bản HTTP/FTP Debian ở http://www.debian.org/distrib/ftplist (xem phần “list of Debian mirrors” [danh sách các máy nhân bản Debian]). Máy nhân bản HTTP thường chạy nhanh hơn máy nhân bản FTP.

Ví dụ, giả sử máy nhân bản Debian gần nhất là http://mirrors.kernel.org. Khi xem xét nó dùng trình duyệt Web hay một chương trình FTP, người dùng sẽ thấy những thư mục chính được sắp đặt như thế:

http://mirrors.kernel.org/debian/dists/lenny/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...

Để sử dụng máy nhân bản này với apt, người dùng nên thêm vào tập tin sources.list dòng này:

deb http://mirrors.kernel.org/debian lenny main contrib

Ghi chú rằng đoạn « dists » được thêm ngầm, và các đối số đằng sau tên bản phát hành được dùng để mở rộng đường dẫn ra nhiều thư mục.

Sau khi thêm các nguồn mới, hãy tắt mỗi dòng “deb” đã tồn tại trong sources.list bằng cách ghi một dấu thăng (#) vào trước.

Thay vào sử dụng máy nhân bản HTTP/FTP, người dùng cũng có thể sửa đổi tập tin /etc/apt/sources.list để sử dụng kho nhân bản trên một đĩa cục bộ (có thể gắn kết thông qua NFS).

Ví dụ, kho nhân bản gói có thể nằm dưới /var/ftp/debian/, với các thư mục chính:

/var/ftp/debian/dists/lenny/main/binary-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

Để sử dụng kho cục bộ này với apt, hãy thêm vào tập tin sources.list dòng này:

deb file:/var/ftp/debian lenny main contrib

Ghi chú rằng đoạn « dists » được thêm ngầm, và các đối số đằng sau tên bản phát hành được dùng để mở rộng đường dẫn ra nhiều thư mục.

Sau khi thêm các nguồn mới, hãy tắt mỗi dòng “deb” đã tồn tại trong sources.list bằng cách ghi một dấu thăng (#) vào trước.

Nếu người dùng chỉ muốn sử dụng các đĩa CD, hãy ghi chú tắt (đặt # vào trước) những dòng “deb” đã tồn tại trong tập tin /etc/apt/sources.list.

Kiểm tra tập tin /etc/fstab chứa một dòng hiệu lực gắn kết ổ đĩa CD ở điểm lắp /cdrom (điểm lắp /cdrom chính xác cần thiết cho apt-cdrom). Ví dụ, nếu /dev/hdc là ổ đĩa CD, /etc/fstab nên chứa một dòng như thế:

/dev/hdc /cdrom auto defaults,noauto,ro 0 0

Ghi chú rằng không cho phép khoảng cách nằm giữa các từ defaults,noauto,ro trong trường thứ tư.

Để thẩm tra chức năng, nạp một đĩa CD và thử chạy:

# mount /cdrom    # câu lệnh này gắn kết đĩa CD tới điểm lắp
# ls -alF /cdrom  # câu lệnh này nên hiển thị thư mục gốc của đĩa CD
# umount /cdrom   # câu lệnh này sẽ tháo gắn kết đĩa CD

Sau đó thì chạy:

# apt-cdrom add

cho mỗi đĩa CD nhị phân Debian, để thêm dữ liệu về mỗi đĩa CD vào co sở dữ liệu của APT.

Rất khuyên người dùng sử dụng chương trình /usr/bin/script để thu một bản sao của phiên chạy nâng cấp. Như thế, nếu một vấn đề xảy ra, có một bản sao mọi hành vi, và nếu cần, người dùng có thể cung cấp thông tin chính xác trong một báo cáo lỗi hay báo cáo nâng cấp. Để bắt đầu thu, hãy gõ câu lệnh:

# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script

hay tương tự. Đừng để bản sao vào một thư mục tạm thời như /tmp hay /var/tmp (các tập tin trong hai thư mục này có thể bị xoá trong khi nâng cấp hoặc khi nào khởi động lại).

Bản sao này cũng cho phép xem lại thông tin đã cuộn qua màn hình. Chỉ chuyển đổi sang VT2 (dùng tổ hợp phím Alt+F2) và, sau khi đăng nhập, dùng câu lệnh less -R ~root/upgrade-lenny.script để xem tập tin đó.

Sau khi nâng cấp xong, người dùng có thể dừng chạy script bằng cách gõ lệnh thoát exit vào dấu nhắc.

Có đặt cờ -t trong câu lệnh script nói trên thì người dùng cũng có thể sử dụng chương trìnhscriptreplay để phát lại toàn bộ phiên chạy.

# scriptreplay ~/upgrade-lenny.time ~/upgrade-lenny.script

Trước tiên nên lấy danh sách các gói sẵn sàng cho bản phát hành mới. Việc này được làm bằng cách chạy câu lệnh cập nhật:

# aptitude update

Việc chạy câu lệnh này lần đầu tiên cập nhật các nguồn mới sẽ in ra một số cảnh báo liên quan đến tính sẵn sàng của các nguồn. Những cảnh báo này vô hại và chỉ xuất hiện một lần.

Trước khi nâng cấp hệ thống, người dùng cần phải kiểm tra có đủ sức chứa còn lại trên đĩa cứng, đặc biệt khi khởi chạy tiến trình nâng cấp hệ thống đầy đủ diễn tả trong Phần 4.5.7, “Nâng cấp phần hệ thống còn lại”. Trước tiên, bất cứ gói nào cần cài đặt được lấy từ mạng và cất giữ trong thư mục /var/cache/apt/archives (cũng trong thư mục con partial/ trong khi tải về), do đó người dùng cần phải kiểm tra có đủ sức chứa còn lại trên phân vùng đó (phân vùng hệ thống tập tin chứa /var) để tải về tạm thời tất cả các gói cần cài đặt vào hệ thống. Sau khi tải về, rất có thể là cần thêm sức chứa trống trong các phiên bản hệ thống tập tin khác để cài đặt cả hai các gói đã nâng cấp (mà có thể chứa các tập tin nhị phân lớn hơn hay dữ liệu bổ sung) và các gói mới được lấy cho quá trình nâng cấp. Nếu hệ thống không có đủ sức chứa trống, kết quả có thể là một quá trình nâng cấp chưa xong, một trường hợp có thể khó phục hồi.

Cả hai aptitude và apt sẽ hiển thị thông tin chi tiết về sức chứa trống trên đĩa mà cần thiết để cài đặt. Trước khi khởi chạy tiến trình nâng cấp, người dùng có thể thấy sự ước lượng này bằng cách chạy câu lệnh:

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX gói được nâng cấp, XXX mới được cài đặt, XXX cần gỡ bỏ và XXX không được nâng cấp.
Cần phải lấy xx.xMB/yyyMB kho. Sau khi giải nén AAAMB sẽ được chiếm.
Nên tải về / cài đặt/ gỡ bỏ các gói.

	Ghi chú
	Việc chạy câu lệnh này ở đầu của quá trình nâng cấp cũng có thể xuất một lỗi, vì lý do diễn tả trong các phần kế tiếp. Trong trường hợp đó, người dùng cần phải đợi đến khi hoàn tất quá trình nâng cấp hệ thống tối thiểu (xem Phần 4.5.6, “Nâng cấp hệ thống tối thiểu”) và hoàn tất nâng cấp hạt nhân trước khi chạy lại câu lệnh này để ước lượng sức chứa còn trống trên đĩa.

Không có đủ sức chứa để nâng cấp thì trước tiên người dùng phải giải phóng thêm sức chứa. Ví dụ :

Ghi chú rằng để gỡ bỏ gói một cách an toàn, khuyên người dùng chuyển đổi tập tinsources.list về etch như diễn tả trong Phần A.2, “Kiểm tra danh sách nguồn”.

Vài báo cáo lỗi đã chứng minh rằng những phiên bản aptitude và apt trong etch thường không thể nâng cấp được lên lenny. Trong lenny, apt quản lý khá hơn các dãy gói phức tạp vẫn cần thiết cấu hình lập tức, và aptitude khéo hơn khi giải quyết quan hệ phụ thuộc. Hai tính năng này chủ yếu trong quá trình nâng cấp dist-upgrade lên lenny, thì cần phải nâng cấp hai gói đó trước khi nâng cấp gì khác. Đối với apt, hãy chạy câu lệnh:

# apt-get install apt

và đối với aptitude (nếu cài đặt), chạy câu lệnh:

# aptitude install aptitude

Bước này sẽ tự động nâng cấp hai gói libc6 và locales, và gọi các thư viện hỗ trợ SELinux (libselinux1). Tại thời điểm này, một số dịch vụ hệ thống đang chạy sẽ được khởi chạy lại, bao gồm xdm, gdm và kdm. Kết quả là phiên chạy X11 cục bộ nào có thể bị ngắt kết nối.

Phần mềm aptitude bảo tồn một danh sách các gói đã được tự động cài đặt (v.d. do quan hệ phụ thuộc với một gói khác). Trong lenny, apt cũng có tính năng này.

Lần đầu tiên chạy phiên bản lenny của aptitude thì nó đọc danh sách các gói tự động cài đặt, và chuyển đổi nó để sử dụng với phiên bản lenny của apt. Người dùng đã cài đặt aptitude về trước thì cần phải chạy ít nhất một câu lệnh aptitude để sơ khởi quá trình chuyển đổi này. Thí dụ, tìm kiếm một gói không tồn tại:

# aptitude search "?false"

Do một số sự xung đột gói giữa etch và lenny, việc chạy câu lệnh aptitude dist-upgrade một cách trực tiếp sẽ thường gỡ bỏ rất nhiều gói mà người dùng muốn giữ. Vì lý do đó, khuyên người dùng chạy một quá trình nâng cấp có hai phần riêng: trước tiên một việc nâng cấp tối thiểu để giải quyết trường hợp xung đột, và sau đó một việc dist-upgrade đầy đủ.

Trước tiên, chạy câu lệnh:

# aptitude safe-upgrade

Kết quả là nâng cấp những gói có thể nâng cấp được mà không cần gỡ bỏ hay cài đặt gói khác nào.

Bước kế tiếp vẫn biến đổi phụ thuộc vào tập hợp gói được cài đặt hiện thời. Ghi chú Phát hành này chỉ có thể cung cấp lời khuyên chung về phương pháp nên dùng, nhưng nếu chưa chắc, rất khuyên người dùng xem lại danh sách các gói nên gỡ bỏ tùy theo mỗi phương pháp, trước khi tiếp tục.

Phương pháp này có thể gỡ bỏ một số gói thường dùng, bao gồm base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common và xserver-common. Để tìm thêm thông tin về những gói đã lỗi thời trong lenny, xem Phần 4.10, “Gói quá cũ”.

Sau đó thì có thể tiếp tục phần chính của quá trình nâng cấp. Chạy câu lệnh:

# aptitude dist-upgrade

Câu lệnh này sẽ nâng cấp hoàn toàn hệ thống, tức là cài đặt phiên bản mới nhất của mọi gói sẵn sàng, và giải quyết mọi quan hệ phụ thuộc có thể biến đổi trong bản phát hành khác nhau. Nếu cần thiết, nó sẽ cài đặt một số gói mới (thường là phiên bản thư viện mới, hay gói bị thay tên), và gỡ bỏ gói quá cũ nào bị xung đột.

Khi nâng cấp từ một bộ đĩa CD/DVD, người dùng sẽ được nhắc nạp một đĩa nào đó ở vài điểm thời trong quá trình nâng cấp. Có lẽ cần phải nạp nhiều lần cùng một đĩa, do các gói liên quan đến nhau mà được chia ra các đĩa khác nhau.

Gói được cài đặt hiện thời mà không thể nâng cấp mà không thay đổi trạng thái cài đặt của một gói khác, sẽ còn lại ở phiên bản hiện thời (đánh dấu là “giữ lại”). Vẫn còn có thể cài đặt phiên bản mới bằng cách sử dụng aptitude để tự chọn những gói phiên bản mới, hoặc bằng cách thử chạy câu lệnh aptitude -f install tên_gói để cài đặt mỗi gói phiên bản mới.

Nếu một thao tác dùng aptitude, apt-get hay dpkg không thành công và xuất lỗi

E: Hết chỗ tạo sơ đồ bộ nhớ động (Dynamic MMap)

thì không đủ sức chứa nhớ tạm mặc định. Quản trị có thể giải quyết vấn đề này bằng cách gỡ bỏ hay tắt ghi chú các dòng không cần thiết trong tập tin /etc/apt/sources.list, hoặc tăng kích cỡ vùng nhớ tạm (đặt APT::Cache-Limit trong tập tin cấu hình /etc/apt/apt.conf. Câu lệnh theo đây sẽ đặt một giá trị nên đủ để nâng cấp:

# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Câu lệnh này giả sử chưa đặt biến này trong tập tin đó.

Đôi khi cần phải hiệu lực tùy chọn APT::Force-LoopBreak trong APT để có khả năng tạm thời gỡ bỏ một gói chủ yếu do một vòng lặp Xung đột/Phụ thuộc trước. aptitude sẽ thông báo về vòng lặp này và hủy bỏ quá trình nâng cấp. Vẫn còn có thể giải quyết vấn đề này bằng cách xác định tùy chọn -o APT::Force-LoopBreak=1 trên dòng lệnh aptitude.

Một trường hợp ít xảy ra là hệ thống có cấu trúc quan hệ phụ thuộc quá bị hỏng mà cần quản trị tự can thiệp. Có thể sử dụng aptitude hoặc

# dpkg --remove tên_gói

để loại trừ một số gói phạm lỗi, hoặc

# aptitude -f install
# dpkg --configure --pending

Trong trường hợp rất khó, bạn có thể cần phải ép buộc cài đặt lại, dùng một câu lệnh như

# dpkg --install /đường/dẫn/tới/tên_gói.deb

Trường hợp tập tin bị xung đột không nên xảy ra khi nâng cấp từ một hệ thống etch “thuần”, nhưng vẫn còn có thể xảy ra nếu hệ thống chứa bản chuyển ngược không chính thức. Sự xung đột giữa các tập tin sẽ gây ra một lỗi như :

Đang giải nén <tên_gói1> (từ <tập_tin_gói1>) ...
dpkg: gặp lỗi khi xử lý <tên_gói1> (--install):
 đang thử ghi đè lên `<tên_tập_tin>',
 mà cũng nằm trong gói <tên_gói2>
dpkg-deb: tiến trình con dán bị tín hiệu giết (Ống dẫn bị vỡ)
 Gập lỗi khi xử lý:
 <tên_gói1>

Quản trị cũng có thể thử giải quyết một trường hợp các tập tin bị xung đột bằng cách ép buộc gỡ bỏ gói có tên trên dòng cuối cùng của thông điệp lỗi:

# dpkg -r --force-depends tên_gói

Sau khi sửa chữa, quản trị nên có thể tiếp tục lại quá trình nâng cấp bằng cách lặp lại những câu lệnh aptitude diễn tả trước.

Trong khi nâng cấp, tiến trình sẽ hỏi câu về cách cấu hình (lại) vài gói. Khi quá trình hỏi nếu tập tin nào trong thư mục /etc/init.d hay /etc/terminfo, hoặc tập tin /etc/manpath.config, nên được thay thế bằng phiên bản của phần mềm quản lý gói, thường nên đồng ý để đảm bảo hệ thống vẫn thống nhất. Lúc sau, cũng có thể hoàn nguyên mỗi phiên bản cũ, vì nó sẽ được lưu với một phần mở rộng .dpkg-old.

Chưa chắc nên làm gì thì viết tên của gói hay tập tin đó, và tháo gỡ trường hợp vào một lúc sau. Cũng có thể tìm kiếm qua tập tin typescript để xem lại thông tin đã cuộn qua trên màn hình trong khi nâng cấp.

Khi chạy quá trình nâng cấp bản phát hành (dist-upgrade) từ etch lên lenny, rất khuyên quản trị cài đặt một siêu gói (metapackage) linux-image-2.6-* mới. Gói này cũng có thể được tự động cài đặt bởi tiến trình dist-upgrade. Quản trị có thể kiểm tra nó đã được cài đặt bằng cách chạy câu lệnh:

# dpkg -l "linux-image*" | grep ^ii

Không có kết xuất gì thì quản trị cần phải tự cài đặt một gói linux-image-2.6-*. Để thấy danh sách các gói linux-image-2.6-* sẵn sàng, chạy câu lệnh:

# apt-cache search linux-image-2.6- | grep -v transition

Chưa chắc về gói nào nên chọn thì chạy câu lệnh uname -r và tìm một gói có tên tương tự. Ví dụ, nếu thấy chuỗi « 2.6.18-6-686 », khuyên quản trị cài đặt gói linux-image-2.6-686. (Ghi chú rằng mùi vị k7 không còn tồn tại lại: quản trị hiện thời sử dụng mùi vị hạt nhân 386 thì nên dùng mùi vị 686 để thay thế.) Cũng có thể sử dụng công cụ apt-cache để hiển thị một mô tả chi tiết về mỗi gói, để giúp chọn gói thích hợp nhất. Ví dụ :

# apt-cache show linux-image-2.6-686

Sau đó thì có nên sử dụng câu lệnh cài đặt aptitude install để cài đặt nó. Một khi cài đặt hạt nhân mới, quản trị nên khởi động lại càng sớm càng có thể, để lợi dụng phiên bản hạt nhân mới.

Cho quản trị liều lĩnh hơn, có một phương pháp dễ để biên dịch hạt nhân riêng trên Debian GNU/Linux. Hãy cài đặt công cụ kernel-package và đọc các tài liệu hướng dẫn trong thư mục /usr/share/doc/kernel-package.

Nếu có thể, tốt hơn khi nâng cấp gói hạt nhân một cách riêng với quá trình dist-upgrade chính, để tránh bị đứng với một hệ thống tạm thời không khởi động được. Ghi chú rằng thao tác này chỉ nên được làm đằng sau quá trình nâng cấp tối thiểu diễn tả trong Phần 4.5.6, “Nâng cấp hệ thống tối thiểu”.

lenny cung cấp một cơ chế phát hiện phần cứng mà mạnh mẽ hơn các bản phát hành trước. Tuy nhiên, cơ chế này có thể sửa đổi thứ tự phát hiện thiết bị trên hệ thống, mà ảnh hưởng đến thứ tự gán tên thiết bị. Ví dụ, nếu có hai bộ tiếp hợp liên quan đến hai trình điều khiển khác nhau, thì hai chuỗi eth0 và eth1 có thể tham chiếu đến hai thiết bị bị trao đổi, so với bản phát hành trước. Ghi chú rằng dùng cơ chế mới (v.d.) việc chuyển đổi bộ tiếp hợp Ethernet trong một hệ thống lenny đang chạy có kết quả là bộ tiếp hợp mới sẽ cũng nhận một tên giao diện mới.

Đối với thiết bị mạng, quản trị có thể tránh trường hợp này bằng cách sử dụng các quy tắc của udev, chính xác hơn thông qua những lời xác định ở /etc/udev/rules.d/70-persistent-net.rules^[4]. Hoặc quản trị có thể sử dụng tiện ích ifrename để đóng kết mỗi thiết bị vật lý tới một tên riêng vào lúc khởi động. Xem ifrename(8) và iftab(5) để tìm thêm thông tin. Hai phần mềm khác nhau (udev và ifrename) không nên được dùng đồng thời.

Đối với thiết bị lưu trữ, quản trị có thể tránh trường hợp thay đổi thứ tự này bằng cách sử dụng gói công cụ initramfs-tools và cấu hình nó để nạp các mô-đun trình điều khiển thiết bị lưu trữ theo thứ tự được nạp hiện thời. Để làm như thế, hãy tìm thứ tự theo đó các thiết bị lưu trữ được nạp vào hệ thống bằng cách xem lại kết xuất của lsmod. Công cụ lsmod liệt kê các mô-đun theo thứ tự nạp đảo ngược, tức là mô-đun thứ nhất trong danh sách là mô-đun được nạp cuối cùng. Ghi chú rằng phương pháp này chỉ có tác động với thiết bị mà hạt nhân đến theo một thứ tự ổn định (v.d. thiết bị PCI).

Tuy nhiên, việc gỡ bỏ và nạp lại mô-đun sau khi khởi động đầu tiên sẽ ảnh hưởng đến thứ tự này. Hơn nữa, hạt nhân trên máy có thể liên kết tĩnh một số trình điều khiển, và các tên này sẽ không xuất hiện trong kết xuất của lsmod. Quản trị cũng có thể xem lại bản ghi /var/log/kern.loghay kết xuất của dmesg để thử phân biệt những tên trình điều khiển này và thứ tự nạp.

Hãy thêm những tên mô-đun này vào /etc/initramfs-tools/modules theo thứ tự nên nạp vào lúc khởi động. Một số tên mô-đun có thể thay đổi giữa etch và lenny. Ví dụ, sym53c8xx_2 đã trở thành sym53c8xx.

Sau đó thì quản trị cần phải tạo ra lại (các) ảnh initramfs bằng cách chạy câu lệnh update-initramfs -u -k all.

Một khi chạy một hạt nhân lenny và udev, quản trị cũng có thể cấu hình lại hệ thống để truy cập đến đĩa theo một biệt hiệu không phụ thuộc vào thứ tự nạp trình điều khiển. Các biệt hiệu này nằn trong cây thư mục /dev/disk/.

Nếu khởi động hệ thống dùng một initrd được tạo dùng initramfs-tools, trong một số trường hợp các tập tin thiết bị được udev tạo quá trễ để văn lệnh khởi động xử lý.

Trường hợp này thường ngụ ý khi không khởi động được vì không thể gắn kết hệ thống tập tin gốc, và màn hình hiển thị một trình bao gỡ lỗi. Tuy nhiên, nếu quản trị kiểm tra về sau, tất cả các thiết bị cần thiết có phải nằm trong /dev. Trường hợp này đã xảy ra khi hệ thống tập tin gốc nằm trên một đĩa USB hay một mảng RAID, đặc biệt khi dùng LILO.

Có thể chỉnh lại vấn đề này bằng cách sử dụng tham số khởi động rootdelay=9 (khoảng đợi khởi động: 9 giây). Điều chỉnh giá trị này để thích hợp với trường hợp riêng.

Nếu hệ thống sử dụng lilo là công cụ nạp khởi động (nó là bộ nạp khởi động cho một số bản cài đặt etch) rất khuyên quản trị chạy lilo lần nữa sau khi nâng cấp:

# /sbin/lilo

Ghi chú rằng cần phải chạy lại lilo thậm chí nếu hạt nhân chưa được nâng cấp, vì giai đoạn thứ hai của lilo sẽ thay đổi so quá trình nâng cấp gói.

Hơn nữa, hãy xem lại nội dung của tập tin cấu hình /etc/kernel-img.conf và kiểm tra nó chứa chuỗi do_bootloader = Yes (làm bộ nạp khởi động = Có). Do đó, bộ nạp khởi động lúc nào cũng chạy sau khi nâng cấp hạt nhân.

Gặp vấn đề nào khi chạy lilo thì hãy so sánh các liên kết tượng trưng trong cây thư mục / mà chỉ tới vmlinuz và initrd với nội dung của tập tin cấu hình /etc/lilo.conf.

Nếu người dùng quên chạy lại lilo trước khi khởi động lại, hoặc hệ thống tình cờ được khởi động lại trước khi người dùng có thể tự làm như thế, hệ thống có thể sẽ không khởi động được. Thay cho dấu nhắc lilo, người dùng sẽ chỉ thấy LI khi khởi động hệ thống^[5]. Xem Phần 4.1.3, “Chuẩn bị phục hồi” để tìm thông tin về cách phục hồi từ trường hợp này.

Vẫn có thể tránh vấn đề này một cách hoàn toàn bằng cách sử dụng một bộ nhận diện cho hệ thống tập tin gốc mà không biến đổi giữa hai việc khởi động. Có hai phương pháp có thể làm như thế: đặt nhãn hệ thống tập tin, hoặc sử dụng bộ nhận diện duy nhất toàn thể (UUID). Hai phương pháp này được hỗ trợ trong Debian kể từ 4.0.

Hai phương pháp này có lợi ích và bất lợi. Phương pháp đặt nhãn vẫn dễ đọc hơn, nhưng cũng có thể gặp vấn đề nếu một hệ thống tập tin khác cùng máy có nhãn đó. Phương pháp UUID ít đẹp hơn, nhưng rất ít có thể tạo hai UUID xung đột.

Trong các mẫu thí dụ dưới đây, giả sử hệ thống tập tin gốc nằm trên /dev/hda6. Cũng giả sử hệ thống có bản cài đặt udev và hệ thống tập tin kiểu ext2 hay ext3.

Để thực hiện phương pháp đặt nhãn:

Để thực hiện phương pháp UUID:

Một số gọi nào đó từ etch đã bị chia ra vài gọi khác nhau trong lenny, thường để cải tiến khả năng bảo tồn hệ thống. Để làm dễ dàng đường dẫn nâng cấp trong các trường hợp như vậy, lenny thường cung cấp các gói “giả”: gói trống cùng tên với gói cũ trong etch với quan hệ phụ thuộc mà gây ra cài đặt gói mới. Sau khi nâng cấp, các gói “giả” được thấy là quá cũ thì có thể được gỡ bỏ an toàn.

Hậu hết (nhưng không phải tất cả các) mô tả về gói giả cũng ngụ ý mục đích của nó. Tuy nhiên, các mô tả gói về gói giả không phải thống nhất, do đó cũng có ích để sử dụng deborphan với tùy chọn --guess (đoán) để phát hiện gói giả trong hệ thống. Ghi chú rằng một số gói giả nào đó không dự định được gỡ bỏ sau khi nâng cấp, vì chúng được dùng để theo dõi phiên bản sẵn sàng hiện thời của một chương trình nào đó trong thời gian.