{"id":1550,"date":"2022-06-06T20:51:50","date_gmt":"2022-06-06T18:51:50","guid":{"rendered":"https:\/\/hobbykeller.spdns.de\/?p=1550"},"modified":"2022-06-07T16:31:50","modified_gmt":"2022-06-07T14:31:50","slug":"upgrading-raspbian-from-buster-to-bullseye","status":"publish","type":"post","link":"https:\/\/hobbykeller.spdns.de\/?p=1550","title":{"rendered":"Upgrading Raspbian from Buster to Bullseye"},"content":{"rendered":"\n<p>About 2 years ago, I already posted an article on <a rel=\"noreferrer noopener\" href=\"https:\/\/hobbykeller.spdns.de\/?p=1259\" data-type=\"post\" data-id=\"1259\" target=\"_blank\">upgrading Raspbian from Stretch<\/a> to Buster. Now it&#8217;s time to move from Buster to Bullseye. Here&#8217;s a quick walk-through:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Precautions to be taken against fatal loss of production system<\/h2>\n\n\n\n<p>Same procedure as in the previous upgrade:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Produce a <strong>full backup<\/strong> of your stretch production system. Using <a rel=\"noreferrer noopener\" href=\"http:\/\/hobbykeller.spdns.de\/?p=1213\" target=\"_blank\">raspiBackup<\/a> is recommended.<\/li><li>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.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">2. Basic upgrade procedure<\/h2>\n\n\n\n<p>There are good walk-through instructions on <a rel=\"noreferrer noopener\" href=\"https:\/\/blues.io\/blog\/guide-upgrade-raspberry-pi-buster-bullseye\/\" target=\"_blank\">BluesWireless<\/a> and <a rel=\"noreferrer noopener\" href=\"https:\/\/pimylifeup.com\/upgrade-raspberry-pi-os-bullseye\/\" target=\"_blank\">PiMyLife up<\/a>. 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).<\/p>\n\n\n\n<p>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).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. MariaDB 10.5.15<\/h2>\n\n\n\n<p>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 &#8211; which is almost everything why we run our Raspberry Pi: Nextcloud, WordPress, Prosody, and countless other services.<\/p>\n\n\n\n<p>We therefore start installing the most recent MariaDB release:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ sudo apt install mariadb-server mariadb-client <\/code><\/pre>\n\n\n\n<p>After installing the server, and checking the server status, we get the next problem:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ sudo service mariadb status\n\n&#91;....]\n\/usr\/bin\/mysql_upgrade: the '--basedir' option is always ignored\nLooking for 'mysql' as: \/usr\/bin\/mysql\nReading datadir from the MariaDB server failed. Got the following error when executing the 'mysql' command line client\nERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)\nFATAL ERROR: Upgrade failed\n<\/code><\/pre>\n\n\n\n<p>The problem is discussed on askubuntu.com and on launchpad. Interestingly, the problem dates back a few years without any definitive solution offered.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>While the purists&#8217; recommendation seems to be to use unix socket authentication, I went for the fast &amp; dirty way and put the root password (twice, both in the <code>[client]<\/code> and in the <code>[mysql upgrade]<\/code> section) into <code>\/etc\/mysql\/debian.cnf<\/code> (So much for DO NOT TOUCH&#8230;):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Automatically generated for Debian scripts. DO NOT TOUCH!\n&#91;client]\nhost     = localhost\nuser     = root\npassword = mysupersecretpassword\nsocket   = \/var\/run\/mysqld\/mysqld.sock\n&#91;mysql_upgrade]\nhost     = localhost\nuser     = root\npassword = mysupersecretpassword\nsocket   = \/var\/run\/mysqld\/mysqld.sock\nbasedir  = \/usr<\/code><\/pre>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>After rebooting with these modifications, the SQL server starts and <code>sudo service mariadb status<\/code> 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:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Jun 06 19:02:04 zerow \/etc\/mysql\/debian-start&#91;573]: Upgrading MySQL tables if necessary.\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: \/usr\/bin\/mysql_upgrade: the '--basedir' option is always ignored\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: Looking for 'mysql' as: \/usr\/bin\/mysql\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: Looking for 'mysqlcheck' as: \/usr\/bin\/mysqlcheck\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: This installation of MariaDB is already upgraded to 10.5.15-MariaDB.\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: There is no need to run mysql_upgrade again for 10.5.15-MariaDB.\nJun 06 19:02:05 zerow \/etc\/mysql\/debian-start&#91;577]: You can use --force if you still want to run mysql_upgrade\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">4. PHP 7.4<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>First we have to install additional PHP 7.4 packages:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>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<\/code><\/pre>\n\n\n\n<p>We then have to manually edit <code>\/etc\/php\/7.4\/fpm\/pool.d\/www.conf<\/code>. We proceed as in the previous Buster upgrade. First we change the <code>listen<\/code> entry to:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>listen=127.0.0.1:9000<\/code><\/pre>\n\n\n\n<p>Then we activate the following environment variables, by removing leading semi-colons:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>env&#91;HOSTNAME]=$HOSTNAME\nenv&#91;PATH]=\/usr\/local\/bin:\/usr\/bin:\/bin\nenv&#91;TMP]=\/tmp\nenv&#91;TMPDIR]=\/tmp\nenv&#91;TEMP]=\/tmp<\/code><\/pre>\n\n\n\n<p>Save and exit, reboot and check if the php7.4-fpm service is running smoothly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl status php7.4-fpm.service <\/code><\/pre>\n\n\n\n<p>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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">5. Nextcloud<\/h2>\n\n\n\n<p>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 <code>\/etc\/php\/7.4\/fpm\/php.ini<\/code>:<\/p>\n\n\n\n<p>The PHP memory limit is below the recommended minimum of 512MB. All we have to do is to change <code>memory_limit<\/code> from the default 128M value to 512M.<\/p>\n\n\n\n<p>Furthermore I got a warning that my opcache interned strings buffer is nearly full. It was recommended to change <code>opcache.interned_strings_buffer<\/code> to a value larger than 8. I chose 16, and the warning was gone.<\/p>\n\n\n\n<p>I stil get another 2 warnings that I have never found out how to get rid of:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Your web server is not properly set up to resolve &#8220;\/.well-known\/webfinger&#8221;. Further information can be found in the <a rel=\"noreferrer noopener\" href=\"https:\/\/docs.nextcloud.com\/server\/23\/go.php?to=admin-setup-well-known-URL\" target=\"_blank\">documentation &#x2197;<\/a>.<\/li><li>Your web server is not properly set up to resolve &#8220;\/.well-known\/nodeinfo&#8221;. Further information can be found in the <a rel=\"noreferrer noopener\" href=\"https:\/\/docs.nextcloud.com\/server\/23\/go.php?to=admin-setup-well-known-URL\" target=\"_blank\">documentation &#x2197;<\/a>.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>About 2 years ago, I already posted an article on upgrading Raspbian from Stretch to Buster. Now it&#8217;s time to move from Buster to Bullseye. Here&#8217;s a quick walk-through: 1.<span class=\"more-button\"><a href=\"https:\/\/hobbykeller.spdns.de\/?p=1550\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\">Upgrading Raspbian from Buster to Bullseye<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1550","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/1550","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1550"}],"version-history":[{"count":6,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/1550\/revisions"}],"predecessor-version":[{"id":1557,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/1550\/revisions\/1557"}],"wp:attachment":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1550"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1550"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}