DietPi Blog

... discover DietPi, Debian and Linux info

DietPi – How to upgrade to “Bullseye”

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

Table of contents

  1. Why upgrading?
  2. How to upgrade
  3. Known incompatibilities
  4. Feedback
  5. Conclusion

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 11 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 stopped at August 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
9StretcholdoldstableJune 20172020-07
10BusteroldstableJuly 20192022-08
11BullseyestableAugust 20212024-08
Debian release schedule (details see DebianReleases, LTS)

2. How to upgrade

There are two ways to get 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 (not 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:

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,openhab}
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:

[[ -f '/etc/apt/sources.list.d/dietpi-mono.list' ]] && sed -i 's/bullseye/buster/' /etc/apt/sources.list.d/dietpi-mono.list
[[ -f '/etc/apt/sources.list.d/sonarr.list' ]] && sed -i 's/bullseye/buster/' /etc/apt/sources.list.d/sonarr.list

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:

[[ -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/.hw_model

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:
  • 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
G_AGP libgcc-8-dev '*php7.3*'
rm -Rf /etc/php/7.3 /usr/local/lib/python3.7 /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:


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="11 (bullseye)"

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:

  • Firefox Sync Server (due to being Python 2 only)
    EDIT: It looks like a ready-to-use installer for this based on Python 3 and/or Rust is not added any time soon or at all, hence we removed the FF Sync Server from our software options.
  • Telephone system 3cx (see here)
    EDIT: In the meantime, support for 3cx on RPi has been dropped completely:

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.

Update (2024-01-21)

In the meantime, Debian 12 Bookworm has been released. If you are on it, you may want to move on to Bookworm directly. This time we prepared a script to do so, so that you do not need to copy&paste commands manually:

DietPi – How to upgrade to “Bullseye”

90 thoughts on “DietPi – How to upgrade to “Bullseye”

  1. Stephan,

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

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

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

  4. 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”

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

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

  6. Upgrade went mostly without a hitch, I only had small issues with redis-server (needed to remove the dump.rdb/ 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=”11 (bullseye)”

    1. 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.

      1. 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 🙂

  7. 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.

  8. 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 ‘ buster InRelease’ doesn’t support architecture ‘arm64’

      1. Sorry for taking so long, but after trying again, it seems the update did work in the end,

  9. 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?

    1. 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.

      1. 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.

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

          1. 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 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 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 ist noch nicht gültig (ungültig für weitere 57 min 9 s). Aktualisierungen für dieses Depot werden nicht angewendet.

            1. 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”.

  10. 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 bullseye InRelease
    Hit:2 bullseye InRelease
    Hit:3 public InRelease
    Ign:4 sarge InRelease
    Hit:5 buster InRelease
    Hit:6 bullseye InRelease
    Hit:7 sarge Release
    Hit:9 raspbianbuster InRelease
    Hit:8 focal InRelease
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    All packages are up to date.

    1. 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.

      1. cat /etc/os-release
        PRETTY_NAME=”Raspbian GNU/Linux 10 (buster)”
        NAME=”Raspbian GNU/Linux”
        VERSION=”10 (buster)”

        1. 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?

  11. 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^

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

    1. 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.

  13. 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.

    1. 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.

  14. 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!

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


  16. 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 !

    1. 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?

  17. 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?

    1. 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.

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

  19. 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

  20. 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.

    1. 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.

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

  22. 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.

    1. 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.

      1. 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 ) …. 👍🏻

  23. 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 .

    1. the magic spell to get lighttpd going is :

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

      1. 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.

        1. 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 ?

        2. 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

          1. 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 …..

            1. 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 🙂

              1. magic spell fixes that problem :

                “apt install php-fpm”

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

                1. 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.

  24. 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.

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

  25. 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=”11 (bullseye)”

    1. 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.

  26. 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…

  27. I assume Mono and Sonarr now have bullseye packages? I recently updated stretch –> buster and was going to update to bullseye but not if there will be Mono or Sonarr issues. Thanks!

    1. Those do still not have explicit Bullseye packages, but you can safely use the Buster ones. No one ever reported issues with the Buster packages on Bullseye, which is likely also why Mono as well as Sonarr found no reason after over 1 year of Bullseye release to maintain actual packages for it.

  28. I’ve just upgraded, and everything went fine but I ended with a pi-hole not working due to lighttpd.
    no big issue, I reinstalled both pi-hole and with it lighttpd and everything was working

    the documentation is very well done!

  29. late to the party; well written out guide, ty. I had issues with docker compose dependencies, python, rust, bcrypt, cargo and other wheels. (probably due to local crap) this helped out: ie make sure the pip install is renewed and make sure alldependencies are installed (manually) From there I got from stretch to bullseye.

    One thing I noticed was Dietpi stayed on v7.9.4 (stretch). I found that this was due to being on a seperate branch and needs to get re-pointed to main.
    G_CONFIG_INJECT ‘DEV_GITBRANCH=’ ‘DEV_GITBRANCH=master’ /boot/dietpi.txt

    hope that might help someone else.
    (now I have to figure out how to enlarge my years old – too small boot partition…)

  30. With 2.2 Manual upgrade, Buster to Bullseye.

    FYI received error message of “The following packages have been kept back: gcc-8-base ” on :
    apt upgrade

    Resolved by installing this by itself.
    apt install gcc-8-base

    DietPi seems fine on Bullseye.

    1. This package is actually shipped only on Buster and not required anymore on Bullseye. It does not hurt to leave it, but you can also remove it:

      apt purge gcc-8-base

      Strange that you were able to (re)install it and that an update was found (as it was kept back). Was this still before the actual upgrade? If it was afterwards, what is the output of:

      apt policy gcc-8-base

      Probably there is still an unintended Buster repo present.

      1. I did the purge since it is not required. Thanks.

        BTW, when using dietpi-update, it shows Latest version : v7.9.4; while the web site shows that as of July 2023 (version 8.19) is the latest version. Is there some trick to get dietpi to the latest version?

        1. I think we do not do the migration back to master branch automatically. Something I wanted to do. Please do this to upgrade to latest DietPi:

          G_DEV_BRANCH master
  31. Upgraded 2 raspberry pi:s from buster to bullseye. The RPi Zero W was updated without issue some months ago. Today I upgraded a RPi 4 Model B and /etc/debian_version wasn’t updated which resulted in $G_DISTRO_NAME not being updated when running dietpi-obtain_hw_model. The correct info was in /etc/os-release and all other places I checked.

    I checked the checksum of the file as described here:

    It checked out on the RPi Zero and showed that it should’ve been the same on the RPi 4, so I ended up manually changing the version number on the RPi4 to 11.7 (to get the expected checksum = same as the RPi Zero). Then I re-ran the dietpi-obtain_hw_model script and now everything looks good.

    It took some digging to find this, so I’m leaving it here for posterity.

    1. Both files `/etc/debian_version` and `/etc/os-release` are shipped by the same package `base-files`. So a mismatch between the info on both indicates a problem. I am currently not sure whether they are declared are config files, so that manual changes prevent them from being updated. Is there a `/etc/debian_version.dpkg-dist`? If so, replace the other one with it to have an unmodified file in place again and prevent the same issue when updating to Bookworm.

      1. Yes, /etc/debian_version.dpkg-dist says “11.7”, so it’s identical to /etc/debian_version after my change. Thanks for the hint. I’ll keep an eye on it.

  32. I have a Raspberry Pi 4 which I had not updated because it was running a TVheadend server which I had manually added, and I was not sure what would happen when I updated to Bullseye.
    I am happy to say that all went well and the TVheadend server is now running on Bullseye.

  33. Thanks for the insightful guide on upgrading to “Bullseye”! I found it super helpful.

  34. Would it not be easier to “sudo su” for the people who need sudo?
    Then they dont have to type sudo every time.
    Its likely the people copying and pasting dont know why the command
    [[ -f ‘/etc/apt/sources.list.d/raspi.list’ ]] && sed -i ‘s/ ui$//’ /etc/apt/sources.list.d/raspi.list
    has failed. You cant type sudo in front of the test.

  35. i spent 2 full weeks trying time after time to try and get this to work…Only to have it resort back to the previous version that i had before i started to upgrade…nothing i have done and no websites has help me yet…Including this one…i can not get a straight answer from any one and every one seems to keep pointing out other problems that they seem to think i have only to find out that the problem that they are talking about is not there…
    is there someone on this website that can help me so i can stop wasting 2 weeks of my time…

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top