Dietpi Update from 10.6.2 to 10.7.2 fails (trixie)

Pi-Rate · 10 October 2026 22:27

I have searched the existing open and closed issues

Required Information

Date | 2026-10-11 00:06:57
Program name | DietPi-Update
Command | `apt-get -y --with-new-pkgs upgrade`
Exit code | 100
DietPi version | v10.6.2 (MichaIng/master)
Distro version | trixie (ID=8)
Kernel version | `Linux mini14 6.12.107+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.107-1 (2026-08-29) x86_64 GNU/Linux`
Architecture | `amd64`
Hardware model | Native PC (x86_64) (ID=21)
Power supply | Internal Power Supply of Mac Mini
SD card | none
Image creator | hermann
Pre-image | debian bookworm

Additional Information (if applicable)

n/a

Steps to reproduce

I run ‘dietpi-update’ to update to v10.7.2. After a while it runs into the below error.

Expected behaviour

The update should succeed.

Actual behaviour

The update is blocked with the below error.

Extra details

Below is the log output with the error.
DietPi is now still running as 10.6.2 and I’m not sure how to proceed.

```
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following package was automatically installed and is no longer required:
  linux-image-6.12.107+deb13-amd64
Use 'sudo apt autoremove' to remove it.
The following packages have been kept back:
  jellyfin
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up php8.4-fpm (8.4.26-1~deb13u1) ...
Failed to connect to system scope bus via local transport: Connection refused
Failed to connect to system scope bus via local transport: Connection refused
invoke-rc.d: could not determine current runlevel
Failed to connect to system scope bus via local transport: Connection refused
invoke-rc.d: initscript php8.4-fpm, action "restart" failed.
Failed to connect to system scope bus via local transport: Connection refused
dpkg: error processing package php8.4-fpm (--configure):
 installed php8.4-fpm package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 php8.4-fpm
E: Sub-process /usr/bin/dpkg returned an error code (1)
```

Joulinar · 11 October 2026 10:37

Hi,

thanks for the report. The failing part is the php8.4-fpm post-install script, which cannot restart the service because it cannot reach the system D-Bus (Failed to connect to system scope bus via local transport: Connection refused). So PHP itself is probably not the actual problem, but the D-Bus/systemd state of the system.

The report says the pre image was Debian Bookworm, so I’d like to understand how you got to Trixie:

Did you recently upgrade from Bookworm to Trixie yourself, e.g. via DietPi-Update or manually? If so, when, and was the system rebooted afterwards?
Is this the first dietpi-update run since the Trixie upgrade?

Could you please also post the output of the following commands?

systemctl is-system-running
systemctl status dbus --no-pager
dpkg --audit
dpkg -l | grep -E 'dbus|systemd'
apt-get -s autoremove
cat /etc/apt/sources.list /etc/apt/sources.list.d/*
ls -l /var/log/apt/

And the complete log of the failed run: the one shown at the end of dietpi-update, ideally also /var/tmp/dietpi/logs/dietpi-update.log (if it exists) and /var/log/apt/term.log. In the excerpt, the package listed under “automatically installed and is no longer required” is missing, so please include that. It could be a dbus-* package. Also, jellyfin is kept back, which probably comes from a third-party APT repository that still points to Bookworm.

Before retrying, please do not run apt autoremove.

MichaIng · 11 October 2026 12:28

PHP does not require D-Bus. These calls seem to be coming from the DEB helper commands, but I have never seen them throwing errors like this.

It is possible that the D-Bus errors are just a symptom for something else. What really caused the failure was the php8.4-fpm.service restart attempt, not the failing helpers themselves.

But I assume systemd itself is not really running or accessible, which is why the helpers attempt to invoke D-Bus in the first place.

So systemctl is-system-running is already a good test, also plain systemctl. And:

journalctl -u php8.4-fpm

Possible that the systemctl commands fail with the same D-Bus error, if systemd itself really crashed somehow.

Pi-Rate · 11 October 2026 14:26

Thanks for your answers.

Regarding your two questions:

I upgraded to Trixie already in June and it worked without problems. The system was rebooted a few times since then. I even thought it was worth a comment in the blog: Debian 13 Trixie has been released – DietPi Blog
I did one or two dietpi-update runs after the Trixie upgrade and didn’t have problems with them.

Now for the output of the commands you are asking for.

dietpi@mini14:~$ systemctl is-system-running
Failed to connect to system scope bus via local transport: No such file or directory

dietpi@mini14:~$ systemctl status dbus --no-pager
Failed to connect to system scope bus via local transport: No such file or directory

systemctl doesn’t seem to work at all anymore at this point.

dietpi@mini14:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time.  The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 php8.4-fpm           server-side, HTML-embedded scripting language (FPM-CGI bi

dietpi@mini14:~$ sudo dpkg -l | grep -E 'dbus|systemd'
ii  libdbus-1-3:amd64                1.16.2-2                             amd64        simple interprocess messaging system (library)
ii  libsystemd-shared:amd64          257.13-1~deb13u1                     amd64        systemd shared private library
ii  libsystemd0:amd64                257.13-1~deb13u1                     amd64        systemd utility library
ii  systemd                          257.13-1~deb13u1                     amd64        system and service manager
ii  systemd-sysv                     257.13-1~deb13u1                     amd64        system and service manager - SysV compatibility symlinks
ii  systemd-timesyncd                257.13-1~deb13u1                     amd64        minimalistic service to synchronize local time with NTP servers

dietpi@mini14:~$ apt-get -s autoremove
NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-image-6.12.107+deb13-amd64
0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
1 not fully installed or removed.
Remv linux-image-6.12.107+deb13-amd64 [6.12.107-1]
Conf php8.4-fpm (8.4.26-1~deb13u1 Debian-Security:13/stable-security [amd64])

dietpi@mini14:~$ cat /etc/apt/sources.list /etc/apt/sources.list.d/*
deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
deb https://deb.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ trixie-backports main contrib non-free non-free-firmware
deb https://repo.jellyfin.org/debian trixie main
deb https://repo.mosquitto.org/debian trixie main
deb https://dietpi.com/apt trixie main
deb https://download.docker.com/linux/debian trixie stable
deb http://linux-packages.resilio.com/resilio-sync/deb resilio-sync non-free

dietpi@mini14:~$ ls -l /var/log/apt/
total 76
-rw-r--r-- 1 root root 28684 Oct 11 00:13 eipp.log.xz
-rw-r--r-- 1 root root  6369 Oct 11 00:13 history.log
-rw-r----- 1 root adm  35025 Oct 11 00:13 term.log

I’m also adding the output @MichaIng asked for:

dietpi@mini14:~$ sudo journalctl -u php8.4-fpm
Oct 10 23:21:30 mini14 systemd[1]: Stopping php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager...
Oct 10 23:21:30 mini14 systemd[1]: php8.4-fpm.service: Deactivated successfully.
Oct 10 23:21:30 mini14 systemd[1]: Stopped php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager.
Oct 10 23:21:30 mini14 systemd[1]: php8.4-fpm.service: Consumed 5h 48min 3.220s CPU time, 1.6G memory peak.
Oct 10 23:42:02 mini14 systemd[1]: Starting php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager...
Oct 10 23:42:02 mini14 systemd[1]: Started php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager.

I’ve attached the /var/log/apt/term.log.

The /var/tmp/dietpi/logs/dietpi-update.log doesn’t contain any recent logs. The last entry was related to v10.4.2 from back in May this year.

I hope I didn’t miss anything you asked for.

Right now, my biggest problem with the situation is, that Home Assistant and Nextcloud are down. I hope you can assist me in finding the root cause of this to fix it.

term.log (34.2 KB)

Joulinar · 11 October 2026 16:30

Hi,

thanks for the outputs and the log. Unfortunately the systemctl commands you ran don’t tell us anything, my fault for not saying it: DietPi doesn’t install D-Bus by default, so systemctl can only talk to systemd as root (via /run/systemd/private). As a normal user it always prints Failed to connect to system scope bus via local transport: No such file or directory, on a healthy system as well. Your package list also looks normal for DietPi (only libdbus-1-3, no dbus-daemon), so there is no missing D-Bus package.

What matters is the error in the apt log, which ran as root: there it says Connection refused. That means the socket /run/systemd/private exists, but PID 1 did not answer on it. The libc6 upgrade in that run (2.41-12+deb13u3 → u4) calls systemctl daemon-reexec, which re-executes PID 1, and the first error appears at the systemd trigger after it. So one possible explanation is that PID 1 did not come back cleanly from that. But I’m not sure, your journal shows php8.4-fpm being started by systemd at 23:42:02, so PID 1 was still reacting at that time.

Nextcloud and Home Assistant are down because dietpi-update stops all services at the start (dietpi-services stop, your journal shows php8.4-fpm stopped at 23:21:30) and only starts them again after a successful run. Your data should be untouched.

Could you please run these commands with sudo?

uptime
sudo systemctl is-system-running
sudo systemctl --failed --no-pager
ps -p 1 -o pid,comm,args
ls -l /run/systemd/private
sudo journalctl --since '2026-10-10 23:15' --until '2026-10-10 23:50' --no-pager > journal.txt
ls -l /mnt/dietpi-backup

Please attach journal.txt (the time window of the failed update). The last command is to see whether a DietPi backup exists and how old it is.

If sudo systemctl is-system-running says running, systemd is working again, and you can simply continue:

sudo dpkg --configure -a
sudo apt-get -f install
sudo dietpi-update

If it fails with the same error as in the log (Connection refused) or hangs, then:

Reboot the system. If reboot does not work, use sync && reboot -f. A new kernel (6.12.111) was installed during the update anyway.
After the reboot, run the three commands above.

If the system does not come back up after the reboot, or dpkg --configure -a still fails, post the output and the result of sudo journalctl -b -p err.

Do you have a DietPi backup (ls -l /mnt/dietpi-backup, see above)? If so, a restore with sudo dietpi-backup -1 is an option to bring the system back to life, in case the steps above don’t help. I’d try the reboot first, though.

Pi-Rate · 11 October 2026 18:32

As root there’s the same problem with systemctl.

My backups are in a different folder on an external disk and just now I saw, that it hasn’t backed up since I upgraded to trixie, so that’s bad, because it’s pre-trixie, but let’s see how far I get.

journal.txt (261.3 KB)

dietpi@mini14:~$ uptime
 19:32:15 up 32 days,  4:12,  0 users,  load average: 0.09, 0.07, 0.08
dietpi@mini14:~$ sudo systemctl is-system-running
Failed to connect to system scope bus via local transport: Connection refused
dietpi@mini14:~$ sudo systemctl --failed --no-pager
Failed to connect to system scope bus via local transport: Connection refused
dietpi@mini14:~$ ps -p 1 -o pid,comm,args
    PID COMMAND         COMMAND
      1 systemd         /usr/lib/systemd/systemd --system --deserialize=46
dietpi@mini14:~$ ls -l /run/systemd/private
srwx------ 1 root root 0 Sep  9 15:40 /run/systemd/private
dietpi@mini14:~$ sudo journalctl --since '2026-10-10 23:15' --until '2026-10-10 23:50' --no-pager > journal.txt
dietpi@mini14:~$ ls -al /mnt/ext_1tb_ssd_01/dietpi-backup/
total 38740
drwxr-xr-x  6 root root     4096 Sep  9 15:11 .
drwxr-xr-x  6 root root     4096 Sep 14  2025 ..
-rw-r--r--  1 root root     1224 Sep  9 15:11 .dietpi-backup_stats
drwxr-xr-x 12 root root     4096 Feb  6  2026 data
drwxr-xr-x 12 root root     4096 Jan 10  2026 data_2
drwxr-xr-x 12 root root     4096 Jun 24 17:59 data_3
drwxr-xr-x 12 root root     4096 Jun 24 17:46 data_4
-rw-r--r--  1 root root 39634655 Jun 24 17:59 dietpi-backup.log

When I try to reboot normally:

dietpi@mini14:~$ sudo reboot
Failed to connect to system scope bus via local transport: No such file or directory
Failed to connect to system scope bus via local transport: No such file or directory
Failed to connect to system scope bus via local transport: Connection refused
Failed to open /run/initctl: No such device or address
Failed to talk to init daemon: Connection refused

With sync and force:

root@mini14:/home/dietpi# sync && reboot -f
Rebooting.

The system came back up and this is the output of the commands after the reboot:

dietpi@mini14:~$ sudo dpkg --configure -a
Setting up php8.4-fpm (8.4.26-1~deb13u1) ...
Processing triggers for php8.4-fpm (8.4.26-1~deb13u1) ...
dietpi@mini14:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-image-6.12.107+deb13-amd64
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Next I did a dietpi-update with backup first and it finished without any errors.

Now I wanted to test another reboot and got again this error, but it still rebooted and came up:

dietpi@mini14:~$ sudo reboot
Failed to connect to system scope bus via local transport: No such file or directory
Failed to connect to system scope bus via local transport: No such file or directory
Connection to mini14 closed by remote host.
Connection to mini14 closed.
client_loop: send disconnect: Broken pipe

Joulinar · 11 October 2026 19:44

what about your apps HA and NC? Both are working “again”?

Pi-Rate · 11 October 2026 20:07

Yes, also HA and NC are working again. The only thing I have to figure out is why the update of jellyfin is held back. So unless you have a suggestion for what I should still inspect to figure out the root cause of this problem, I think I’m good again.

Thanks for your quick reaction, that was very welcome and is normally not a given.

Joulinar · 11 October 2026 20:28

Hi,

glad to hear everything is running again.

Regarding Jellyfin: this is expected and not related to the failed update. Jellyfin’s jellyfin package is only a meta package, which depends on jellyfin-server, jellyfin-web and a jellyfin-ffmpeg* package. The new Jellyfin 12.x depends on jellyfin-ffmpeg8, which conflicts with (and replaces) jellyfin-ffmpeg7, which is what your current jellyfin package depends on. apt-get upgrade never removes installed packages, hence it holds back the meta package.

Looking at your journal, the Jellyfin server itself has actually already been updated by the upgrade: it reports Jellyfin version: 12.2.0 since 23:28 and ran its database migration then. So only the meta package and the ffmpeg package are left behind. Jellyfin is running, so this is not urgent.

To verify this on your system, without changing anything, please post the output of:

dpkg -l | grep jellyfin
apt-cache policy jellyfin jellyfin-server jellyfin-ffmpeg7 jellyfin-ffmpeg8
sudo apt-get -s install jellyfin

-s is only a simulation. I’d expect it to list jellyfin-ffmpeg7 as to be removed, jellyfin-ffmpeg8 as new and jellyfin as to be upgraded, and nothing else. If it looks different, please post it before doing anything.

If it matches, you can complete the upgrade with:

sudo apt-get install jellyfin

Since it is a major version jump (10.11 → 12.x), I’d do a backup first (e.g. sudo dietpi-backup, which includes /mnt/dietpi_userdata/jellyfin) and have a look at the Jellyfin release notes for 12.x before.

Joulinar · 11 October 2026 20:57

For the original issue I had a closer look at your journal.txt and I think I found the root cause. I was also able to reproduce it on two test systems. My guess a broken NFS mount.

What happened on your system:

Your journal shows an NFS server that was not reachable the whole time: nfs: server 192.168.65.43 not responding, timed out, 26 times in the 35 minutes of the log.
Every systemctl daemon-reload during the update took exactly 90 seconds and ended with Failed to fork off sandboxing environment for executing generators: Protocol error. That’s why the APT run took 20 minutes.
At 23:42:03 systemd was re-executed (daemon-reexec). This is done by the systemd package on every libc6 upgrade, visible as Processing triggers for systemd in your term.log. 90 seconds later: Freezing execution. From that moment on, systemd (PID 1) was frozen, so every systemctl call failed with Connection refused, the php8.4-fpm restart failed, and a normal reboot didn’t work anymore.

Why:
On every reload and re-exec, systemd runs its generators, with a limit of 90 seconds. One of them, systemd-fstab-generator, checks the mount point of every entry in /etc/fstab, including network mounts. If an NFS share is mounted but the server is gone, this check hangs until the 90 seconds are over. On a daemon-reload systemd only logs this and continues, but on a daemon-reexec it is fatal, and systemd freezes.

On the test systems I mounted an NFS share via /etc/fstab, made the NFS server unreachable and got exactly the same messages: the reload took 90 s with the same Protocol error, systemd-fstab-generator was stuck waiting for the NFS server, and daemon-reexec ended in Freezing execution. After that, systemctl and reboot failed in the same way as on your system, and only reboot -f helped.

So this is not a DietPi or Debian Trixie issue as such, but a dead NFS mount in /etc/fstab in combination with a systemd re-exec, which can happen on any APT upgrade of libc6 or systemd.

What I’d recommend:
Please check whether this NFS server (192.168.65.43) still exists and should still be mounted:

grep -i nfs /etc/fstab
findmnt -t nfs,nfs4

If it is not needed anymore, remove the entry from /etc/fstab and unmount it (sudo umount -l <mount point>). If it is needed, make sure the server is reachable before the next dietpi-update or apt upgrade. If such an update ever takes very long again and you see Protocol error in the journal, it is safer to make the NFS server reachable again, or unmount the share, before rebooting.

Regarding the reboot messages: the Failed to connect to system scope bus via local transport: No such file or directory line on sudo reboot is “normal” in some cases. It shows up on a healthy system as well, because DietPi doesn’t install D-Bus. Only the additional Connection refused and Failed to talk to init daemon lines indicated the frozen systemd.

MichaIng · 11 October 2026 21:46

So the issue is kinda similar to 90 seconds freeze when anything accesses the mount point of an unreachable drive or network share, with systemd.automount. The automount timeout can be reduced with an argument in /etc/fstab, IIRC, or otherwise with a systemd unit override for that mount unit. But not sure whether the same is possible for the systemd-fstab-generator. Or is it probably both the same issues, the fstab generator waiting for the automount?

There is also:

echo _sb > /proc/sysrq-trigger

which I learned about just recently. So this node accepts certain commands, s for sync, b for reboot, and the leading _ to let the kernel do both in sequence. In cases where even sync and/or poweroff fail, like in case of some rootfs access issue or something like that.