Debian 13 Trixie has been released on 2025-08-09 and we want to give you a brief overview and info how to install it or upgrade your Bookworm system.
- Feature overview
1.1 Release schedule
1.2 Available software updates
1.3 Other notable changes - Incompatible software
- How to apply
3.1. DietPi Trixie images
3.2. Upgrade from Bookworm - Feedback & Support
1. Feature overview
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) |
| 12 | Bookworm | oldstable | 2023-06-10 | 2026-06-10 (2028-06-30) |
| 13 | Trixie | stable | 2025-08-09 | 2028-08-09 (2030-08-31) |
| 14 | Forky | testing | 2027-08-?? | 2030-08-?? (2032-08-31) |
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 behavior by looking at the version strings when running 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 Firefox and Chromium web browsers, which receive regular major version updates for security reasons.
This means that once a new Debian version is released, software packages provided by the previous Debian release are about 2 years old. A new Debian release provides hence significant feature updates.
1.2 Available software updates
The following list shows an excerpt of updates available with Debian Trixie for software often used on DietPi systems:
| Software | Bookworm | Trixie | Note |
| OpenSSH | 9.2 | 10.0 | |
| Unbound | 1.17.1 | 1.22.0 | |
| Python | 3.11 | 3.13 | |
| PHP | 8.2 | 8.4 | |
| MariaDB | 10.11.11 | 11.8.2 | |
| PostgreSQL | 15 | 17 | The required cluster migration is included with our Trixie upgrade script. |
| Redis | 7.0.15 | 8.0.2 | |
| Nginx | 1.22.1 | 1.26.3 | |
| qBittorrent | 4.5.2 | 5.1.0 | |
| Transmission | 3.00 | 4.1.0 | |
| Kodi | 20.1 | 21.2 | This is not true for Raspberry Pi, where newer Kodi versions are provided from the archive.raspberrypi.com APT repository. |
| FFmpeg | 5.1.6 | 7.1.1 | |
| MPD | 0.23.12 | 0.24.4 | |
| Mesa | 22.3.6 | 25.0.7 | |
| Linux | 6.1 | 6.12 | This is true for x86_64 platforms only. ARM/RISC-V SBCs get separate kernel upgrades from our APT repository. |
Notable are the PHP and Python upgrades to their respective latest official version, which affects a large number of dietpi-software installation options.
1.3 Other notable changes
1.3.1 64-bit time_t transition
With Debian Trixie, a transition to 64-bit time_t values with the newer time64 syscalls has been done. On 32-bit systems, these time values were only 32 bit long, which makes it impossible for them to represent any time after 2038-01-19 03:14:07 UTC, the so called year 2038 problem, or “Epochalypse”. After the transition, these values are 64 bit long, eliminating the issue. The time64 syscalls are available since Linux 5.6, which hence also defines the minimum Linux version needed to support Debian Trixie on 32-bit systems. Additionally, the transition implied renamed library packages, giving them a “t64” suffix. E.g. the libssl3 package is now called libssl3t64, which makes older DEB packages not compiled against the new library incompatible also package-wise. For 64-bit systems, however, nothing changes: time_t values were already 64 bit long before and the “t64” suffix packages formally “provide” the variants without the suffix, which enables compatibility also package-wise. For 64-bit systems, this means the minimum required Linux version remains 4.15, to guarantee regulatory database support without CRDA.
2. Incompatible software
DietPi offers Debian Trixie based images since Debian Bookworm was released, but we did not provide them prominently on our download page or elsewhere until now, hence the number of users has been low so far. To compensate that, systematic tests of all software option in dietpi-software have been performed, assuring that installations go through, services start up, and processes in case listen on the intended network ports: https://github.com/MichaIng/DietPi/wiki/Debian-Trixie-testing
The following list of software titles is known to be not (yet) compatible with Debian Trixie:
- QuiteRSS: Due to outstanding upstream development and maintenance, Debian has removed the package from their repository. This is hence known to not come back, and we will probably remove it from DietPi with the first 2026 release.
- Netdata: Since the project turned commercial, and the web interface is now closed source software, Debian removed it from their repository. We did not yet decide whether we switch to Netdata’s own APT repository, and keep it as software option. Based on information from Debian, the new local web UI lost a lot of features compared to the old open source one, which were moved into Netdata’s cloud platform instead, for which an account is needed, and paid plans to exceed certain limits. If you are interested in Netdata, please join the discussion on our GitHub repository: https://github.com/MichaIng/DietPi/issues/6929
- Jellyfin: Support for 32-bit has been generally removed from the project. There are packages for older Debian versions, but those are not updated anymore either: https://jellyfin.org/posts/jellyfin-release-10.10.0/#breaking-changes
- Moonlight (CLI): The official repository has not been updated for Debian Trixie yet, and packages for Debian Bookworm are not compatible due to 64-bit time_t transition, mentioned above.
In case you want to use one of the above software titles, you can find up-to-date Debian Bookworm based DietPi images for all platforms here: https://dietpi.com/downloads/images/
3. How to apply
We provide Debian Trixie images as well as a script to upgrade your Debian Bookworm based DietPi system.
3.1 DietPi Trixie images
Trixie images are provided on our download page. You may follow the instruction from our documentation to get DietPi up on your platform.
3.2 Upgrade from Bookworm
We provide a script to upgrade a DietPi Bookworm system to Trixie, as safe as possible. While starting over with a fresh image is generally cleaner, we know that some of you have setups which are time consuming to replicate on a fresh system. Our script warns you if one of the yet incompatible software options is installed on your system, offers to create a backup first, does all known needed migrations and adjustments to have your software running on the new Debian version as before. Execute the following command on your console to start the distribution upgrade:
sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-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 review the output, before continuing with software (config) migrations, which also includes some dietpi-software reinstalls.
Generally: If you face any issues or see errors, please keep/copy the output of the script somewhere, and report them to us, so we have a chance to find out what happened and why, and can in case prevent it for future users. If RAM logging has not been disabled, also copying the APT log file to a persistent place preserves possible relevant output:
cp -a /var/log/apt/term.log ~/Once everything is done, the script offers to do a reboot, which we highly recommend. On first console login as root user after the reboot, old leftover Bookworm APT packages are automatically removed.
In case you run a graphical desktop, just open a terminal emulator and execute sudo -s to finish this step.
4. Feedback & Support
Feel free to leave a comment below for short feedback about this article and how Trixie works for you.
For more detailed feedback, to attach logs or console output, if you face issues with our upgrade script or Trixie in general, please use the following issue on our GitHub repository: https://github.com/MichaIng/DietPi/issues/7644
Alternatively, you can open a topic in our forum’s troubleshooting section: https://dietpi.com/forum/c/troubleshooting/10
Happy hacking!
note: the download page says:
“All image downloads incl. Debian 12 Bookworm”
But it does actually download Trixie
This was meant to say that there are additional images behind that link, especially older Bookworm ones, if anyone requires them. Looks like the text is unclear. I am open for suggestions.
i mean it says inclusively or included so it does what it says
Thanks for providing this nice script! The upgrade worked just fine on one of my Pi´s. However, I had to remove the apt-listbugs package using the subshell, because of the following error: “/usr/bin/apt-listbugs apt returned an error code (10)”.
On my second Pi, the kernel image got lost during the reboot for some reason and the Pi wouldn´t start up anymore (the green LED was blinking 7 times). It got solved by downloading the latest kernel8.img from the official RPI Github repo. Upon reboot, it threw a message that the kernel requires an update. I launched dietpi-config >> Advanced >> RPI kernel choice. Once the Kernel choice menu was exited, the script reinstalled the kernel (headers??) and I rebooted once again. Finally, it was all up and running again.
Since I am not sure, if this was caused by myself (I changed some configs over time) or if it was just bad luck. Maybe this info is helpful for someone running into the same or similar issue… Cheers!
Thanks for your feedback. You do not have the log/output available anymore, do you?
apt-listbugsis available on Trixie as well, so I wonder why or at which point it caused issues.The kernel package should of course never be removed either. Generally, when facing issues, it makes much sense to preserve the output of the script. I am thinking about adding logs at least for the actual APT package upgrade commands, to see which removals were done.
when trying to upgrade from bookworm, i get the following error The repository ‘https://deb.nodesource.com/node_18.x trixie Release’ does not have a Release file.
any idea?
I have uninstall it from from diet-software and i have the node 22 installed with hombridge, but i dont know how to remove node 18
The legacy Node.js APT repository is/was probably in
/etc/apt/sources.list.d/nodesource_nodejs.list. It was used by DietPi until some years ago.If you uninstalled Node.js via
dietpi-softwarethat old repository was removed as well. Not sure what you mean by “node 22 installed with hombridge”? If you install or reinstall Node.js viadietpi-software, it would be always the latest, i.e. v24.7.0 at time of writing. But not via https://deb.nodesource.com/ anymore, since it does neither support ARMv6 nor RISC-V.I have reinstalled node via dietpi-software again and it installed v24. I re run the upgrade and still says the same error
E: The repository ‘https://deb.nodesource.com/node_18.x trixie Release’ does not have a Release file.
Then you need to search and remove the list file which contains this repository:
Thank that worked a treat, all updated now
thanks for the script
I have used this script with lighttpd server installed and the updated system breaks the server. Any suggestion I can do? I tried using a fresh install and copied the files in /etc/lighttpd and doesn’t work
I used the lighttpd package in apt repository and works fine
There might be breaking syntax changes between the Lighttpd versions of Bookworm and Trixie. If there are still issues with it, check the service logs:
.
Sorry in advance for double post, I’m updating from bookworm using the script, on the native pc, and have been stuck for 1 hr already on the flw line:
Deep recursion on subroutine “main::remove_links” at /usr/bin/deb-systemd-helper line 488, line 14.
Can you please guide ?
Hi! Thank you for the script! I could upgrade without errors but had to uninstall and reinstall ProFTPD afterwards. Just reinstall did not work. The configuration file of ProFTPD was already gone after the reinstall (not a problem though).
What was the issue with ProFTPD after the Trixie upgrade? If a fresh installation works, then our default config at least does not seem to contain incompatible keys.
On a reinstall, the existing config is backed up to
/etc/proftpd/proftpd.conf.bak_XXXXwith XXXX being the date of the backup.When you manually migrate to the deb822 format the scripts fails at sed -i command where it tries to switch from bookworm to trixie. Maybe you could also try the check for the debian.sources in /etc/apt/sources.list.d the replacment for that would be this code:
find /etc/apt/sources.list.d -name "*.list" -exec sed -i 's/bookworm/trixie/g' {} \;Just do not migrate to deb822. DietPi does not support it yet, not the upgrade script only, but several patches and install options create and expect list files and do not handle sources files.
Also, there is no reason to do this migration. deb822 has not much to do with Trixie, and it has no benefits, neither has the old format any lack of features or so, and it is still fully supported by all parts of APT.
For now, you need to revert to list format. When I find some time, we will migrate to deb822 on all distro versions in one go (Bullseye supports it as well).
After upgrading Rock64 from kernel 4.4 it stopped booting (using boot form USB). I was able to recover it through copying the dietpi-backup over the boot partition and then restoring it upon boot. It seems that the new bootloader is unable to boot from usb.
If it was Linux 4.4, then not one of our original images, or a very old one. Assure that our current linux-image-current-rockchip64 + linux-dtb-current-rockchip64 + linux-u-boot-rock64-current packages are installed, a boot.scr loads the correct kernel + device tree, and that U-Boot image is flashed to the SPI storage, which can be done via dietpi-config advanced options.
Yes it is an old image. When updated as suggested, after flashing the spi storage I am unable to boot from the USB disk (it boots from SD card. The serial console is empty.
If I do not flash the SPI, I can boot through extlinux from the USB but not with boot.scr. Maybe my configuration of the boot.scr is not good.
The result is:
DDR version 1.13 20180428 ID:0x805 Y In LPDDR3 786MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:7 OUT U-Boot SPL 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:17) board_init_sdmmc_pwr_en setup_ddr_param 1 booted from SPI flash Trying to boot from SPI NOTICE: BL31: v1.3(debug):9d3f591 NOTICE: BL31: Built : 14:39:02, Jan 17 2018 NOTICE: BL31:Rockchip release version: v1.3 INFO: ARM GICv2 driver initialized INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 1 INFO: plat_rockchip_pmu_init: pd status 0xe INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:39 +0000) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b50303930303800000000022c15 serial=d8ed574ae969758 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 Card did not respond to voltage select! mmc_init: -95, time 9 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 4 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Device 0: Vendor: Innostor Rev: 0.00 Prod: Ext. HDD Type: Hard Disk Capacity: 381554.0 MB = 372.6 GB (781422768 x 512) ... is now current device Scanning usb 0:2... Found U-Boot script /boot/boot.scr 3458 bytes read in 208 ms (15.6 KiB/s) ## Executing script at 00500000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** libfdt fdt_check_header(): FDT_ERR_BADMAGIC Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Bad Linux ARM64 Image magic! devnum=0 rootdev=PARTUUID=5DFC2C63-02 arch=arm baudrate=1500000 board=rock64_rk3328 board_name=rock64_rk3328 boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};i boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf boot_net_usb_start=usb start boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_targets=mmc0 mmc1 usb0 pxe dhcp bootargs=root=PARTUUID=5DFC2C63-02 rootfstype=ext4 rootwait console=tty1 consoleblank=0 coherent_pool=2M partuuid= bootcmd=run distro_bootcmd bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci}; bootcmd_mmc0=setenv devnum 0; run mmc_boot bootcmd_mmc1=setenv devnum 1; run mmc_boot bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi bootcmd_usb0=setenv devnum 0; run usb_boot bootdelay=0 bootfstype=ext4 consoleargs=console=tty1 cpu=armv8 cpuid#=55524b50303930303800000000022c15 debug=1 devnum=0 devplist=2 devtype=usb distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done docker_optimizations=off efi_dtb_prefixes=/ /dtb/ /dtb/current/ eth1addr=26:3c:3d:22:de:1f ethaddr=26:3c:3d:22:de:ff fdt_addr_r=0x01f00000 fdtaddr=0x87f00000 fdtcontroladdr=fcf051c8 fdtfile=rockchip/rk3328-rock64.dtb fdtovaddr=0x87fc0000 fileaddr=500000 filesize=d82 kernel_addr_r=0x02000000 load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M; pxefile_addr_r=0x00600000 ramdisk_addr_r=0x04000000 rootdev=PARTUUID=5DFC2C63-02 rootfstype=ext4 scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run; scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtye scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run le scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinuxi scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${scripe scriptaddr=0x9000000 serial#=d8ed574ae969758 soc=rockchip stderr=serial@ff130000 stdin=serial@ff130000 stdout=serial@ff130000 usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi vendor=rockchip Environment size: 4396/32764 bytes SCRIPT FAILED: continuing... Speed: 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.25.25 (7 ms) *** Warning: no boot file name; using 'C0A81919.img' Using ethernet@ff540000 device TFTP from server 192.168.25.1; our IP address is 192.168.25.25 Filename 'C0A81919.img'. Load address: 0x800800 Loading: TI see, indeed an old image with a U-Boot buid from Ayufan. The boot script fails to mount the partition as ext2 filesystem, so it is probably a dedicated FAT partition, while the boot script tries false commands or so.
Since WordPress commands are not so well suited for larger logs and commands, could you open an issue on GitHub or our forum instead? With an updated
boot.scrand after flashing the latest bootloader to SPI, it should be possible, regardless whether/bootis a dedicated partition or not.Works fine, thanks!!!
Updated my RPi5 to Trixie without any issue.
Struggled only with Home Assistant which required some manual updates of packages:
home_assistant_intents
hassil
How did you install HA, and what issues did you face with those Python modules? Since our HA implementation lives in its own pyenv, it is mostly immune to host OS changes. Only thing I could imagine is if a module build depends on a specific version of a host OS runtime library, and is incompatible with the newer version from Trixie. But those two you mentioned are pure Python modules, without C/C++ code embedded.
ran the script by copying the command line above. seemed to finish fine, and recommended reboot. when I reboot, I appear to still have bookworm installed. I clearly must have missed something. any advice?
If applies APT upgrades and a DietPi update before the actual Trixie upgrade. If this implied a kernel upgrade, it suggests a reboot as well. If that was the case, just repeat the script, to continue with the actual Trixie upgrade.
Did you see this line in between on the console, requiring to hit a key to continue?
thank you. no, I did not see that line, but I did repeat the script and all appears well. I appreciate the quick reply
Great, then it was all as expected. Let me know if we can enhance the text in the dialogues to make things clearer.
Hi,
I got the following when upgradng. Safe to assume I can ignore it?
Not an immediate issue, and in those cases the new package contains/uses the same directory anyway. But that the warning shows up might indicate that there is unexpected other stuff inside. Maybe some some evil macOS created its
.DS_Storeor._*trash inside :).Check what is inside, maybe you find a pattern which can be cleaned up with some
find -deletecommand.ls -Al /lib/hdparm /lib/firmware/qcaThey won’t be empty now in most cases, so it is more to see whether there is anything else aside of the expected content inside.
awesome, nice work MichaIng and of course the team. Hope you dont stress out for all the support tickets now. Keep it chill now. Good job!
sidenote. I’ll wait to update until after i backup everything and now for sure all the critical tickets been sorted out.
Thanks for your kind words :). Yes a backup definitely makes sense. A lot of potentially failure reasons have been sorted, but we cannot address everything depending on how customized a system is, especially if 3rd party repositories were added.
The script worked great on my Pi 4, Pi 5 and Opi 5 plus.
It worked on my rockpro 64 after I did it twice. First time went through, asked me to reboot and when I logged in there was no apt autoremove so I checked and my apt was not v3, nor were my repos set to trixie (still bookworm)
It doesn’t do anything that isn’t ready in another place as a failover so I did it again and no issues.
No errors, nothing in the logs either. Was like rebooting a box running alpine linux. Just rolled back to the last state it was in. Which is handy for some things but less so when it’s on accident.
The script also suggests a reboot if the preliminary package upgrades include a kernel upgrade. The dialogue says so
But I understand that one does not read every dialogue fully after 3rd upgraded system :).
The post says:
> On first console login as root user after the reboot, old leftover Bookworm APT packages are automatically removed.
What happens if this is a headless device that I login to via ssh? Can I remove the old leftover Bookwork APT packages myself, or do I really need to console login as root to complete the upgrade tasks?
Doesn’t matter whether you login via SSH, or local console, or serial console, or terminal emulator, or run
bash -sfrom anywhere else. It just requires an interactive bash session.The script
/etc/bashrc.d/zz-dietpi-autopurge.bashdoes this, which is invoked from/etc/bash.bashrcon DietPi.Worked nice on my RaspberryPi B model 2 v1.1 (yes, old hardware). Thanks !
I cannot access baikal any more. Neither the admin page nor user access is working. Can anyone help me troubleshoot?
I just tested it, and generally it works fine on Trixie. What is the error message, and is your webserver and PHP running?
Just assuming Apache2 here, might be
nginxorlighttpdinstead.I have just checked migration script on aarch64 VM – experience is amazingly smooth and pleasant. Nothing was broken! One package from 3rd party repository was removed – but that behaviour is expected and recovery is trivial.
Bravo MichaIng and the team!
One thing I noticed – running kernel in my case is still 6.1.0-25-arm64.
Thinking, if I should proceed with manual upgrade to one of https://packages.debian.org/trixie/kernel-image
Thanks for your kind feedback. Which SBC are you using? From the version string this looks like a Debian kernel, while we use some own builds or some built with Armbian build system for ARM boards.
I use RK3588 (here OrangePi 5), however DietPi runs as a Generic Device (aarch64) inside virtual machine. You may disregard my previous comment about kernel – if I need help, I will raise a new topic in the forum. Thank you as always!
Ah I understand. For a VM the Debian kernel should be fine, indeed.
Be sure to use the meta packages that do not have a version string, i.e.
That one depends on the actual versioned kernel packages, pulls a new one as dependency on upgrade, and hence also assures that Linux 6.12.y is installed on upgrade to Trixie.
Amazing, many thanks, just noticed the motd said it has trixie relased when login to one of my SBC board today. I upgraded 3 SBC in row:
1. Raspberry 2
2. Orange Pi 3 Zero
3. Orange Pi 5 Plus
The result is amazing, it runs smoothly, upgraded very well.
On Raspi 2, is slightly warmer compare to bookworm.
On Orange Pi 3 Zero which is hosted home assistant application with supervisor mode gave me warning that the system is not supported, but so far the HA is working fine.
On Orange Pi 5 Plus is working fine without any issue.
Many thanks for your kind feedback.
On Raspberry Pi, the distribution upgrade has no effect on the kernel or firmware version, so that end it should not have an effect on temperature. But of course it is possible that some new software version causes more load, or maybe is kept in some error loop that causes load. Check
whether you see a process with unexpected high (idle) load, and
whether you see some errors in the system log.
Note that HA supervised is deprecated/support dropped by HA team, hence I don’t think Trixie support will be added: https://github.com/home-assistant/supervised-installer/issues/413
If you depend on addons, I suggest to migrate to HAOS. If you can live without addons, use our HA core
dietpi-softwareoption. HA core is deprecated likewise, but we are keeping up support our end. One could never expect real support for it on HA forum etc anyway. Compared to HA supervised which requires additional maintenance around core, HA core, as part of HAOS etc, is naturally developed anyway.Hi there,
Is the Jellyfin trixie 32-compatible package available yet? That’s one of the main usage of my dietpi running on a Raspberry Pi2 32 bits and I’m holding off upgrading to Trixie because of that very package.
Thanks in advance for your answer.
Jellyfin has sadly dropped 32-bit support in general. Also the packages for older Debian versions are not updated anymore since v10.11: https://jellyfin.org/posts/jellyfin-release-10.10.0/#breaking-changes
I updated the info in https://dietpi.com/blog/?p=4014#incompatible.
Do you have the v1.1 revision of the RPi 2B that really does not support 64-bit?
Unfortunately, I think I do : “armv7i”, isn’t it?
Maybe it’s time for me to look for a more recent single-board device…
armv7l represents the kernel architecture, not necessarily the hardware architecture. You would need to check the PCB, which says “Raspberry Pi 2 Model B V1.1” or “Raspberry Pi 2 Model B V1.2”. The latter has the same chip as the Raspberry Pi 3, hence is 64-bit capable.
EDIT:
cat /proc/device-tree/modelmight reveal the board revision as well.Thanks for following up. I confirm I have a 32bits RP2. Currently looking at used OrangePi 3… I might upgrade to that in the near future. Thanks for the help @Michalng.
Bis zum gestrigen Tag fand ich DietPi noch optimal für meine Belange.
Mein Odroid-N2+ habe ich mit Ihrem Skript von Debian 11 “Bullseye” auf Debian 12 “Bookworm” upgraded und anschliessend als alles durch war (es gab ein paar Bugs von curl, cups und libgdbm6, die dann auf apt-mark hold gesetzt wurden damit das Skript durchläuft) und anschliessend wieder mit Ihrem Skript auf Debian 13 “Trixie” upgraded, wie es empfohlen wurde. Hierbei wurden die Holds entfernt und das Skript stolperte über Perl-5.40 dessen Abhängigkeiten nicht erfüllt waren, weil u.a. libc6 einen Bug aufwies und auf hold gesetzt wurde. Als am Ende alles so gelöst war, das das Skript zum Ende kam und ein Neustart anstand, wurde dieser durchgeführt (alles per ssh) und oh wunder, das System kam zwar wieder hoch und die Dienste laufen (Grafana, influxdb, telegraf, meine eigenen Skripte als intermittierende Dienste) doch seit diesem Neustart laufen SSHD und das Kommando “sudo” nicht mehr!! Also musste ich die eMMC abstecken, auf Adapter nehmen an einem anderen N2+, mounten und siehe da, es fehlten im Verzeichnis /usr/bin sämtliche sudo-Files! Ebenso in /usr/lib und selbst nach dem hinzufügen der fehlenden Dateien beschwert sich sudo nun über einen SYNTAX ERROR near line 54 in /etc/sudoers (in Zeile 54 steht der Verweis auf den Ordner /etc/sudoers.d ) – unverständlich wieso das nun plötzlich obsolet sein soll. Schlimmer noch: auch lokal kommt weder die grafische Oberfläche am HDMI Ausgang, noch eine Terminal-Konsole! Ich bekomme zwar meine bekannte Terminalausgabe, aber mit sudo-Fehlermeldung (von meinem darin angehängten Skript), und das wars. Der Cursor steht dort, aber nicht ausgefüllt und nicht blinkend, und lässt auch keine Tastatureingabe mehr zu. SSH funktioniert nicht mehr und auch RDP arbeitet nicht. Da ich auch kaum noch Zeit habe in diesem Jahr, muss ich das System nun so weiterlaufen lassen, ohne jede weitere Option auf Administration. Super gelaufen, ich bin echt bedient! NEVER CHANGE A RUNNING SYSTEM! Von wegen, immer aktualisieren…
I am sorry that you faced issues. It works well for most, but there is no guarantee.
Some general info we should probably add to the article: Never set a package on on hold to work around upgrade issues. Solve them, or restore a backup to revert to the old version, we are ready to help in the GitHub issue linked in the article. It will otherwise only cause subtile or more severe issues, especially if you then attempt to upgrade even further to a next Debian version with packages in place that belong to an older Debian version. libc6 in particular is the most essential package of whole Debian, everything depends on it, and binaries are build with support for a particular set of glibc/libc6 ABI versions. You cannot run a newer Debian version with onhold libc6. I am surprised that you were even able to run the next upgrade script (EDIT: Ah, most likely vast parts of the system were still Bullseye packages, due to package dependencies preventing upgrades with onhold libc6). Did you do a reboot between Bookworm upgrade and Trixie upgrade? That is absolutely mandatory as well, to assure the Bookworm upgrade was successful and complete, new kernel, init system and services are loaded.
It is expected that you may need to edit some config files. Some packages do migrations by themselves, and our script covers some other known cases, including a OpenSSH server config migration for Bullseye => Bookworm, but we cannot know/cover everything, especially not custom sudoers configs. This is the reason such distro upgrade is never done automatically by DietPi updates, and why we have a dedicated support thread for every upgrade script/path.
“Never change a running system” is a dangerous statement for IT, especially server systems, as long as you do not have a long-term support contract and system admin that keeps outdated software versions secure with backported security patches. The (IT) world evolves fast, and numerous security vulnerabilities are found daily in software, libraries, and the kernel itself, and they are patched quickly by Debian, as long as it is a properly maintained version. Debian Bullseye is EOL since summer 2024, hence is not maintained by their security team anymore. Running it implies security vulnerabilities, and the older it gets, the more vulnerabilities are found, and the more malware and hackers are going for those. So my advice would be to stay at the latest stable Debian where possible, and upgrade as soon as a spare weekend permits fiddling with possible (and often expected) issues, config updates and such. If any issues are left, we are ready to help at GitHub or our forum.
Ah, and as this seems to have not been the case: accept the offer of the script to create a backup, especially if a downtime for setting up a fresh image is not feasible.
Hello, I made a download of the latest Trixie version for the RaspberryPi4, but the SHA256 checksum doesn’t match.
Kind regards
Kai
See here: https://github.com/MichaIng/DietPi/issues/7802