How to upgrade our perfect server based on Debian 10 (Buster) to Debian 11 (Bullseye) (page 2)

botond published 2023/01/31, k - 11:21 time

Content

  1. page: Completing pre-update tasks
  2. page: Upgrade Debian 10 (Buster) to Debian 11 (Bullseye).
  3. page: Checking the server after the update and making subsequent settings

 

2. page content

 

Continuation

Az previous page we reviewed the necessary tasks before the update, which we used to prepare our system for the new major version, and on this page we continue with the update of the distribution to the Debian 11 (Bullseye) system.

 

 

Updating the Debian distribution

If all is well around our packages, we can start upgrading to the main version.

Full update of current (Debian 10) distribution

First, run the normal apt-get update command followed by the full distribution update:

apt-get upgrade
apt-get dist-upgrade
dist-upgrade option provides the usual upgrade features, as well as intelligently managing changing dependencies with new versions of packages. So this package manager tool updates packages with a more advanced conflict resolution mechanism, so our system can better catch up with further updates in the next release of Debian.
Az apt-get dist-upgrade command is equivalent to apt full-upgrade command, so you can use any of them here to run the full update.

I didn't have anything to update here now:

dist-upgrade / full-upgrade matches

But in other cases, there were already examples of him updating for a long time at this time.

Recheck packages

If the previous full update involved updating many packages, we check our packages again in the ways already described on the first page:

  • Search for withheld packages
  • Search for broken packages
  • Remove packages that have become redundant

Here, it is only necessary to check these at this time.

If, on the other hand, like here, you have updated nothing or only a few packages, you can skip this verification step, because in this case no special changes have occurred in the package database.

Modifying APT source list files for Debian 11

In this section, we modify the source list file of APT so that it can update the packages from the Debian 11 repositories.

First, make a backup copy of the sources.list file:

cp /etc/apt/sources.list /etc/apt/sources.list.bak

Open the sources.list file for editing:

nano /etc/apt/sources.list

Original contents of /etc/apt/sources.list file

#

# deb cdrom:[Debian GNU/Linux 10.1.0 _Buster_ - Official amd64 NETINST 20190908-01:07]/ buster main

#deb cdrom:[Debian GNU/Linux 10.1.0 _Buster_ - Official amd64 NETINST 20190908-01:07]/ buster main

deb http://deb.debian.org/debian/ buster main contrib non-free
deb-src http://deb.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

# buster-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ buster-updates main contrib non-free
deb-src http://deb.debian.org/debian/ buster-updates main contrib non-free

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.


# Backports tároló
deb https://deb.debian.org/debian buster-backports main contrib non-free

# Sury.org tároló (felvéve: 2020-01-27)
deb https://packages.sury.org/php/ buster main
In this update, the from updating previous distributions references to some packages must be rewritten in a slightly different way!
In the past, only the code names of the distributions (e.g. stretch/buster/bullseye) changed for each package reference, but in Debian 11 the package structure also changed for the security.debian.org mirror.

So, for example, what was the following in the case of Debian 10:

deb http://security.debian.org/debian-security buster/updates main contrib non-free

On Debian 11 it looks like this:

deb http://security.debian.org/debian-security bullseye-security main contrib non-free

So for this package, it is not enough to just rewrite the code names, but to change "buster/updates" to "bullseye-security" in Debian 11. In essence, the package directory was moved one subdirectory further out, which then also received a hyphenated name, just like the other package directories.

 

 

Debian 10 security package repository:

Debian 10 (Buster) Security package link

And the Debian 11 security package:

Debian 11 (Bullseye) Security package link

This only affects the security package, for the others (deb.debian.org (in the case of mirrors starting with

Debian 10 (Buster) buster-updates:

Debian 10 (Buster) buster-updates

Debian 11 (Bullseye) bullseye-updates:

Debian 11 (Bullseye) bullseye-updates

So there is no other difference between them, only the code names have to be exchanged. The same goes for backports containers.

So this above structural change is only a security.debian.org touches the mirror at address, while a deb.debian.org not the one at the address, because the arrangement is already in this form there.

We can make these changes manually, but we can entrust it to the thirst command, if we don't want to miss the changes.
In this case, we can modify our source list files accordingly with the following commands:

  1. First, we modify the security packages in the sources.list file, since they are multi-word replacements:
    sed -i 's/buster\/updates/bullseye-security/g' /etc/apt/sources.list
  2. Then we also modify the other package links in the sources list file, so here we only change the code names:
    sed -i 's/buster/bullseye/g' /etc/apt/sources.list
  3. Then in all the source list files in the sources.list.d directory, we replace any security packages:
    sed -i 's/buster\/updates/bullseye-security/g' /etc/apt/sources.list.d/*.list
  4. Finally, in all the source list files in the sources.list.d directory, we replace the other packages, also with only the code names:
    sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*.list

Modifying repositories with the sed command

I don't have a single source list file in the sources.list.d directory, which is why the last two commands threw an error.

a-sources-list-file-a-modositas-utan

There is also a _Buster_ part left over from the commented out cdrom parts, but that is no longer important, we don't use a CDrom...

After the modification, my own sources.list file is also copied:

#

# deb cdrom:[Debian GNU/Linux 10.1.0 _Buster_ - Official amd64 NETINST 20190908-01:07]/ bullseye main

#deb cdrom:[Debian GNU/Linux 10.1.0 _Buster_ - Official amd64 NETINST 20190908-01:07]/ bullseye main

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

# bullseye-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.


# Backports tároló
deb https://deb.debian.org/debian bullseye-backports main contrib non-free

# Sury.org tároló (felvéve: 2020-01-27)
deb https://packages.sury.org/php/ bullseye main
This file is of course just a sample, with which I would like to demonstrate how the changes are made. However, if we have the same server configuration as I'm working with here, we can take this file one at a time.

If you are done with the change, run it JUST updating the package database, updating the package NOT YET let's run!

apt-get update

The output of the apt-get update command

Here, it downloads the new package repositories for the first time, after which we get the usual output of a few lines if we run the same command again.

It ran without error here. If an error occurs somewhere, it is likely that a third-party package repository that does not contain Debian 11 packages has not been removed. In such cases, it is advisable to look on the website of the given software to see if the package repository for Debian 11 can be found at another url, etc.

 

 

The simulation of updating packages

Here we still run a simulation and see which packages can be upgraded and which cannot. To do this, run the following command:

apt list --upgradable

For me, the output is:

The simulation of updating packages

After that, an error query and a re-run by checking the number of packages. Just out of curiosity.
I now have 953 upgradeable packages.

If there are no errors here, then we can continue. If you happen to find a package that cannot be updated in the list, you have to proceed in a unique way. For example, remove the package in question, find an alternative, etc.

Basic upgrade from Debian 11 (Bullseye) repositories

After the simulation, we first perform a basic update, which only updates packages that do not require the installation or removal of other packages. To do this, issue the usual command:

apt-get upgrade

Basic upgrade of Debian packages

In my case, it will update only 510 packages out of 953 in this round.

Continue with the Yes option.

The package manager works for a while and then stops in some cases while we wait for our intervention.

We will review these as well, but I would point out that these are the only cases of this ISPConfigappear when you update your server configuration, you may have to stop on another server to configure other packages and services. So let’s just look at these as an example, let’s make an impromptu for things other than that, taking into account the previous settings of the components on our server.
However, if you upgrade on exactly the same server as I mentioned at the beginning of this description, chances are you'll get the same issues.

Here are some of the following:

  • Scrollable sections that display text that you can exit with the "q" key - continuing the upgrade process.
  • Text mode color dialog windows, where you are asked questions about the update, which you can answer by choosing from several options.
  • Show configuration conflicts where we compare previously modified configurations to the default settings of newer versions of packages, where we need to decide which version to use

In the future, we can therefore expect such things, among which there will be those that appear for everyone, and those that only appear in the case of a specific configuration where the given program or service is installed. Here, I recommend following the same part of the previous update description as you go, because there were some overlaps in it, but other cases also occurred. Thus, by using the description of the two update processes at the same time, we can get a wider range of examples for the unique solution of our own situation:

Now let's see my concrete example:

APT list changes

The first is APT package manager changes, it will be visible to everyone:

APT - news

Displays the apt package manager version log. In this interface, you can use the mouse scroll wheel and the up and down keys to scroll through the text, and you can exit the update process by pressing the "q" key.

Package configuration: libpam0g

I have the here now libpam0g package configuration comes:

Package Configuration - libpam0g

 ┌────────────────────────────────────────────────────────────────┤ libpam0g:amd64 konfigurálása ├────────────────────────────────────────────────────────────────┐
 │                                                                                                                                                                │
 │ There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these     │
 │ restarts may cause interruptions of service for the system, you will normally be prompted on each upgrade for the list of services you wish to restart.  You   │
 │ can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being asked questions on   │
 │ each library upgrade.                                                                                                                                          │
 │                                                                                                                                                                │
 │ Restart services during package upgrades without asking?                                                                                                       │
 │                                                                                                                                                                │
 │                                                 <Igen>                                                   <Nem>                                                 │
 │                                                                                                                                                                │
 └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

The point here is that updating many function libraries requires restarting some services, which causes the services to be interrupted. By default, the system requests the user's permission for each such service restart. Here, in this question, you offer to allow it to restart the mentioned services automatically, so you don't have to ask for permission in every case.

This type of (Whiptail/Ncurses) on panels a Tab key, we can navigate between the options that may appear in the upper part of the panel and the answer options below. In this case, there are no options to choose from above, so the row of options below is the active part of the panel.

Select "Yes" here and move on.

The update continues...

 

 

Configuration conflict: munin.conf

The next question already asks about a custom setting, regarding the /etc/munin/munin.conf file:

Configuration conflict: munin.conf

Configuration file '/etc/munin/munin.conf'
 ==> Modified (by you or by a script) since installation.
 ==> A csomag terjesztője frissített.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 Az alapművelet a jelenlegi változatod megtartása.
*** munin.conf (Y/I/N/O/D/Z) [alapművelet=N:nem] ?

If you have the same server installed, so Debian 10 is the perfect server at the time of installation we have modified this file in this section. Here, scrolling down a bit, we find the modification of the munin.conf file, so if this configuration conflicting part appears, then we must have set this file, which is therefore now different from the configuration in the updated package.

Here, in this case, let's keep our own version, so choose the "N" option.

Package configuration: grub-pc

In the next step a GRUB bootloader grub-pc package configuration comes in:

Package Configuration - grub-pc

 ┌───────────────────────────────────────────────────────────────────┤ grub-pc konfigurálása ├────────────────────────────────────────────────────────────────────┐
 │ A GRUB rendszerbetöltő korábban egy olyan lemezre volt telepítve, amely hiányzik vagy amelynek megváltozott az egyedi azonosítója. Fontos, hogy biztosítsuk,   │
 │ hogy a GRUB töltőkép ugyanolyan verziójú legyen, mint a GRUB modulok és a grub.cfg. Kérlek ellenőrizd még egyszer hogy biztosan a megfelelő eszközre írjuk a   │
 │ GRUB-ot.                                                                                                                                                       │
 │                                                                                                                                                                │
 │ Ha nem vagy benne biztos, hogy melyik meghajtó van rendszerlemeznek beállítva a BIOS-ban, jó ötlet lehet mindegyikre feltelepíteni a GRUB-ot.                  │
 │                                                                                                                                                                │
 │ Megjegyzés: A GRUB-ot nemcsak lemez, de partíció rendszerbetöltő részére is lehet telepíteni, és ha van erre alkalmas partíció, azt is felkínáljuk itt. Mivel  │
 │ azonban így a GRUB kénytelen a blokklista módszert (blocklist) alkalmazni, amely kevésbé megbízható, így ez nem javasolt.                                      │
 │                                                                                                                                                                │
 │ GRUB telepítési eszközök:                                                                                                                                      │
 │                                                                                                                                                                │
 │    [*] /dev/sda (42949 MB; VBOX_HARDDISK)                                                                                                                      │
 │    [ ] - /dev/sda1 (38653 MB; /)                                                                                                                               │
 │                                                                                                                                                                │
 │                                                                                                                                                                │
 │                                                                             <Ok>                                                                               │
 │                                                                                                                                                                │
 └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

We mark the disk here, so don't install it on the partition, but in this example on the / Dev / sda to. Then OK, and we can go on.

 

And the basic update has been completed, error code 0.

Basic update completed

 

Full distribution update

After the existing packages have been updated at the base level, a full update must also be performed to complete the entire process. This section installs the latest available versions of all packages and all their possible dependencies.

To do this, run the full upgrade command you used before - here using the Debian 11 repositories:

apt-get dist-upgrade

For me, the output is:

Full distribution update

In this step, the remaining 441 packages are updated, 134 are installed, and 19 are deleted. You will need 366 Mb of disk space for all of this. So here too, the package manager will have a lot to do, where we will also go through the parts that require user intervention, which will be of a similar type to those we have already encountered during the basic update. Select Yes to continue.

APT list changes

An APT changelog appears in this phase of the update process as well, but here it lists the main programs that will now undergo important updates:

APT list changes

You can review this in the same way, if you want, and then press the aq key to go back to continue the update.

Here, the installation and configuration took about 10-20 minutes for me, and then came the next part.

 

 

Package configuration: openssh-server

In the next step it is SSH our server openssh-server configuration of your package comes in.

Package configuration: openssh-server

  ┌───────────────────────────────────────────────────────────────┤ openssh-server konfigurálása ├───────────────────────────────────────────────────────────────┐
  │ A new version (/tmp/tmp.FHTs8hFhkN) of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified.  │
  │                                                                                                                                                              │
  │ What do you want to do about modified configuration file sshd_config?                                                                                        │
  │                                                                                                                                                              │
  │                                                     install the package maintainer's version                                                                 │
  │                                                     keep the local version currently installed                                                               │
  │                                                     show the differences between the versions                                                                │
  │                                                     show a side-by-side difference between the versions                                                      │
  │                                                     show a 3-way difference between available versions                                                       │
  │                                                     do a 3-way merge between available versions                                                              │
  │                                                     start a new shell to examine the situation                                                               │
  │                                                                                                                                                              │
  │                                                                                                                                                              │
  │                                                                            <Ok>                                                                              │
  │                                                                                                                                                              │
  └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

It says here that the / Etc / ssh / sshd_config file has changed, but a newer version came out in the meantime. Let's take a look at the differences, select the "show the differences between the versions" option:

Package configuration: openssh-server

┌─────────────────────┤ openssh-server konfigurálása ├─────────────────────┐
│                                                                          │
│ Line by line differences between versions                                │
│                                                                          │
│ --- /etc/ssh/sshd_config root.root 0644 2023-01-11 03:56:33              │
│ +++ /tmp/tmp.FHTs8hFhkN root.root 0644 2022-07-02 00:37:41               │
│ @@ -10,7 +10,9 @@                                                        │
│  # possible, but leave them commented. Uncommented options override the  │
│  # default value.                                                        │
│                                                                          │
│ -#Port 57345                                                             │
│ +Include /etc/ssh/sshd_config.d/*.conf                                   │
│ +                                                                        │
│ +#Port 22                                                                │
│  #AddressFamily any                                                      │
│  #ListenAddress 0.0.0.0                                                  │
│  #ListenAddress ::                                                       │
│                                                                          │
│                                  <Ok>                                    │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

So much has happened here that one In my previous description, I wrote about SSH unique ports, where I set the custom port, I finally commented it out afterwards, because it was no longer needed, I only set it for the time of the presentation. The system took this as a deviation.

Since there is one more small change at the top, and my custom port setting is already commented out, I will install the latest version here, i.e. go back to the previous menu and select the "install the package maintainer's version" option. Of course, this is also completely individual, who has set what in their own config, so I only intend this as a kind of sample, based on what to consider in such cases. So it installs the latest config version with me, and Ok.

Configuration conflict: mariadb.conf

Here is the MariaDB you had a problem with your configuration:

Configuration conflict: mariadb.conf

Configuration file '/etc/mysql/mariadb.conf.d/50-server.cnf'
 ==> Modified (by you or by a script) since installation.
 ==> A csomag terjesztője frissített.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 Az alapművelet a jelenlegi változatod megtartása.
*** 50-server.cnf (Y/I/N/O/D/Z) [alapművelet=N:nem] ?

Here I look into the differences with the "D" option:

Here again, you want to restore the default settings in the same way as when upgrading an older distribution.

Returning to the menu, I keep my own settings here too, so "N"

Configuration conflict: /etc/roundcube/apache.conf

At the next Roundcube There is a conflict in the Webmail Apache configuration:

Configuration conflict: /etc/roundcube/apache.conf

Configuration file '/etc/roundcube/apache.conf'
 ==> Modified (by you or by a script) since installation.
 ==> A csomag terjesztője frissített.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 Az alapművelet a jelenlegi változatod megtartása.
*** apache.conf (Y/I/N/O/D/Z) [alapművelet=N:nem] ?

This is at the time it was set here. Let's look at the differences (D):

Configuration conflict: /etc/roundcube/apache.conf - Differences

Here, in essence, you want to extract our own Alias ​​at the top, and below, you want to restore the vast majority of lines that are only tabulated further in, so it is perceived as a difference. So, in this example, I'm keeping my own version. Backspace with Q, then "N".

 

 

Package configuration: roundcube-core

And here there is something to set in connection with the Roundcube database.

Package configuration: roundcube-core

┌───────────────────────────────────────────────────────────────┤ roundcube-core konfigurálása ├────────────────────────────────────────────────────────────────┐
│                                                                                                                                                               │
│ According to the maintainer for this package, database upgrade operations need to be performed on roundcube. Typically, this is due to changes in how a new   │
│ upstream version of the package needs to store its data.                                                                                                      │
│                                                                                                                                                               │
│ If you want to handle this process manually, you should refuse this option. Otherwise, you should choose this option. During the upgrade, a backup of the     │
│ database will be made in /var/cache/dbconfig-common/backups, from which the database can be restored in the case of problems.                                 │
│                                                                                                                                                               │
│ Perform upgrade on database for roundcube with dbconfig-common?                                                                                               │
│                                                                                                                                                               │
│                                                <Igen>                                                  <Nem>                                                  │
│                                                                                                                                                               │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

The exact same thing has already happened in old description is.

Now, knowing the above, I checked the status of MariaDB in another terminal window, and it is working, so presumably there won't be any complications like last year.
Of course, we can check this ourselves in another terminal with the following command:

systemctl status mariadb.service
 mariadb.service - MariaDB 10.3.36 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-12-13 01:02:45 CET; 1 months 14 days ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
 Main PID: 1120 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 42 (limit: 4915)
   Memory: 1.8G
   CGroup: /system.slice/mariadb.service
           └─1120 /usr/sbin/mysqld

It works. So, choose yes here, and the following panel will appear:

Package configuration: roundcube-core

┌─────────────────────────────────────────────────────────────┤ roundcube-core konfigurálása ├─────────────────────────────────────────────────────────────┐
│ config.inc.php: A new version (/etc/roundcube/config.inc.php.ucftmp) of configuration file /etc/roundcube/config.inc.php is available, but the version   │
│ installed currently has been locally modified.                                                                                                           │
│                                                                                                                                                          │
│ What do you want to do about modified configuration file config.inc.php?                                                                                 │
│                                                                                                                                                          │
│                                                   install the package maintainer's version                                                               │
│                                                   keep the local version currently installed                                                             │
│                                                   show the differences between the versions                                                              │
│                                                   show a side-by-side difference between the versions                                                    │
│                                                   start a new shell to examine the situation                                                             │
│                                                                                                                                                          │
│                                                                                                                                                          │
│                                                                          <Ok>                                                                            │
│                                                                                                                                                          │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Here, the error that occurred at the time of the old update no longer appears, but it goes straight to the configuration part. Let's see the difference: "show the differences between the versions":

Package configuration: roundcube-core

There are completely insignificant differences here. Or the default_host would like to extract our setting, which is fine if it is set to localhost. So here we go back and keep our own config copy: "keep the local version currently installed".

 

Even after a little configuration, the complete update was completed, and there were no errors.

Full distribution update completed

 

Restart server

If we have reached this point, restart the server:

reboot

 

The distribution update is not over yet, a next page we will review the server and make the subsequent settings.

 

 

 

Navigation

This description consists of several pages: