DietPi – How to upgrade to “Bullseye”

D

Debian 11 (aka Debian Bullseye) has been released on August 14, 2021:

While DietPi started to ship new Bullseye-based images, this description gives the how to upgrade a system to Debian Bullseye and why you should do it.

Debian 11 logo
Debian 11 (Bullseye) logo

1. Why upgrading?

Debian’s stability is based on the fact that stable releases do not receive software package upgrades, aside of hand selected security patches and bug fixes. The downside is that package versions of a stable release are up to two years old. To benefit from newest features, design and standards, switching to the new Debian release is hence recommended. With Debian Bullseye, more than 70% of all software packages were updated to a new version. Some notable software version bumps between Debian 10 Buster and Debian Bullseye are:

The updated FOSS Mesa drivers are interesting for many single-board computer users, which use a desktop or other GUI, gaming or video software, as OpenGL ES and further general GPU acceleration for many popular SoC GPUs has been added or enhanced, like for Rockchip RK3399, RK3328, Allwinner H5 and others.

Native PC (x86_64) and virtual machine systems will benefit from an upgraded Linux kernel. Debian Buster shipped Linux 4.19, Debian Bullseye ships Linux 5.10, which includes native WireGuard, native exFAT support and many other filesystem and performance enhancements as well as new encryption and security standards.

Another interesting point is the option of driverless printing/scanning via the standardized IPP-over-USB protocol (printing) resp. SANE printing backend (scanning). Driverless means that you can get rid of non open source vendor specific printer/scanner driver which often were needed to be installed. In addition, the kernel support contains the option to use such a device over the network (e.g. see there).

Under the hood, the security of the password handling was improved (password hashing via yescrypt). This brings a better security resp. robustness against wordlist based attacks.

Due to the Debian roadmap regular Buster support will be stopped at 2022, Bullseye support is planned to be kept alive until 2024, with a limited support by the Debian LTS team until 2026.
Therefore it is reasonable to switchover to Bullseye within the next months to be up-to-date to ensure best software support.

VersionNameStatusRelease dateSupport end date
(LTS)
9StretcholdoldstableJune 20172020
(2022-06)
10BusteroldstableJuly 20192022
(2024)
11BullseyestableAugust 20212024
(2026)
Roadmap of Debian (LTS: Long term support, i.e. security patches and updates)

2. How to upgrade

There are two options to come to a Bullseye based DietPi system:

  1. Starting a fresh install using our new Bullseye images
  2. Manual upgrade of a running DietPi system

Generally we recommend to start with a fresh image, note down and migrate only individual data, configuration and setup steps, to prevent obsolete or incompatible left overs from the old system. But in some cases, if too much customisation has been done without having it well documented or scripted, an upgrade of the running system may be easier. Just note that such an upgrade can always fail at some point, in the worst case (none reported yet!) making your system unusable.

2.1 Fresh install with DietPi Bullseye images

In the meantime, all DietPi images from our download page have been migrated to Bullseye. As always, follow our install instructions for getting them up and running.

We highly recommend to keep the old system SD card/drive for a while and flash Bullseye to a new one. So in case something does not work as expected on the new system, you can revert, and to be able to copy over potentially missing data or configurations any time later. If you have installed MariaDB, do an additional database dump, which can be imported on the new system, if the automatic migration of the raw table files in /mnt/dietpi_userdata/mysql fails for some reason:

mysqldump --all-databases > mariadb.sql
# To import on the new system after installing MariaDB and if automatic database migration fails:
mariadb < mariadb.sql

A common way to migrate configuration and data from the old DietPi image is to copy over the content of /mnt/dietpi_userdata and /var/www as a whole before doing any software install, and in case selected files or directories from within /var/lib after software installs. Apply individual configuration changes where necessary from config files in /etc, /root or /home.

2.2 Manual upgrade

First of all, assure that you are currently running Debian Buster, e.g. by running
echo $G_DISTRO_NAME, which should return buster. If you are running Debian Stretch, please use the following instructions in your documentation, to upgrade to Buster first: https://dietpi.com/docs/usage/#how-to-upgrade-to-buster

The manual upgrade needs the following steps:

  1. Backup the system
  2. Change the package sources (APT sources) to Bullseye
  3. Upgrade the system
  4. Software migrations
  5. Reboot to load all parts of Bullseye

In the following, commands for update actions are given. Depending whether you operate as root or not, you possibly have to add a sudo in advance.

2.2.1 Backup the system

Please always do a full system backup before touching a running Linux system in such an intrusive way. On DietPi you may simply use:

dietpi-backup 1

NB: When restoring the backup, to downgrade from Bullseye back to Buster, we got reports about an issue when calling curl with a shared library error. The reason for this is still unknown, but the solution is to reinstall the faulty library:

apt update
apt -y install --reinstall librtmp1

2.2.2 Change the package sources

The package sources are defined in /etc/apt/sources.list resp. *.list files within the directory /etc/apt/sources.list.d. The following commands will update all of them to pull the Debian Bullseye package lists from now on, and additionally will remove some now obsolete lists and preferences, dietpi-software installs on older Debian versions:

sed -i 's/buster/bullseye/g' /etc/apt/sources.list{,.d/*.list}
sed -i 's|bullseye/updates|bullseye-security|' /etc/apt/sources.list
[[ -f '/etc/apt/sources.list.d/raspi.list' ]] && sed -i 's/ ui$//' /etc/apt/sources.list.d/raspi.list
rm -f /etc/apt/sources.list.d/dietpi-{php,wireguard}.list
rm -f /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm -f /etc/apt/preferences.d/dietpi-{php,openssl,xrdp,wireguard,kodi}
rm -f /etc/apt/sources.list.d/pivpn-bullseye.list
rm -f /etc/apt/sources.list.d/pivpn-bullseye-repo.list
rm -f /etc/apt/preferences.d/pivpn-limit-bullseye

2.2.3 Upgrade the system

As a next step, you need to pull the new APT package lists using the command:

apt update

This should give you a message that more than 250 software packages can be upgraded.

Depending on 3rd party software you installed, some package repositories may not provide dedicated packages for Bullseye yet, in which case the above command throws related errors. However, the Buster packages work fine on Bullseye, so you can edit the related file in /etc/apt/sources.list.d, revert the code name back from “bullseye” to “buster” and repeat the command above. As time of writing, the following repositories are known to not provide Bullseye packages yet:

There may be some config changes required to prevent upgrade errors in the first place. The below code can be copy&pasted into the console to apply some known required changes when related config files are present:

# ProFTPD
[[ -f '/etc/proftpd/proftpd.conf' ]] && ! grep -q 'IfModule mod_ident.c' /etc/proftpd/proftpd.conf && sed -i '/IdentLookups/c\<IfModule mod_ident.c>\nIdentLookups off\n</IfModule>' /etc/proftpd/proftpd.conf

# Legacy network interface names
# - RPi
(( $G_HW_MODEL < 10 )) && ! grep -q 'net.ifnames=0' /boot/cmdline.txt && sed -i '/root=/s/$/ net.ifnames=0/' /boot/cmdline.txt
# - Odroid XU4
(( $G_HW_MODEL == 11 )) && ! grep -q 'net.ifnames=0' /boot/boot.ini && sed -i '/bootrootfs/s/"$/ net.ifnames=0"/' /boot/boot.ini
# - Armbian
[[ -f '/etc/armbianEnv.txt' ]] && ! grep -q 'net.ifnames=0' /etc/armbianEnv.txt && G_CONFIG_INJECT 'extraargs=' 'extraargs="net.ifnames=0"' /boot/armbianEnv.txt

With updated package lists, the actual software package upgrades are done via below commands. Please assure that no errors happen and do not reboot before all upgrades have finished successfully. If you face any errors and are unsure how to resolve, please contact us via our community forum or GitHub issue to find help.

dietpi-services stop
apt upgrade

Wait for the apt upgrade to be finished, possibly you need to answer some questions (mostly the default answers are fine).

apt full-upgrade

Then finish the process with

/boot/dietpi/func/dietpi-obtain_hw_model
. /boot/dietpi/func/dietpi-globals

2.2.4 Software migrations

Depending on installed software titles, as a distribution upgrade includes breaking changes, some configurations may need to be updated. When installed via dietpi-software, a reinstall is often the easiest way to have those applied automatically:

  • As the PHP base version has been upgraded from 7.3 to 7.4, old packages need to be purged, webservers re-configured and in case option PHP modules installed. If you did any manual PHP configuration changes, remember or backup them from /etc/php/7.3. We highly recommend to not backup whole config files, but note down the individual changes/additions you did, as the other content of old configs may be incompatible or deprecated with PHP 7.4.
  • If you use Pi-hole, you should prevent lsof from being auto-removed:
    apt-mark manual lsof
  • If you use qBittorrent, see a solution for web UI login issues here: https://github.com/MichaIng/DietPi/issues/4862
  • Since Python 3 is upgraded from version 3.7 to 3.9, it needs to be reinstalled and modules installed via pip can be removed as cleanup step (both included with the commands below). Note that this means that you need to reinstall modules you installed manually via pip.
  • The following commands will purge PHP 7.3, install required but potentially auto-removed packages and reinstall all currently installed dietpi-software options (including PHP 7.4, if PHP was installed before), which are known to require configuration changes, done as part of the reinstall. So these steps should be always performed on a DietPi system, upgraded to Bullseye:
dietpi-services stop
command -v a2dismod > /dev/null && a2dismod php7.3
G_AGP '*php7.3*'
rm -Rf /etc/php/7.3 /usr/local/lib/{python3.7,python3.9/dist-packages/setuptools} /usr/local/bin/pip3* /etc/chromium-browser
apt -y install fdisk systemd-timesyncd
[[ -f '/etc/tigervnc/vncserver-config-defaults' ]] && G_CONFIG_INJECT '\$localhost[[:blank:]]*=' '$localhost = "no";' /etc/tigervnc/vncserver-config-defaults
[[ -f '/etc/X11/xrdp/xorg.conf.dpkg-dist' ]] && mv /etc/X11/xrdp/xorg.conf{.dpkg-dist,} && GGI_PRESERVE=1 G_CONFIG_INJECT 'Option[[:blank:]]+"DefaultServerLayout"' '    Option "DefaultServerLayout" "X11 Server"' /etc/X11/xrdp/xorg.conf 'Section[[:blank:]]+"ServerFlags"'
[[ -f '/etc/systemd/system/deluge-web.service' ]] && sed -i '/^ExecStart=/s/deluge-web$/deluge-web -d/' /etc/systemd/system/deluge-web.service
dietpi-software reinstall 31 38 40 47 48 56 83 84 85 88 89 93 114 118 130 134 143 155

2.2.5 Reboot to Bullseye

Reboot your system with:

reboot

When the system has rebooted, you may check your version with:

cat /etc/os-release

If Bullseye is running, it typically gives (on Raspberry Pi ARMv6 images with “Raspbian” instead of “Debian”):

# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Finally, you can purge unused packages with:

apt autopurge

Now you’re finished with your successful Bullseye update. Congratulations!

3. Known incompatibilities

There are a couple of known incompatibilities. We list them below and try to keep this list up to date so that you can re-check your software later on.

If you want to use these software packages, you should wait with the transition to Bullseye until the software packages are made compatible:

  • MotionEye (due to being Python 2 only)
  • CouchPotato (due to being Python 2 only)
  • Firefox Sync Server (due to being Python 2 only)
  • Airsonic (as it does not support Java 17)
  • Telephone system 3cx (see here)

4. Feedback

If you faced error messages or a failure during the described upgrade process, please open an issue on GitHub DietPi issues or a topic in our DietPi forum.
If had any issues to understand or follow this guide, or missing some details, please let us know via a comment below.”

5. Conclusion

In short words: Upgrading your system to Bullseye gets you fit for the DietPi future.

About the author

Avatar of StephanStS
StephanStS

DietPi image creator and documentation contributor.

72 comments

  • Stephan,

    This is a great post – so clear and easy to follow ! I will upgrade soon my Raspberry PIs.

  • Great tut. I have a problem, can’t access Pi-hole web page, using nginx. Any help is welcome 🙂

  • Thank you StephanStS, all done and all working. Though I’ve only got Pi-hole (with DHCP server), openVPN, RPI Monitor.

  • Upgraded my dietpi-Pihole with no issue!! Thanks!
    Just a minor observation: at the end of step 2.2.4 I reinstalled only the software I have. i.e.
    get the nubers with a quick “dietpi-software list | grep =2”
    and use the output to build your list for “dietpi-software reinstall”
    Ciao
    A

    • There is no issue to try to reinstall all software title. If not being installed, they simple will be skipped.

  • Simple and easy to follow instructions. I encountered no issues upgrading and reinstalling PiHole

  • Upgrade went mostly without a hitch, I only had small issues with redis-server (needed to remove the dump.rdb/redis.pid before the service would run) and lightttpd (needing to reinstall mod-deflate and mod-openssl before it would run). Apart from that, pihole works fine, motioneye does not (of course, pity though as my camera just started working again on the kernel recently lol). Nothing else seems out of order, though my setup is quite minimal. Running lxde, kodi, pihole/unbound, vaultwarden, nextcloud, tor hotspot, vscodium. If anything pops up I’ll post on git /issues/. Using my rpi4B 8GB.

    PRETTY_NAME=”Debian GNU/Linux 11 (bullseye)”
    NAME=”Debian GNU/Linux”
    VERSION_ID=”11″
    VERSION=”11 (bullseye)”
    VERSION_CODENAME=bullseye
    ID=debian
    HOME_URL=”https://www.debian.org/”
    SUPPORT_URL=”https://www.debian.org/support”
    BUG_REPORT_URL=”https://bugs.debian.org/”

    • Many thanks for your feedback. Interesting issue with Redis, I’ll try to replicate, and in case add a prober step to the commands in this article. The Lighttpd and Pi-hole dietpi-software reinstall, being part of the commands, should handle the module install(s). But if you installed Pi-hole via the official installer, then indeed this needs to be done manually instead. With next Pi-hole release, deflate won’t be required anymore.

      • I think the redis issue was most probably something on my end so I don’t think anyone will run into it.
        Many thanks for your work!
        ps – good to know deflate won’t be needed next time 🙂

  • Thanks. Just checked this out with one of my older Raspberry system, and I’m glad to report it is working. Took some time though.

    one down, three more to go.

  • How do I fix this?

    275 packages can be upgraded. Run ‘apt list –upgradable’ to see them.
    N: Skipping acquire of configured file ‘main/binary-arm64/Packages’ as repository ‘http://repository.picockpit.com/raspbian buster InRelease’ doesn’t support architecture ‘arm64’

  • Upgraded my Dietpi to Bullseye. Use the same memory for my movie collection. This will of course also be deleted. Is there a way to keep the movie folder?

    • All your personal data and also changed configuration files will all be preserved when you do the manual upgrade. Its only the APT packages (the OS and software commands, libraries etc) which are upgraded in place without touching any other files.

      • Thank you for your reply. I decided to do a reinstallation. Now I have the problem that my Fritzbox does not show any Ip? With Lanscan I have already tried it unfortunately unsuccessfully. Do you have any idea what this can be?

        Rasperri 4
        I installed the software with Balena.
        Armv6, Armv7, Armv8 already tried.
        Fritzbox 7590 with mesh.

        • are you able to connect a screen/keyboard to the RPi4? This would allow to do some more investigation.

          • The lan cable was damaged… Unfortunately I have another problem and hope you can help with it. When entering the command (apt update) I get this error message:

            E: Release-Datei für https://deb.debian.org/debian/dists/bullseye-updates/InRelease ist noch nicht gültig (ungültig für weitere 57 min 10 s). Aktualisierungen für dieses Depot werden nicht angewendet.
            E: Release-Datei für https://deb.debian.org/debian-security/dists/bullseye-security/InRelease ist noch nicht gültig (ungültig für weitere 1 h 5 min 50 s). Aktualisierungen für dieses Depot werden nicht angewendet.
            E: Release-Datei für https://deb.debian.org/debian/dists/bullseye-backports/InRelease ist noch nicht gültig (ungültig für weitere 57 min 9 s). Aktualisierungen für dieses Depot werden nicht angewendet.

            • Hello Carlit0s,
              can it be that you did not boot with a functioning internet connection, so that the system time of the DietPi system is not yet synchronized? Then it could be that the https certificate is not valid.
              You can get rid of this either by booting with a “good” internet connection or by setting the system time via “/boot/dietpi/func/run_ntpd 1”.
              You could monitor the correct time sync at boot time if you watch your boot messages output of your system (on the system console, e.g. if you have a monitor connected to your DietPi system): At boot time the system tries up to 60 seconds to update your system time. Another option to investigate this, is to use “journalctl -u systemd-timesyncd”.

  • I am on step 2.2.3. When I click on apt update, non of the packages are due for an upgrade. Am I doing something wrong? I tried restarting the system twice.

    apt update
    Hit:1 https://download.docker.com/linux/raspbian bullseye InRelease
    Hit:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
    Hit:3 https://downloads.plex.tv/repo/deb public InRelease
    Ign:4 https://download.webmin.com/download/repository sarge InRelease
    Hit:5 https://apt.sonarr.tv/debian buster InRelease
    Hit:6 https://archive.raspberrypi.org/debian bullseye InRelease
    Hit:7 https://download.webmin.com/download/repository sarge Release
    Hit:9 https://download.mono-project.com/repo/debian raspbianbuster InRelease
    Hit:8 https://packagecloud.io/golift/pkgs/ubuntu focal InRelease
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    All packages are up to date.

    • Then your system seem to be on Bullseye already. Check via cat /etc/os-release to be sure. If not, please open an issue at GitHub or on our forum, where we’ll be able to investigate and resolve the issue.

      • cat /etc/os-release
        PRETTY_NAME=”Raspbian GNU/Linux 10 (buster)”
        NAME=”Raspbian GNU/Linux”
        VERSION_ID=”10″
        VERSION=”10 (buster)”
        VERSION_CODENAME=buster
        ID=raspbian
        ID_LIKE=debian
        HOME_URL=”http://www.raspbian.org/”
        SUPPORT_URL=”http://www.raspbian.org/RaspbianForums”
        BUG_REPORT_URL=”http://www.raspbian.org/RaspbianBugs”

        • Did you do also the rest of the commands given in 2.2.3 (e.g. apt upgrade,…) up to 2.2.5 with the final reboot?

  • Thank you for the guide !

    The update was smooth and nothing seems broken. It took me 15 minutes or so.
    But I must add I’m running my server apps on docker containers so there was little chance of breaking things.

    Have a nice day ^w^

  • Used this guide and worked perfectly.
    But I have another machine and this question arises: Any similar tutorial for non-dietpi Debian?

    • You should be able to follow the same guide on regular Debian systems. Of course some commands won’t have any effect (the ones which remove files added by dietpi-software) and some will fail (the ones which call DietPi tools), but the major steps and also most precautions/hints apply to all Debian based distros the same way.

  • Yeah…the upgrade path completely blew mine to pieces. Nothing left but a few fragments that I left on my shelf as a symbol of my defeat. But seriously, lighttpd broke when attempting the upgrade. Fortunately I snapshoted the VM so I was able to roll it back. Looks like I’ll just need to do the fresh image download instead. I am trying to remember how I enabled SSL on my setup for the web control panel.

    • Why don’t you try to find out why Lighttpd fails? There are two known required config changes for Lighttpd, which is why a reinstall of it is part of the guide, when installed via dietpi-software. Please open an issue at GitHub with outputs of:
      journalctl -u lighttpd
      cat /var/log/lighttpd/error.log

      With this we should be able to fix it.

  • Should also include the digits for AdguardHome and Unbound in the dietpi-software reinstall line, they are 126 and 182 respectively. Adguard will need its service stopped with systemctl stop adguardhome as well beforehand.
    This was the only problem I ran into while upgrading following your tutorial.

    Thank you for sharing!

  • In my case Nextcloud is no longer working after the upgrade. Any suggestion where can I start checking why it is no longer running?

    Thanks!

  • Hi, I am a system administrator, and I just want to say thank you.
    The update was done flawlessly, I only had one problem with one of my configurations in NGINX.
    Great job !

    • Many thanks for your feedback. Was the Nginx config issue one that we could fix our end, respectively add a fix here to the article, or was it a custom config?

  • I am finding this very frustrating. After “apt upgrade”, it asks me if I want to continue (Y/n) and it ALWAYS aborts despite me entering “Y”.

    Any ideas?

    • Ah yes, we chose to use the interactive commands here so that you have more control and better review of what is upgraded and in case can abort if something unexpected would happen. But this means that you cannot copy&paste everything into the command line as instead of “y”, the input would then be the next command you paste already, so it aborts.

      I’ll add a note into the command block.

  • OK, git it to work by typing each line in separately (not copy paste the group) per your copy button.

  • I am pleased to say this worked for four RPi4 servers I have running. One is a WordPress install, the only issue was the modded apache conf file needed replacing. Next were two NextCloud servers and one needed the SSL reapplied. The last was a Joomla server which went no issues. So all in all, it succeeds with maybe a minor very easy fix.

    It was noted that the servers seem a bit faster. Its good to be on PHP7.4

  • I ran into 2 complications. I had atop installed before the upgrade and that cause an issue during apt full-upgrade. Just remove it:
    apt-get remove –purge atop
    then finish up apt full-upgrade
    then reinstall
    apt-get install atop

    The second issue is it killed docker-compose. I had to remove it and reinstall it using dietpi-software.

    After that everything seems to be running ok.

    • Many thanks for your feedback. atop was installed regularly via apt before? It doesn’t have any conflicting dependency changes between Buster and Bullseye, so not sure why it doesn’t upgrade seamlessly. Good point about Docker Compose. It makes sense as it was installed as Python 3.7 module while the upgrade to Bullseye will pull Python 3.9. So we need to add it to the “dietpi-software reinstall” command above.

  • Yes, atop was installed like normal via apt. The error I got was:
    “Sub-process /usr/bin/dpkg returned an error code (1)”

  • The instructions are clear and concise ! And the system comes up nicely … Thank you for creating this page !

    Some small problems relating to Python going from 3.7 to 3.9 – as follows:

    somehow before (on 3.7) I had it setup so “python3” and “python” both worked… on the new system only “python3” was working. So (I really cannot remember how I setup that on the old system( but to fix I just put : `alias python=’python3’` into the `.bashrc` file…

    And then – all my virtualenvs – (built on python 3.7 ) stopped working… I only had a few, so it was just easier to re-create them afresh in the new python3.9 environment.

    • Many thanks for your feedback. I guess the additional redo of the virtual environments is expected as they are Aldi tied to a specific Python version. Not sure if there is a simpler way to somehow upgrade a virtualenv/venv, otherwise at least module lock list can be used to quickly recreate a clone for Python 3.9.

      • Yes that was expected . And even by my method of re-creating them – it literally only took about 15 minutes – very simple. . It was easy to do and allowed me to clean out those environments at the same time ( which was needed ) …. 👍🏻

  • Oh no – I spoke too soon….

    Lighttpd is now broken ( won’t start )

    So now what ??????? How do I fix Lighttpd ??? I need that because it runs my Matomo site.
    ___________
    also I noticed that LXDE is not running – but I rarely use that, so it not really any impact to me .

    • the magic spell to get lighttpd going is :

      apt install lighttpd-mod-deflate
      lighty-enable-mod deflate

      • Ah you found it already, exactly. This is why we have Lighttpd among the software titles to reinstall. dietpi-software then replaces the deprecated directives and installs the deflate module. But if you installed it manually, this is exactly how you solve it.

        Btw, I removed your long console paste above, as this comment section is really not suitable for code/log pastes. For the future: Please open an issue on GitHub (or our forum) for further investigation as noted in the article, we may then leave a link here for others who face the same.

        • Well.. thank you .. I noticed that you are the author of the post that I got those 2 commands from …

          BUT — now lighttpd starts and status is good –
          ——————

          [Tue Nov 30] root@batopi: ~$ systemctl status lighttpd.service
          ● lighttpd.service – Lighttpd Daemon
          Loaded: loaded (/lib/systemd/system/lighttpd.service; disabled; vendor preset: enabled)
          Active: active (running) since Tue 2021-11-30 08:21:33 EST; 23min ago
          Process: 2509 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
          Main PID: 2520 (lighttpd)
          Tasks: 1 (limit: 2206)
          Memory: 1.2M
          CPU: 823ms
          CGroup: /system.slice/lighttpd.service
          └─2520 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

          Nov 30 08:21:32 batopi systemd[1]: Starting Lighttpd Daemon…
          Nov 30 08:21:33 batopi lighttpd[2509]: 2021-11-30 08:21:32: mod_deflate.c.567) DEPRECATED: compress.filetype replaced with deflate.mimetypes
          Nov 30 08:21:33 batopi lighttpd[2509]: 2021-11-30 08:21:32: mod_deflate.c.580) DEPRECATED: compress.cache-dir replaced with deflate.cache-dir
          Nov 30 08:21:33 batopi systemd[1]: Started Lighttpd Daemon.
          ———————————————-

          BUT — the only site I use that for – matomo – is now giving 503 service not available — to webbrowser trying to connect
          ————-

          Do – technically yes Lighttpd is running, but the only thing I use Lighttpd for ( matomo ) is not running.

          This is getting quite frustrating….
          ————
          BTW – all the sites that I serve with CaddyServer all came up immediately , all working perfectly ….. and Caddy is not officially “diepi software” yet Lighttpd is … Any suggestions ?

        • HOW to reinstall Lighttpd ? I think maybe I need to do that … It is showing a green/working status , but nothing else about it seems to be working

          • Lighttpd is working and owns port 80 – a curl command even confirms it is serving out the “503 service unavailable” error… Maria-db is active and running – and I can access. … so very frustrating … I think somewhere – someone, (lighttpd or Matomo ) are still configured to look for php 7.3 …..

            • Hi MICHAING —

              I think I found the problem with Lighttpd – but I do not know how to fix it …

              Symptom: Lighttpd runs everything except PHP – becasue it still looking for PHP7.3 .

              Lighttpd Error log:
              ——————————
              2021-11-30 23:10:16: gw_backend.c.238) establishing connection failed: socket: unix:/run/php/php7.3-fpm.sock: No such file or directory
              2021-11-30 23:10:16: gw_backend.c.970) all handlers for /index.php? on .php are down.
              —————————

              What is “fpm.sock” ?? Seems light not installed for PHP7.4 ??? And then I assume update to the path in “/etc/lighttpd/conf-available/15-fastcgi-php.conf”
              —–

              Any advice very WELCOME 🙂

              • magic spell fixes that problem :

                “apt install php-fpm”

                also update “path in “/etc/lighttpd/conf-available/15-fastcgi-php.conf”” and restart lighttpd

                • Usually this should have been fixed by running all software reinstallations mention on point 2.2.4

                  BTW: for such investigation, better to contact us on GitHub or our Forum as it is quite hard to read your comments.

  • Well, upgrading failed looking at the result. Using DietPi only for ownCloud-Service and this will not start on bullseye. There’s a problem starting lighttpd. reinstalled ownCloud several times. purged lighttpd and reinstalled. No chance.

    • Ok, made it. Just reinstalled lighttpd with DietPi-software (#82 and #84). Now it works.

  • On my RasPi v1 after upgrade it looks like the following. Is that ok, or should I change to the original Debian repos?
    “`
    root@DietPi:~# cat /etc/os-release
    PRETTY_NAME=”Raspbian GNU/Linux 11 (bullseye)”
    NAME=”Raspbian GNU/Linux”
    VERSION_ID=”11″
    VERSION=”11 (bullseye)”
    VERSION_CODENAME=bullseye
    ID=raspbian
    ID_LIKE=debian
    HOME_URL=”http://www.raspbian.org/”
    SUPPORT_URL=”http://www.raspbian.org/RaspbianForums”
    BUG_REPORT_URL=”http://www.raspbian.org/RaspbianBugs”
    “`

    • That is perfectly right. Original Debian does not support Raspberry Pi 1 and Zero (1). I’ll add a note to the article that on RPi ARMv6 images one will see “Raspbian” instead of “Debian” in this file.

  • Hi, while the Upgrade i get this Error:

    FAILED] DietPi-Software | systemctl restart mariadb
    [ INFO ] DietPi-Software | Executing alternative command: systemctl restart mariadb
    Job for mariadb.service failed because a fatal signal was delivered to the control process.
    See “systemctl status mariadb.service” and “journalctl -xe” for details.
    [FAILED] Alternative command execution | Exited with error
    Press any key to return to error handler menu…

Avatar of Eztam By StephanStS

About Author

Avatar of Eztam

StephanStS

DietPi image creator and documentation contributor.

DietPi Blog

DietPi is an extremely lightweight Debian-based OS, optimised for minimal resource usage, ensuring your SBC runs at its maximum potential!