# Dietpi Update from 10.6.2 to 10.7.2 fails (trixie)
**URL:** https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522
**Category:** Troubleshooting
**Created:** [10 October 2026 22:27 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522 "2026-10-10T22:27:53Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [10 October 2026 22:27 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/1 "2026-10-10T22:27:53Z")
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
1. 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.
````auto
```
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)
```
````
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [11 October 2026 10:37 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/2 "2026-10-11T10:37:01Z")
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:
1. 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?
2. Is this the first `dietpi-update` run since the Trixie upgrade?
Could you please also post the output of the following commands?
```auto
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`.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [11 October 2026 12:28 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/3 "2026-10-11T12:28:22Z")
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:
```sh
journalctl -u php8.4-fpm
```
Possible that the `systemctl` commands fail with the same D-Bus error, if systemd itself really crashed somehow.
---
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [11 October 2026 14:26 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/4 "2026-10-11T14:26:37Z")
Thanks for your answers.
Regarding your two questions:
1. 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](https://dietpi.com/blog/?p=4014#comment-6232)
2. 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.
```auto
dietpi@mini14:~$ systemctl is-system-running
Failed to connect to system scope bus via local transport: No such file or directory
```
```auto
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.
```auto
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 or the configure menu option in dselect:
php8.4-fpm server-side, HTML-embedded scripting language (FPM-CGI bi
```
```auto
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
```
```auto
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])
```
```auto
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
```
```auto
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:
```auto
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](https://dietpi.com/forum/uploads/short-url/2S6YtiAyIGRpEpQeauugtG7sxCo.log) (34.2 KB)
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [11 October 2026 16:30 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/5 "2026-10-11T16:30:30Z")
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`?**
```auto
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:
```auto
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:
1. Reboot the system. If `reboot` does not work, use `sync && reboot -f`. A new kernel (6.12.111) was installed during the update anyway.
2. 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.
---
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [11 October 2026 18:32 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/6 "2026-10-11T18:32:08Z")
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](https://dietpi.com/forum/uploads/short-url/8Wr7PGncVdZdiGaZpK7neJdwfV1.txt) (261.3 KB)
```auto
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:
```auto
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:
```auto
root@mini14:/home/dietpi# sync && reboot -f
Rebooting.
```
The system came back up and this is the output of the commands after the reboot:
```auto
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:
```auto
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
```
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [11 October 2026 19:44 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/7 "2026-10-11T19:44:06Z")
what about your apps HA and NC? Both are working “again”?
---
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [11 October 2026 20:07 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/8 "2026-10-11T20:07:24Z")
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.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [11 October 2026 20:28 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/9 "2026-10-11T20:28:18Z")
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:
```auto
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:
```auto
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.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [11 October 2026 20:57 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/10 "2026-10-11T20:57:51Z")
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:**
1. 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.
2. 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.
3. 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:
```auto
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 `). 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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [11 October 2026 21:46 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/11 "2026-10-11T21:46:56Z")
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?
> [@Pi-Rate](#):
>
> With sync and force:
>
> ```ruby
> root@mini14:/home/dietpi# sync && reboot -f
> Rebooting.
>
> ```
>
> The system came back up and this is the output of the commands after the reboot:
There is also:
```auto
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.
---
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [12 October 2026 05:46 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/12 "2026-10-12T05:46:05Z")
I wasn’t aware that jellyfin is a meta package. You were absolutely right about everything and I’ll plan the upgrade for a different time, it’s not urgent.
```auto
dietpi@mini14:~$ dpkg -l | grep jellyfin
ii jellyfin 10.11.11+deb13 all Jellyfin is the Free Software Media System.
ii jellyfin-ffmpeg7 7.1.4-3-trixie amd64 Tools for transcoding, streaming and playing of multimedia files
ii jellyfin-server 12.2+deb13 amd64 Jellyfin is the Free Software Media System.
ii jellyfin-web 12.2+deb13 all Jellyfin is the Free Software Media System.
dietpi@mini14:~$ apt-cache policy jellyfin jellyfin-server jellyfin-ffmpeg7 jellyfin-ffmpeg8
jellyfin:
Installed: 10.11.11+deb13
Candidate: 12.2+deb13
Version table:
12.2+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
12.1+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
12.0+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
*** 10.11.11+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
100 /var/lib/dpkg/status
10.11.10+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.9+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.8+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.7+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.6+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.5+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.4+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.3+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.2+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.1+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.0+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.10.7+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
jellyfin-server:
Installed: 12.2+deb13
Candidate: 12.2+deb13
Version table:
*** 12.2+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
100 /var/lib/dpkg/status
12.1+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
12.0+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.11+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.10+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.9+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.8+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.7+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.6+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.5+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.4+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.3+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.2+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.1+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.11.0+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
10.10.7+deb13 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
jellyfin-ffmpeg7:
Installed: 7.1.4-3-trixie
Candidate: 7.1.4-3-trixie
Version table:
*** 7.1.4-3-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
100 /var/lib/dpkg/status
7.1.4-2-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.4-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.3-6-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.3-5-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.3-4-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.3-3-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.3-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.2-4-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.2-3-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.2-2-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.2-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.1-7-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
7.1.1-6-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
jellyfin-ffmpeg8:
Installed: (none)
Candidate: 8.1.3-1-trixie
Version table:
8.1.3-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.2-5-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.2-4-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.2-3-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.2-2-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.2-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.1-4-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.1-3-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.1-2-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
8.1.1-1-trixie 500
500 https://repo.jellyfin.org/debian trixie/main amd64 Packages
dietpi@mini14:~$ sudo apt-get -s install jellyfin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
jellyfin-ffmpeg8
Suggested packages:
intel-opencl-icd intel-opencl-icd-legacy
The following packages will be REMOVED:
jellyfin-ffmpeg7
The following NEW packages will be installed:
jellyfin-ffmpeg8
The following packages will be upgraded:
jellyfin
1 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Inst jellyfin [10.11.11+deb13] (12.2+deb13 Jellyfin:repo.jellyfin.org [all]) []
Remv jellyfin-ffmpeg7 [7.1.4-3-trixie] []
Inst jellyfin-ffmpeg8 (8.1.3-1-trixie Jellyfin:repo.jellyfin.org [amd64])
Conf jellyfin (12.2+deb13 Jellyfin:repo.jellyfin.org [all])
Conf jellyfin-ffmpeg8 (8.1.3-1-trixie Jellyfin:repo.jellyfin.org [amd64])
```
---
### Author:  [@Pi-Rate](https://dietpi.com/forum/u/Pi-Rate)
#### Post date: [12 October 2026 05:53 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/13 "2026-10-12T05:53:15Z")
Your observation matches my setup. I have a NAS share on which I store files that are served by jellyfin. It’s mounted with nfs on the DietPi system. The NAS runs only during the day.
When I started the dietpi-update the NAS was already powered off, but the mount was still there, stale.
Isn’t there a way to mount and umount automatically depending on the availability of the remote share via automount?
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [12 October 2026 11:27 UTC](https://dietpi.com/forum/t/dietpi-update-from-10-6-2-to-10-7-2-fails-trixie/25522/14 "2026-10-12T11:27:07Z")
@Pi-Rate thanks for confirming. We are looking into options to prevent this when the NAS is switched off. I’ll come back to you once we know what works best.
@MichaIng regarding your question and the DietPi side of this, I ran some tests on two test systems: one as NFS server via `dietpi-software install 109`, one as client with the share added via `dietpi-drive_manager`. The server was made unreachable while the share was mounted, then I waited until the NFS attribute cache expired.
Generator vs. automount: The fstab generator does not wait for the automount itself. As long as the automount was not triggered, `daemon-reload` stays fast (0.3 s) with the server down. It only hangs if the NFS share is actually mounted: `systemd-fstab-generator` canonicalizes every fstab mount point via `chase()`, also for network mounts, and blocks in an NFS GETATTR. After 90 s the generator sandbox is killed (`Failed to fork off sandboxing environment for executing generators: Protocol error`). On `daemon-reload` this is ignored, on `daemon-reexec` it is fatal: `Freezing execution`. The re-exec comes from the systemd package’s `libc-upgrade` trigger, so from Debian, not from DietPi.
Drive manager NFS mounts:
| State | `daemon-reload` | `daemon-reexec` |
| --- | --- | --- |
| Right after adding the share in drive manager | 90 s | – |
| After reboot, automount not triggered | 0.3 s | – |
| After reboot, share accessed once | 90 s | Freezing execution |
- The drive manager mounts the share directly with `mount` and only then writes `noauto,x-systemd.automount` to fstab. Until the next reboot it is therefore a plain hard mount, and the `.automount` unit is inactive.
- No `x-systemd.idle-timeout` is set, so once accessed, the share stays mounted forever. That is Pi-Rate’s case.
- With a dead share, `dietpi-drive_manager` itself hangs forever on start, at `ls -d /mnt/*/.` in `Init_Drives_and_Refresh`. So the tool you’d use to remove the mount can’t be opened.
- Many DietPi tools call `daemon-reload` (dietpi-services, dietpi-software, dietpi-update, etc.), and each one takes 90 s in this state.
Mitigations tested:
| Option | Result |
| --- | --- |
| `x-systemd.idle-timeout=30`, server dies while the share is idle | Unmounted after 30 s despite the dead server, reload 0.3 s |
| `idle-timeout`, but a process keeps the share busy | Not unmounted, 90 s hang |
| `umount -l` on the busy, dead share | Immediate, reload 0 s; automount stays active and re-mounts once the server is back |
| `soft,timeo=30,retrans=1` | Single access fails after 7 s, but the reload still took 78 s, just below the limit. Not reliable, and soft has write risks |
Possible improvements for the drive manager:
1. Add `x-systemd.idle-timeout=` to network mounts (NFS and probably CIFS, which I didn’t test). This covers the common case of a share that is idle when the NAS goes down.
2. After adding a share, mount it via the automount unit instead of a direct `mount`, so the state before and after a reboot is the same.
3. Prevent `Init_Drives_and_Refresh` from blocking on dead network mounts, e.g. with a timeout around the automount trigger and `df`.
For a busy share there’s no clean solution on our side; `umount -l` before switching off the NAS or before updates is the workaround. What do you think?