4.1. Preparing for the upgrade

We suggest that before upgrading you also read the information in Chapter 5, Issues to be aware of for buster. That chapter covers potential issues which are not directly related to the upgrade process but could still be important to know about before you begin.

4.1.1. Back up any data or configuration information Before upgrading your system, it is strongly recommended that you make a full backup, or at least back up any data or configuration information you can't afford to lose. The upgrade tools and process are quite reliable, but a hardware failure in the middle of an upgrade could result in a severely damaged system. The main things you'll want to back up are the contents of /etc , /var/lib/dpkg , /var/lib/apt/extended_states and the output of dpkg --get-selections "*" (the quotes are important). If you use aptitude to manage packages on your system, you will also want to back up /var/lib/aptitude/pkgstates . The upgrade process itself does not modify anything in the /home directory. However, some applications (e.g. parts of the Mozilla suite, and the GNOME and KDE desktop environments) are known to overwrite existing user settings with new defaults when a new version of the application is first started by a user. As a precaution, you may want to make a backup of the hidden files and directories (“dotfiles”) in users' home directories. This backup may help to restore or recreate the old settings. You may also want to inform users about this. Any package installation operation must be run with superuser privileges, so either log in as root or use su or sudo to gain the necessary access rights. The upgrade has a few preconditions; you should check them before actually executing the upgrade.

4.1.2. Inform users in advance It's wise to inform all users in advance of any upgrades you're planning, although users accessing your system via an ssh connection should notice little during the upgrade, and should be able to continue working. If you wish to take extra precautions, back up or unmount the /home partition before upgrading. You will have to do a kernel upgrade when upgrading to buster, so a reboot will be necessary. Typically, this will be done after the upgrade is finished.

4.1.3. Prepare for downtime on services There might be services that are offered by the system which are associated with packages that will be included in the upgrade. If this is the case, please note that, during the upgrade, these services will be stopped while their associated packages are being replaced and configured. During this time, these services will not be available. The precise downtime for these services will vary depending on the number of packages being upgraded in the system, and it also includes the time the system administrator spends answering any configuration questions from package upgrades. Notice that if the upgrade process is left unattended and the system requests input during the upgrade there is a high possibility of services being unavailable for a significant period of time. If the system being upgraded provides critical services for your users or the network , you can reduce the downtime if you do a minimal system upgrade, as described in Section 4.4.4, “Minimal system upgrade”, followed by a kernel upgrade and reboot, and then upgrade the packages associated with your critical services. Upgrade these packages prior to doing the full upgrade described in Section 4.4.5, “Upgrading the system”. This way you can ensure that these critical services are running and available through the full upgrade process, and their downtime is reduced.

4.1.4. Prepare for recovery Although Debian tries to ensure that your system stays bootable at all times, there is always a chance that you may experience problems rebooting your system after the upgrade. Known potential issues are documented in this and the next chapters of these Release Notes. For this reason it makes sense to ensure that you will be able to recover if your system should fail to reboot or, for remotely managed systems, fail to bring up networking. If you are upgrading remotely via an ssh link it is recommended that you take the necessary precautions to be able to access the server through a remote serial terminal. There is a chance that, after upgrading the kernel and rebooting, you will have to fix the system configuration through a local console. Also, if the system is rebooted accidentally in the middle of an upgrade there is a chance you will need to recover using a local console. For emergency recovery we generally recommend using the rescue mode of the buster Debian Installer. The advantage of using the installer is that you can choose between its many methods to find one that best suits your situation. For more information, please consult the section “Recovering a Broken System” in chapter 8 of the Installation Guide and the Debian Installer FAQ. If that fails, you will need an alternative way to boot your system so you can access and repair it. One option is to use a special rescue image or a Linux live CD. After booting from that, you should be able to mount your root file system and chroot into it to investigate and fix the problem. 4.1.4.1. Debug shell during boot using initrd The initramfs-tools package includes a debug shell in the initrds it generates. If for example the initrd is unable to mount your root file system, you will be dropped into this debug shell which has basic commands available to help trace the problem and possibly fix it. Basic things to check are: presence of correct device files in /dev ; what modules are loaded ( cat /proc/modules ); output of dmesg for errors loading drivers. The output of dmesg will also show what device files have been assigned to which disks; you should check that against the output of echo $ROOT to make sure that the root file system is on the expected device. If you do manage to fix the problem, typing exit will quit the debug shell and continue the boot process at the point it failed. Of course you will also need to fix the underlying problem and regenerate the initrd so the next boot won't fail again. 4.1.4.2. Debug shell during boot using systemd If the boot fails under systemd, it is possible to obtain a debug root shell by changing the kernel command line. If the basic boot succeeds, but some services fail to start, it may be useful to add systemd.unit=rescue.target to the kernel parameters. Otherwise, the kernel parameter systemd.unit=emergency.target will provide you with a root shell at the earliest possible point. However, this is done before mounting the root file system with read-write permissions. You will have to do that manually with: # mount -o remount,rw / More information on debugging a broken boot under systemd can be found in the Diagnosing Boot Problems article.

4.1.5. Prepare a safe environment for the upgrade Important If you are using some VPN services (such as tinc ) consider that they might not be available throughout the upgrade process. Please see Section 4.1.3, “Prepare for downtime on services”. In order to gain extra safety margin when upgrading remotely, we suggest that you run upgrade processes in the virtual console provided by the screen program, which enables safe reconnection and ensures the upgrade process is not interrupted even if the remote connection process temporarily fails.