Debian 12 Bookworm is expected to be released this Juli 2023-06-10. We want to give you a brief preview and info how to test it, either using our DietPi Bookworm images, or by upgrading your running DietPi Bullseye system.
- Feature preview
1.1 Release schedule
1.2 Available software updates
1.3 Other notable changes - Current status
2.1 Debian side
2.2 DietPi side - How to test
3.1. DietPi Bookworm images
3.2. Upgrade from Bullseye - Giving feedback
Feature preview
1.1 Release schedule
Debian does not follow the rolling release model, but is a point release distribution, which provides updates for its distributed software via major releases every two years. The following table gives an overview of the last, current and next stable Debian release:
| Version | Code name | Current status | Release date | End-of-life (LTS) |
| 10 | Buster | oldstable | 2019-07 | 2022-09 (2024-06) |
| 11 | Bullseye | stable | 2021-08 | 2024-07 (2026-06) |
| 12 | Bookworm | testing | 2023-06 | 2026-06 (2028-06) |
During these two years, a stable Debian release receives only bug fixes, security patches and in rare cases patch version updates, i.e. updates where the upstream software developer does not declare any breaking changes or new features. You can observe this behaviour by looking at the version strings when doing apt upgrade: Usually only the suffix changes, indicating that the same software source code version was used. Changes were then limited to the package maintainer/meta files, including bug fix and security patches.
There are some exceptions for this strict update policy, like the Chromium browser, which receives regular major version upgrades for security reasons.
This means that at the end of a version release cycle, software provided by the Debian package repository is up to two years old and the next release hence provides some significant updates.
1.2 Available software updates
The following list shows an excerpt of updates available with Debian Bookworm for software often used on DietPi systems:
| Software | Bullseye | Bookworm | Note |
| OpenSSH | 8.4 | 9.2 | adds full Ed25519 support, disables ssh-rsa support by default |
| OpenVPN | 2.5.1 | 2.6.1 | |
| Python | 3.9 | 3.11 | Not all Python applications have been tested by us with Python 3.11 yet. |
| PHP | 7.4 | 8.2 | Not all PHP applications have been tested by us with PHP 8.2 yet. |
| MariaDB | 10.5 | 10.11 | |
| PostgreSQL | 13 | 15 | The required database migration is included with our Bookworm upgrade script. |
| qBittorrent | 4.2.5 | 4.5.2 | |
| Kodi | 19.1 | 20.1 | not relevant for Raspberry Pi |
| MPD | 0.22.6 | 0.23.12 | |
| Netdata | 1.29.3 | 1.37.1 | |
| Mesa graphics drivers | 20.3.5 | 22.3.6 | |
| Linux | 5.10 | 6.1 | relevant for x86_64 platforms only |
Notable are the PHP and Python upgrades to their respective latest official version, which affects a large number of dietpi-software installation options:
- Some applications did already drop support for PHP 7.4 respectively Python 3.9, including Nextcloud and TasmoAdmin, which forces us do install older versions on Bullseye systems.
- Other applications do not support PHP 8.2 respectively Python 3.11 yet and hence fail to run or install on Bookworm. ownCloud is an example, further explained below.
1.3 Other notable changes
There are some other changes we want to highlight:
Already since Linux 4.15, the kernel is able to obtain permitted WiFi channels/frequencies, the so called regulatory domains, from the regulatory database, based on a given WiFi country code. Previously, a dedicated user-space tool was needed to pass this information to the kernel: the Central Regulatory Domain Agent (CRDA). Since Debian Bullseye, the provided packages generally allows the use of this feature, and we hence offer the migration away from CRDA with the DietPi v8.14 upgrade. But on Bookworm, the CRDA package is not available at all. This means that systems, using a Linux version below 4.15, are not able to connect to a WiFi access point or provide one, using all locally allowed frequencies, but only a limited subset of shared global ones, which can break WiFi communication completely. This and a bunch of other uses of recent Linux kernel features force us to not provide Bookworm images for certain SBCs anymore, which have no Linux kernel of 4.15 or higher available.
This includes the Sparky SBC, NanoPi M2/T2/Fire2 and NanoPi M3/T3/Fire3 models. We are especially sad for the latter ones, which use a very powerful octa-core SoC, but the involved manufacturers have not managed to add support to mainline Linux or update their own kernel sources, stuck at Linux 4.4, which practically implies an artificially early end-of-life for such hardware.
Since Linux 5.15, an SMB kernel server ksmbd is available, similar to the NFS kernel server nfsd. This provides an alternative to the Samba user-space server, optimised for better performance and lower footprint running right in kernel-space. Debian Bookworm provides the needed user-space tools to manage this new SMB server implementation, and we are excited to implement it into dietpi-software as well.
2. Current status
2.1 Debian side
Debian Bookworm has not yet been released, but the release has been scheduled for 2023-06-10.
As always, about half a year before the release, Debian starts a set of freeze stages, to incrementally settle the list of provided packages and their versions, first for fundamental libraries, toolchains and frameworks, backend software, over middleware, to frontend and end user software. At time of writing, the so called “hard freeze” has been reached. Details about the freeze stages can be found in the Debian website: https://release.debian.org/bookworm/freeze_policy.html
While during the first 1.5 years of a Debian testing phase, a lot of package upgrades with potentially breaking changes will be offered via APT, for Debian Bookworm in its current freeze stage, no big surprises are expected anymore, e.g. above listed software versions are not expected to change, and the number and frequency of package upgrades has become much lower. While it is still in testing, we can hence already recommend using Debian Bookworm in some production cases, e.g. when a newer PHP version is needed to run recent web applications. We use Debian Bookworm on the dietpi.com server already since a long time, and no manual setup change, config file update or similar intervention was needed recently.
2.2 DietPi side
DietPi offers Debian Bookworm based images since a long time, but we did not provide them prominently on our download page or elsewhere until now. However, general Bookworm support has been implemented shortly after the Bullseye release and since then we are testing our tools and software implementations on Bookworm systems as well, reacting to any breaking change. While quirks in special setups are possible, generally we can declare DietPi to be compatible with Debian Bookworm.
It is not complete or up-to-date in every case, but an overview of explicitly tested software titles can be found on our wiki: https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing
The following list of software titles is known to be not (yet) compatible with Debian Bookworm:
- Logitech Media Server, since it does not support Perl 5.36 yet
- ownCloud, since it does not support PHP 8.x and will probably never do. On Bookworm, one should hence use Nextcloud or the rewritten ownCloud Infinite Scale solution.
Additionally, not all PHP and Python applications have been recently tested for PHP 8.2 and Python 3.11 support. You are invited to help testing the ones you need.
3. How to test
We made it very easy for you to test DietPi on Debian Bookworm, providing images as well as a script to upgrade your Debian Bullseye based DietPi system.
3.1 DietPi Bookworm images
While Bookworm images are not provided on our download page, your can find them for all devices (expect Sparky SBC, NanoPi M2/T2/Fire2 and NanoPi M3/T3/Fire3 as mentioned above) here: https://dietpi.com/downloads/images/
Install them the same way you do with the current stable Bullseye images, e.g. by following our install instructions: https://dietpi.com/docs/install/
3.2 Upgrade from Bullseye
We wrote a script to upgrade a DietPi Bullseye system to Bookworm, as safe as possible. While flashing a fresh image is generally cleaner and recommended, we know that some of you have setups which are time consuming to replicate on a fresh system. Our script offers to create a backup, does all known needed migrations and adjustments to have your software running on the new Debian as it did before. Run the following one-liner on your console to execute it:
sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.meta/dietpi-bookworm-upgrade')"Carefully watch the output of the script. If an error occurs, our error handler allows you to open a subshell to investigate and fix the underlying issue, to repeat and continue. After the packages themselves have been upgraded, it allows you to again review the output, before continuing with software (config) migrations, which also includes some dietpi-software reinstalls.
4. Giving feedback
Feel free to use the comments for short feedback about this article and how Bookworm works for you.
For more detailed test results and issues you face with our upgrade script or Bookworm in general, please use the following issue on our GitHub repository: https://github.com/MichaIng/DietPi/issues/6227
Happy hacking!
There is some glitch with php 8.1 and bookworm (kernel 6.1?). After a few minute my docker instances that use webserver and php (heimdall, smokeping) die. It happens on both my devices (rpi4, odroid-c2).
call trace:
[39513.213225] __switch_to+0xf8/0x1e0
[39513.213262] __schedule+0x2a8/0x830
[39513.213284] schedule+0x60/0x100
[39513.213336] io_schedule+0x24/0x60
[39513.213358] folio_wait_bit+0x11c/0x1e0
[39513.213379] folio_wait_writeback+0x54/0xd8
[39513.213395] wait_on_page_writeback+0x28/0x38
[39513.213412] __filemap_fdatawait_range+0x9c/0x138
[39513.213429] filemap_write_and_wait_range+0x90/0xb8
[39513.213448] nfs_wb_all+0x30/0x180
[39513.213465] nfs4_file_flush+0xa8/0xf8
[39513.213481] filp_close+0x40/0xa0
[39513.213502] put_files_struct+0x12c/0x130
[39513.213522] exit_files+0x48/0x60
[39513.213695] do_exit+0x2f8/0xa90
[39513.213726] do_group_exit+0x3c/0x98
[39513.213746] __wake_up_parent+0x0/0x38
[39513.213767] invoke_syscall+0x4c/0x110
[39513.213789] el0_svc_common.constprop.3+0x98/0x120
[39513.213810] do_el0_svc+0x34/0xd0
[39513.213830] el0_svc+0x30/0x88
[39513.213849] el0t_64_sync_handler+0x98/0xc0
[39513.213869] el0t_64_sync+0x18c/0x190
Bookworm ships PHP 8.2, so this PHP 8.1 is entirely a matter of the Docker image. Do you have options to test with another container image? Else, not sure about smokeping, but Heimdall can be easily installed bare metal.
I’m pretty sure that problem causes php-fpm and kernel 6.1. I downgraded dietpi to bullseye and installed heimdall once again. After a few minutes every docker container that used webserver was unresponsive (heimdall, smokeping). I tried to install previous version of heimdall – 2.5.4 which worked fine with kernel 5.15? (previous for rpi4) with no luck. System was unresponsive after few minutes; I couldn’t kill container with heimdall. In dmsg I got:
[ 605.151218] INFO: task nginx:2586 blocked for more than 241 seconds.
[ 605.151241] Tainted: G C 6.1.21-v8+ #1642
[ 605.151262] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 605.151284] task:nginx state:D stack:0 pid:2586 ppid:2572 flags:0x00000808
[ 605.151308] Call trace:
[ 605.151318] __switch_to+0xf8/0x1e0
[ 605.151340] __schedule+0x2a8/0x830
[ 605.151360] schedule+0x60/0x100
[ 605.151380] io_schedule+0x24/0x60
[ 605.151401] folio_wait_bit+0x11c/0x1e0
[ 605.151420] folio_wait_writeback+0x54/0xd8
[ 605.151434] wait_on_page_writeback+0x28/0x38
[ 605.151450] __filemap_fdatawait_range+0x9c/0x138
[ 605.151468] filemap_write_and_wait_range+0x90/0xb8
[ 605.151486] nfs_wb_all+0x30/0x180
[ 605.151501] nfs4_file_flush+0xa8/0xf8
[ 605.151516] filp_close+0x40/0xa0
[ 605.151534] put_files_struct+0x12c/0x130
[ 605.151554] exit_files+0x48/0x60
[ 605.151571] do_exit+0x2f8/0xa90
[ 605.151591] do_group_exit+0x3c/0x98
[ 605.151611] __wake_up_parent+0x0/0x38
[ 605.151631] invoke_syscall+0x4c/0x110
[ 605.151650] el0_svc_common.constprop.3+0x98/0x120
[ 605.151670] do_el0_svc+0x34/0xd0
[ 605.151690] el0_svc+0x30/0x88
[ 605.151707] el0t_64_sync_handler+0x98/0xc0
[ 605.151725] el0t_64_sync+0x18c/0x190
A hanging I/O task can be also caused by some sorts of system overload, especially when you are running multiple Docker containers with PHP and webservers in each of them, one of the natural issues when running everything as container. A direct causality between Linux 6.1 and PHP 8.1 is highly unlikely, but more likely a general issue with either the new kernel or the new container image which appears (is triggered with higher chance) in this combination. To narrow it down, I’d test the following systematically:
– Test new Heimdall container on Linux 6.1 (done, this is where you face the issue)
– Test old Heimdall container on Linux 5.15 (done, this is where you didn’t face the issue so far?)
– Test old Heimdall container on Linux 6.1
– Test new Heimfall container on Linux 5.15
To rule out that it’s an issue with Linux 6.1 and PHP 8.1 in general, you could test a bare metal install, e.g. via Ondrej’s PHP repo: https://packages.sury.org/php/README.txt
After systematical testing, I’d report the issue first to the Heimdall container developers/maintainers, then to the RPi kernel developers. Before doing the second, it would be beneficial to verify that the same issue appears on Raspberry Pi OS 64-bit.
Another thing: This issue is actually unrelated to Debian Bookworm as on all SBCs the kernel version is independent of the Debian version and you faced the issue on Debian Bullseye as well. So to further track this, please open an issue on our GitHub repository or forum.
Updated my “Docker-station” (JDownloader2 and Solaranzeige running) on a Pine Rock64 with 2 GB. Update took 1 hour and is running fine, still no issues after 2 hours of testing.
I think i will upgrade rest of my systems (1x Intel Atom Z83, 1x Raspberry Pi1, 1x OrangePi PC, 1x Raspberry Pi Zero) next weeks 🙂
So, let me say again:
thanks a lot for all the time, money and grey-hairs developers have invested!
Many thanks for your kind feedback. Great that it works well for you. Still, keep creating the offered backup when doing the upgrade and feel free to report any issue you face with your other systems, so we can add further migration steps if needed.
Hi again,
just wanted to say that i upgraded my “Z83 II” Intel Atom (it is my Zoneminder System, not fastet system on planet but working with 7-10 Watt only for 3 cams in HD quality) successfully.
Only issue:
Restarting and zoneminder did not work when accessing via (browser)webinterface (something with PHP and access and level and directories…). Using the zmninja app with android is running.
Cleared browser cache, now everything is working fine. I think it was confused by update from PHPxxx to PHPxyz on serverside.
If i am the only one having problems with that, don’t worry, but if a lot of guys telling you this problem, you should add a warning message to “clear your browser’s cache when running services like apache, mariadb or zoneminder” ?! 🙂
Regardes
Hmm, a PHP, database or webserver update should not affect the web frontend, unless the application itself is updated as well. However, of course some internal logic would be able to do this, while I’ve no idea for what reason such would be done, especially in a way that the old cached assets remain incompatible. If someone else faces this, adding some logs would be fine: Browser (HTTP response/error code + developer tools console), webserver, PHP and backend/service logs, so we can check what the exact issue was. A hint could then be to try clearing browser cache when facing issues with any web application after the distro upgrade.
Hi,
it was nearby same error messages like in this post here:
https://forums.zoneminder.com/viewtopic.php?t=32004
I tried to install and reinstall als last comment there suggested to do, but this did not solve the problem.
So i started ZMninja and it worked. I was wondering and i installed chromium browser on my laptop and ZM was accessible and running via webinterface. I started my firefox browser on laptop again but there was still this strange error. I googled again and found a page where someone told “clear cache and most problems are gone”. I cleared cache, restarted firefox, ZM is running.
But, once again:
this is no error of dietpi, it is a problem of client side (as fas as i understand this problem), but it happens after upgrade of dietpi 😀
BTW… maybe you are right and it is a problem of the ZM installation because after the probem started to appear, i reinstalled zoneminder and there was a version change from 1.36.31 to 1.36.33 (or something like that), but problem still existed until clearing cache on clientside.
Regardes
If you are involved in this forum thread, note that
dietpi-softwareinstalls PHP-FPM, the nowadays common way to run production PHP applications, instead of the basically deprecated Apache PHP module. So instead ofa2enmod php8.2(8.2 on Bookworm) and what they are trying there, it isa2enconf php8.2-fpmand e.g. checking the related servicejournalctl -u php8.2-fpm. The `dietpi-bookworm-upgrade` script however does this automatically as part of the software reinstalls.But probably you installed the webserver and PHP manually as part of some zoneminder install guide or installer script? Then it is quite possible that the changed PHP version requires a related manual change in the webserver config, respectively enabling/disabling the module or config snippes for the new PHP version.
Updating zoneminder could be tested separately. If this alone also causes and issue and clearing the cache helps, then it seems like some cacheable asset has changed with the zoneminder update but the name of the asset or the URL used to load it stood the same. Usually, when breaking changes (or any changes) are done to assets, one changes either its name or the URL to invalidate the cached asset. In web applications with separate backend, this is often solved by simply appending a hash of the asset as query string to the src/href attribute, like
src="js/app.js?h=123456789". On dietpi.com, which is a static website without backend, we simply increment a?v=1version number of assets whenever we do a breaking change.Worked well. Only issue I see so far is the following warning when rebooting:
Failed to set wall message, ignoring: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists
Call to Reboot failed: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists
Thanks for reminding us about this issue. I still didn’t find the time to look into it. It is visual only, and disappears when enabling systemd-logind or installing software which depends on it (like a desktop). But probably there is a way to mute the error or telling systemd to not attempt talking to logind on poweroff/reboot if the service is not up.
Worked well on Odroid HC4! Only the public facing endpoints of Nextcloud and Jellyfin were unavailable. After I ran Certbot, everything works fine.
Thanks for all your work.
Thanks for your feedback. I’m not sure how the Bookworm upgrade can affect the DDNS provide-side stored IP, but probably a coincidence + the long upgrade process during which no DDNS updates (cron jobs) were done.
I upgraded from bullseye to bookworm, Worked well on my rpi 4
however i am left with a apt upgrade of 11 packages which never upgrade. It says upgrades have been kept back, how do i solve this?
I guess its FFmpeg packages (which includes libavdevice and such libraries)? I merged a live patch some hours ago, which can be applied via dietpi-update and should solve the problem.