Home   2026-10-22 19:56:51

←

Software-update - DietPi 10.7

Original article

DietPi logo (170 pix)DietPi is een lichtgewicht besturingssysteem voor zogenaamde singleboardcomputers. Het is op Debian gebaseerd en geoptimaliseerd om maximale prestaties uit de kleine computers te halen. DietPi heeft daarnaast ook een groot aantal ready-to-run applicaties die kunnen worden geïnstalleerd. Hoewel de naam anders doet vermoeden is het niet alleen geschikt voor Raspberry Pi's, maar ook prima te gebruiken op hardware van bijvoorbeeld Odroid, Orange Rock en Pine. Versie 10.7 is uitgekomen en hier zijn de volgende veranderingen en verbeteringen in aangebracht:

New images
  • Containers with network | We added support for containers with virtual network, providing images with network stack and SSH server pre-installed, which configure the network on first boot based on dietpi.txt choices, using DHCP on any first detected veth or VLAN interface by default. These work all e.g. for LXC containers. #8238
  • ARMv8 VMs | We added support for ARM VMs, and will host a full set of images and virtualizer appliances. We could not test all of them yet. Let us know if you face any issues, or importing an appliance (OVA/VMX/UTM) fails. We might need to adjust the VM configurations a bit.
  • LubanCat 4 | Support for this EmbedFire SBC with Rockchip RK3588S SoC has been added to DietPi, based on mainline Linux and U-Boot. #8258
New software
  • HomeBox | This self-hosted home inventory and organisation system has been added to our software catalogue with ID 219. #8240
  • Scrypted | This high performance video integration and automation platform has been added to our software catalogue with ID 220. #8277
New tools
  • dietpi-network | The DietPi network configuration has gone through a rework. A new tool dietpi-network allows to configure multiple Ethernet(-like) and WiFi interfaces. This allows to e.g. configure one interface with gateway for Internet access, and another one with static IP and without gateway for LAN access. This works independently of the interface name, i.e. it does not need to be eth[0-9] or wlan[0-9], but the type is detected in other ways, which adds support for systemd's "predictable interface names", as well as virtual interfaces as provided in container guests. A CLI has been added to add, remove, or adjust individual interfaces. Configurations are stored in per-interface /etc/network/interfaces.d/<name>.conf drop-in config files, and also automatically migrated from the previously used /etc/network/interfaces when applying changes. These changes are a basis to allow configuring more complex network setups, like bridges, NAT, and e.g. more flexible WiFi-to-WiFi hotspots.
Enhancements
  • Allwinner SBCs | USB DVB device drivers have been re-added to the kernel packages. They were lost for Allwinner boards between Linux 6.12 and 6.18. Now they are added to all kernel builds via post-config hook, i.e. independent of the used defconfig. #8218
  • DietPi-Banner | The Fail2Ban status now also counts bans for whole subnets in CIDR notation, which can be applied manually via fail2ban-client. The banner message now accordingly refers to "ban(s)" instead of "banned IP(s)".
  • dietpi-timesync | /boot/dietpi/func/run_ntpd has been renamed to /boot/dietpi/func/dietpi-timesync, for consistency, and since it does not make use of the nptd tools anymore since years. When time is synced, it does now restart systemd-timesyncd.service, to force a fresh connection attempt to the time servers in any case. Especially when the service starts during boot, it has been observed to give up for a while, if network connectivity has not been fully established yet. /boot/dietpi/func/dietpi-timesync is called at a later boot stage, and in the context of the dietpi-update check preceded by a general network connectivity check, so that systemd-timesyncd is more likely able to connect to time servers immediately. This change may hence speed up, or even avoid the timeout abortion of the initial time sync at boot, and following DietPi and APT update checks, if enabled.
  • dietpi-software | Chromium: The low-end device mode flag and some other legacy flags, aiming to maximise Chromium performance at the cost of visual quality, have been removed from our config /etc/chromium.d/dietpi. These had some value at Raspberry Pi 1 times, but since some years, Chromium cannot be executed on ARMv6 SBCs anyway. For Chromium to be started as root, e.g. in some kind of minimal kiosk setup, the --no-sandbox flag is needed, and the --test-type flag hides a warning that skipping the sandbox is not recommended for security reasons. This is now applied only conditionally, if Chromium is really started as root user, otherwise sandboxing is used. Note that we generally do not recommend to start desktop sessions and GUI applications as root on a regular basis, and some, like Chromium and Mate, will throw respective warnings. Hence this is mainly aimed for direct Chromium starts from Linux console, where additional permissions are needed in any case, with trusted websites, like a fixed page in kiosk mode. #25394
Bug fixes
  • Raspberry Pi | Resolved an issue where dtparam entries in config.txt were ineffective, if DRM/KMS was enabled. Any dtparam entry sorted after any dtoverlay entry, is gets applied to the overlay, rather than the base device tree, that way becoming ineffective, or change/break the overlay. This particularly started to cause issues since DietPi v10.5, when we added dtoverlay=vc4-kms-v3d as commented line into the display section of our default config.txt, above all dtparam lines. As fast as KMS/DRM is enabled, which uncomments the line, all dtparam entries become ineffective. Onboard HDMI audio on the first port couldn't be enabled along with KMS/DRM, since dtparam=audio=off (intended to disable the Broadcom analogue 3.5mm driver) got applied to dtoverlay=vc4-kms-v3d to become dtoverlay=vc4-kms-v3d,audio=off, which disables HDMI audio on the first HDMI port. #8202, #25411
  • Orange Pi 5/5B | Resolved a v10.5 regression where the USB 2.0 and Type-C ports were not functional, since we moved to mainline Linux where the respective device tree overlay changed its name. Without the overlay, they are running in OTG mode.
  • Orange Pi 3 LTS/ROCK 3A | Resolved possible high package loss rates when using Ethernet. #8285, #8295
  • dietpi-banner | Resolved an issue where the number of failed systemd services could not be obtained when logging in as non-root user, if D-Bus was not installed. #25413
  • dietpi-software | Ampache: Resolved an issue where detecting the latest version failed, since Ampache 8 requires PHP 8.5+. The latest version is now searched among all releases, so that latest Ampache 7 is downloaded on all supported Debian versions at time of writing.
  • dietpi-software | WiringPi: Resolved an issue where the installation failed on Odroid SBCs since Debian Trixie, since an outdated package was tried to be installed. Also, support for all recently added Orange Pi boards was added. #8266
  • dietpi-software | Roon Bridge: Resolved an issue where the latest version failed to start, due to a missing new dependency. #8287
  • dietpi-software | Immich: Resolved an issue where the install failed with recent pnpm, since the state dir cannot be set for local workspace basis anymore. #25482

DietPi

Versienummer 10.7
Releasestatus Final
Besturingssystemen Linux
Website DietPi
Download https://dietpi.com/#download
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

Feedback • 13-09-2026 10:00
14 • submitter: RobbyTown

13-09-2026 • 10:00

14

Submitter: RobbyTown

Bron: DietPi

Update-historie

13-09 DietPi 10.7 14
09-08 DietPi 10.6 6
15-06 DietPi 10.5 18
18-05 DietPi 10.4 7
19-04 DietPi 10.3 5
23-03 DietPi 10.2 4
22-02 DietPi 10.1 4
26-01 DietPi 10.0 12
12-'25 DietPi 9.20 0
11-'25 DietPi 9.19 2
Meer historie

Reacties (14)

Hoewel de naam anders doet vermoeden is het niet alleen geschikt voor Raspberry Pi's, maar ook prima te gebruiken op hardware van bijvoorbeeld Odroid, Orange Rock en Pine.
Draait ook prima op een (x86) PC, baremetal of VM. Ideaal als je een lichte OS-laag nodig hebt tussen hardware/hypervisor en hogere applicatielagen (Docker, etc.). DietPi is compatibel met Debian, dus goed ondersteund.

[Reactie gewijzigd door The Zep Man op 13 september 2026 11:04]

DietPi is een fork van Armbian en een lichte OS laag is een kwestie van weinig packages installeren in de image. Als je temninste om non-volatile storage gaat, RAM footprint is een ander verhaal. Echter hoe minder packages pre-installed, hoe groter de kans dat je toch zelf nog een groter aantal moet na-installeren. Wat mij opviel is dat bij first-boot een software-install wordt aangeboden. <dietpi>.img.xz is klein en dus snel te downloaden en neemt ook weinig ruimte op download servers in beslag, maar daarna 'groeit' het alsnog.

Ik heb een Radxa ROCK3A en n.a.v. dit artikel eens even gekeken wat de image behelst en dat is wel even schrikken vergeleken met wat Armbian zelf/origineel biedt. O.a. is er geen NetworkManager aanwezig (standard in Debian13) wel systemd-networkd, maar dat is disabled. In plaats daarvan heeft hij (MichaIng op github) een eigen .service file gebaseerd op legacy ifupdown. O.a. werd mijn DNS fout gezet, iets wat normaliter bij verse images met NetworkMnanager geen issue is. Ook dropbear i.p.v. openssh-server. De bootloader (U-Boot 2026.x based) is gewoon armbian build en geen optie om ook vendor/Rockchip U-Boot en kernel (wat Armbian biedt) te selecteren, zodat een aantal HW modules op de ROCK3A onbenut blijven. O.a. mijn 8TB SATA HDD die aan de ROCK3A is dan niet benaderbaar.

Verder is het hoofdzakelijk rename van 'armbian' naar 'dietpi'. Doe maar eens een find / -name "dietpi*". Het zijn heel veel scripts, bovenop Debian, maar alles in de image gepatched. Niet als .deb packages. Dat gaat problemen opleveren als je standard Debian dist-upgrade wil doen, voor mij is het daarom een no-go. Ik heb ook wel images van https://cloud.debian.org/images/cloud/trixie/latest/ gebruikt, o.a. nocloud varianten, dat gaf meer vertrouwen.
Dat gaat problemen opleveren als je standard Debian dist-upgrade wil doen
Waarom zou je dat willen?
Je kiest voor een distro, in dit geval DietPi. Ja, dat is Debian gebaseerd. Maar waarom ga je de distro waar je voor gekozen hebt proberen te omzeilen door commando’s uit te voeren van de onderliggende distro? Dan weet je dat je dingen kan verkl*ten.

Ask me how I know: dat heb ik zelf ook een paar keer gedaan. Daar moet je mee ophouden: je kiest voor een distro, met alle voor- en nadelen van dien. Als je de nadelen te groot vindt: stop met deze distro en kies voor een andere.
Het is in mijn geval niet een kwestie van zou willen, maar iets wat ik al 10 jaar doe middels Opensuse Tumbleweed. Is rolling release distro. Ook voor Debian op sommige HW/computers pas ik de sources.list* aan zodat ik efficienter ook eigen SW kan ontwikkelen en draaien.

De vraag is dan ook wat je onder 'distro' verstaat. Is het een pre-installed image dat je met dd of balena etcher o.i.d. op SD-card schrijft en door invoeren van username/password (en WiFI, ssh keys) laat draaien en verder nooit 'apt update && apt full-upgrade' dan wel 'zypper dup' gebruikt. Of is het een multi-arch (x86_64, aarch64, armhf, armel, RISC-V, etc) eco-systeem met, b.v. net-installer (tftp, http, minimale netinst.iso) en dan zelf keuzes maken in het installatie programma ten aanzien van partitties, filesystemen, crypto, Desktop Environment, etc. Of is het misschien beide, afhankelijk van use-case en de gebruiker.

Vorige week oude laptop (32-bit) van bullseye->bookworm, maar 1 vraag, rest unattended (scherm is kapot, dus alles via ssh). Wellicht omdat ik het ding al jaren geleden, toen nog met stretch of buster, zodanig had opgeschoond dat het zo soepeltjes verliep.

Ik beschouw wat ik aantref of aanpas in repository spec als wat de distro is. Ik bouw ook zelf U-Boot en kernels enz, dus heb geen enkele moeite om door te gaan waar jij aangeeft dat ik mee moet ophouden. Er gaat bij SW en elecronica onwikkeling wel eens wat mis, maar daarom gebruik ik Btrfs met snapper voor root filesystem. Ideal voor korte testjes en prima roll-back of last-know-good zoals dat in Windows heet.

Ik heb verder geen DietPi in gebruik, het is dus geen kwestie van stoppen, maar het was kijken wat het is. Gedaan als virtuele machine op mijn ROCK3A zelf. Die heeft geen SD-card, maar naast de 8TB HDD ook een 256GB NVME met ruim 100GB vrij. Zoals al aangegeven, Btrfs als filesystem, inclusief zstd on-the-fly compressie. U-Boot bootloader zit in MTD/SPI flash. Voor latere/krachtigere ROCK5B 'SBC' (16G RAM, 512G NVME, 8T HDD) zelfde methodes alleen geen U-Boot maar EDK2 UEFI als firmware/bootloader, zodat het gewoon is zoals een Intel/AMD PC. Nog steeds oorsponkelijk Armbian, maar bootpartitie type 0xEF00 gezet, grub-efi en Debian Sid kernel. Idem voor RPi4, maar dan van RasberryPiOS 64-bit naar alleen Debian (raspi.list disabled). Hoofdreden m.b.t. RPi is het cloudinit drama van kerst 2025, dat heeft MichaIng ook zeker meegekregen en daarom wellicht veel eigen scripts, ook voor networking. Ik zelf had Raspbian op oude 32-bit RPi0/1 al voorzien van systemd-networkd, is voor remote/headless, 24/7 operation.

Er zijn ook mensen die buildroot gebruiken voor een eigen 'distro', maar dat gaat mij te ver. Als b.v. er maar 512MB eMMC zou zijn i.p.v. een oude 32GB SD-card, dan wellicht wel buildroot.
Dat gaat problemen opleveren als je standard Debian dist-upgrade wil doen
Waarom zou je dat willen?
DietPi is gebaseerd op Debian. Op alle andere op Debian gebaseerde distributies die ik ken (Ubuntu, Mint, Pop!_OS, Raspberry Pi OS) kan je prima een dist-upgrade doen om het systeem te upgraden zonder het stuk te maken. Als dat op DietPi niet kan ligt dat toch echt aan DietPi wat mij betreft. Laat ze dan een custom versie van apt mee leveren waar dat commando uit is gesloopt, of in ieder geval een wrapper script met een dikke waarschuwing dat die functie niet wordt ondersteund en waarschijnlijk je installatie sloopt.
Zoveel mensen, zoveel wensen. Ik draai al meer dan 25 jaar Debian en ook al jarenlang naar tevredenheid DietPi op andere apparaten. DietPi werkt prima voor mijn doel, nooit issues gehad. De ontwerpkeuzes hebben wat impact ja, maar als je je daar bewust van bent is er geen probleem. Ik vind het wel een poweruser / Tweaker distributie, maar dat is Debian eigenijk ook natuurlijk.

[Reactie gewijzigd door zordaz op 13 september 2026 22:39]

Inderdaad mooi en goed gezegd: Zoveel mensen, zoveel wensen

Dat merk ik heel vaak, ziiten enorme verschillen in hoe mensen computers gebruiken. En dit is tweakers, kan je eigenlijk van alles verwachten.

Met Debian kan het ook alles zijn; Er zullen mensen zijn die hele nieuwe/andere subsystemen draaien, b.v. Xlibre i.p.v. Xorg omdat ze Wayland haten. Enz.

Belangrijkste is denk ik dat in de kern het open-source is, en je in principe je eigen spullen werkend moet zien te houden. Ook bij Raspbian/RaspberryPiOS kan je niet even de helpdesk bellen en eisen dat er iemand langs komt om je RPi te repareren, hoewel RPL dus de HW verkoopt. DietPi is alleen SW and Armbian krijgt donaties en gelden van enkele SBC suppliers voor zover ik weet.
Wat maakt DietPi nou lichter dan een "minimal" installatie van Debian op x86 hardware? Veel minimalistischer dan dat wordt het namelijk niet volgens mij. Ik weet niet of een minimale installatie van Debian inmiddels out-of-the-box werkt op een Raspberry Pi.
DietPi is met name getweaked voor het headless gebruik op SBC's. Bijvoorbeeld de software is zo ingesteld zodat meer gebruik wordt gemaakt van caching in memory in plaats van het flashkaartje zodat die langer meegaan. Verder maakt het je leven wat makkelijker door een hele reeks aan applicaties via hun eigen user interface kant en klaar te installeren (zitten ook nadelen aan zoals afwijkende applicatie-settings). Ik ken Debian Minimal zelf niet, maar neem dan even aan dat je daar net wat meer werk zal moeten verrichten voor hetzelfde resultaat.
En niet alleen de optimalisaties. De Debian minimal image is ruim 600MB groot, DietPi slechts 209MB.
Maar heb je, als je dat image van 209MB naar een SD kaart krast, een werkend systeem of moeten er bij ingebruikname nog allemaal packages gedownload en geïnstalleerd worden?

De filosofie van Debian is dat je met het installatiemedium waar je voor kiest een werkend systeem kan optuigen, zonder dat je daarvoor online hoeft te zijn. Het "minimal" image past nog precies op een recordable CD en stelt je in staat om een headless server te installeren met wat basisfunctionaliteit. Wil je meer, zoals een desktop GUI, dan heb je packages uit de repository nodig of had je met een "live" image moeten beginnen van zo'n 4GB. Deze filosofie doet misschien wat ouderwets aan maar het stelt je in staat om met 1 download meerdere systemen te installeren, ook op plekken waar misschien geen (betrouwbare) internetverbinding is.
Durf ik niet te zeggen, want voor mijn Pi gebruik ik de standaard Debian Minimal die in de Raspberry pi imager zit. Maar vaak installeer je packages pas zodra je ze nodig hebt, en de rest is overbodig. Ik zou eerlijk gezegd dus mijn voorkeur aan DietPi geven.
DietPi is met name getweaked voor het headless gebruik op SBC's. Bijvoorbeeld de software is zo ingesteld zodat meer gebruik wordt gemaakt van caching in memory in plaats van het flashkaartje zodat die langer meegaan.
So far so good
Verder maakt het je leven wat makkelijker door een hele reeks aan applicaties via hun eigen user interface kant en klaar te installeren (zitten ook nadelen aan zoals afwijkende applicatie-settings).
Hier haak ik dus een beetje af. Ik hou niet van de custom user interfaces waardoor ik niet weet wat er precies gebeurd. Ik beheer mijn (Debian) Linux systemen via de command line en via Ansible, zodat ik precies weet wat ik installeer en hoe ik dat configureer. Dat is misschien iets meer werk maar wel 100% reproduceerbaar en onder mijn controle.
Dan zou ik persoonlijk voorkeur geven voor een LXC container in b.v. Proxmox

Om te kunnen reageren moet je ingelogd zijn