About 2 years ago, I already posted an article on upgrading Raspbian from Stretch to Buster. Now it’s time to move from Buster to Bullseye. Here’s a quick walk-through:
1. Precautions to be taken against fatal loss of production system
Same procedure as in the previous upgrade:
- Produce a full backup of your stretch production system. Using raspiBackup is recommended.
- If you want to be ultra-sure, produce a clone (with dd) on a second MicroSD card on which you perform the upgrade. If things go sideways, you can still revert to your clone and restart from scratch.
2. Basic upgrade procedure
There are good walk-through instructions on BluesWireless and PiMyLife up. Pick one of those how-tos and follow their instructions (differences between the how-tos are marginal and did not affect the upgrade outcome in my case).
Whenever the upgrade process stops and asks you if to keep existing config files or install new ones, go with the default option (which is keeping existing config files).
3. MariaDB 10.5.15
Now comes the nasty stuff: The first thing that does not work out of the box after the upgrade is MariaDB. And that means that any other service that relies on the database will not run either – which is almost everything why we run our Raspberry Pi: Nextcloud, WordPress, Prosody, and countless other services.
We therefore start installing the most recent MariaDB release:
|
1 |
$ sudo apt install mariadb-server mariadb-client |
After installing the server, and checking the server status, we get the next problem:
|
1 2 3 4 5 6 7 8 9 |
$ sudo service mariadb status [....] /usr/bin/mysql_upgrade: the '--basedir' option is always ignored Looking for 'mysql' as: /usr/bin/mysql Reading datadir from the MariaDB server failed. Got the following error when executing the 'mysql' command line client ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) FATAL ERROR: Upgrade failed |
The problem is discussed on askubuntu.com and on launchpad. Interestingly, the problem dates back a few years without any definitive solution offered.
Furthermore I found a more recent announcement on the MariaDB website, telling us that the authentication procedure has been modified starting with MariaDB 10.4. As my upgrade was from 10.3 to 10.5, I guess the error message above is connected to that new way of handling the authentication directly after installation.
While the purists’ recommendation seems to be to use unix socket authentication, I went for the fast & dirty way and put the root password (twice, both in the [client] and in the [mysql upgrade] section) into /etc/mysql/debian.cnf (So much for DO NOT TOUCH…):
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost user = root password = mysupersecretpassword socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = root password = mysupersecretpassword socket = /var/run/mysqld/mysqld.sock basedir = /usr |
Going forward, I will check if the more elegant solution is to switch to unix socket authentication, but so far I am glad to have a running system at all.
After rebooting with these modifications, the SQL server starts and sudo service mariadb status shows no more errors. There is an annoying and superfluous info message in yellow though, telling me that there is no need to run mysql_upgrade. I will check how to ged rid of this going forward, too:
|
1 2 3 4 5 6 7 8 |
Jun 06 19:02:04 zerow /etc/mysql/debian-start[573]: Upgrading MySQL tables if necessary. Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: Looking for 'mysql' as: /usr/bin/mysql Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: This installation of MariaDB is already upgraded to 10.5.15-MariaDB. Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: There is no need to run mysql_upgrade again for 10.5.15-MariaDB. Jun 06 19:02:05 zerow /etc/mysql/debian-start[577]: You can use --force if you still want to run mysql_upgrade |
4. PHP 7.4
As with our previous upgrade from Stretch to Buster, Bullseye also comes with a new PHP version (7.4 instead of 7.3). We do want to have 7.4 installed because Nextcloud requires 7.4 from release 24 on.
First we have to install additional PHP 7.4 packages:
|
1 |
sudo apt install git certbot unzip nginx curl libcurl4 redis-server php-mysql php7.4-fpm php7.4-curl php7.4-gd php7.4-intl php7.4-mbstring php7.4-opcache php7.4-xml php7.4-xmlrpc php7.4-zip php7.4-apcu php7.4-common php7.4-intl php-pear php7.4-apcu php7.4-xml php7.4-mbstring php7.4-zip php7.4-pgsql php7.4-intl php-imagick php7.4-json php7.4-bz2 php-smbclient redis-server php-redis |
We then have to manually edit /etc/php/7.4/fpm/pool.d/www.conf. We proceed as in the previous Buster upgrade. First we change the listen entry to:
|
1 |
listen=127.0.0.1:9000 |
Then we activate the following environment variables, by removing leading semi-colons:
|
1 2 3 4 5 |
env[HOSTNAME]=$HOSTNAME env[PATH]=/usr/local/bin:/usr/bin:/bin env[TMP]=/tmp env[TMPDIR]=/tmp env[TEMP]=/tmp |
Save and exit, reboot and check if the php7.4-fpm service is running smoothly:
|
1 |
sudo systemctl status php7.4-fpm.service |
In my case, PHP 7.4 was already set up as a deamon service which is automatically launched at the boot time. If you are still stuck with php7.3-fpm, proceed as in the Buster upgrade: stop the 7.3 service, disable it, enable php7.4-fpm and start it.
5. Nextcloud
Reboot and check: WordPress and Prosody should run smoothly and Nextcloud should come up, too. Still we have a couple of warnings which we can get rid of by manually editing /etc/php/7.4/fpm/php.ini:
The PHP memory limit is below the recommended minimum of 512MB. All we have to do is to change memory_limit from the default 128M value to 512M.
Furthermore I got a warning that my opcache interned strings buffer is nearly full. It was recommended to change opcache.interned_strings_buffer to a value larger than 8. I chose 16, and the warning was gone.
I stil get another 2 warnings that I have never found out how to get rid of:
- Your web server is not properly set up to resolve “/.well-known/webfinger”. Further information can be found in the documentation ↗.
- Your web server is not properly set up to resolve “/.well-known/nodeinfo”. Further information can be found in the documentation ↗.