Required Information
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=12
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='applied'
- Distro version: bullseye
- Kernel version: Linux DietPi 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
- SBC model: Native PC (x86_64)
Additional Information (if applicable)
- Software title: Jellyfin
- Was the software title installed freshly or updated/migrated? Installed with DietPi, regularly updated automatically
- Can this issue be replicated on a fresh installation of DietPi? No idea
Steps to reproduce
- Start computer
- Jellyfin service will not start, spitting out:
Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 547: elf_machine_rela_relative: Assertion ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE’ failed!`
- Jellyfin won’t start either using
dietpi-services to restart it
Expected behaviour
- Jellyfin should start automatically at boot, or when using
dietpi=services
Actual behaviour
Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 547: elf_machine_rela_relative: Assertion 'ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!
Extra details
Here’s the result of journalctl -u jellyfin.service:
Jan 14 00:44:07 DietPi systemd[1]: Started Jellyfin Media Server.
Jan 14 00:44:07 DietPi jellyfin[1240]: Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 547: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!
Jan 14 00:44:07 DietPi systemd[1]: jellyfin.service: Main process exited, code=exited, status=127/n/a
Jan 14 00:44:07 DietPi systemd[1]: jellyfin.service: Failed with result 'exit-code'.
Furthermore, the HDD light is sometimes lit up “solid white”, as if HDD was working at 100%. Used to happen once per day while Bazaar service was running, but happens about once per week after I disabled it. No idea what’s causing this, but I can’t SSH to the PC, I can’t use any web UI, so no way to see in the logs what’s happening since all I can do at this point is to hit the power switch and restart. Then when restarting, logs are empty. I set a cronjob to restart every morning at 6am so at least if it freezes up I could still connect and “try” to find the problem after (I never did).
However earlier today my server was working, then the solid HDD light was on so I hit the power switch and after that I could not connect to Jellyfin anymore (all other services work), so maybe something got corrupted?
Did you try to reinstall Jellyfin?
dietpi-software reinstall 178
Did you check kernel error messages?
dmesg -l err,crit,alert,emerg
Try to setup persist system logs:
dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall
Then you can check system logs via:
journalctl
which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:
mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_
This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.
Hay! Was away for the weekend but thanks for your super useful answer as usual! That amazing trick to make logs persist… I will definitely be able to use that to identify why the HDD is hanging 
Will reinstall Jellyfin like this make me lose all the settings? Or it’s a special way of re-installing that saves everything?
dietpi-software reinstall 178
The output of dmesg -l err,crit,alert,emerg returned a bunch of errors. I feel those are due to when I tried to use Hardware aceleration several weeks ago but never managed to make it work:
root@DietPi: ~# dmesg -l err,crit,alert,emerg
[ 3.519762] kvm: disabled by bios
[ 3.541944] [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or later requires firmware installed
[ 3.542709] See https://wiki.debian.org/Firmware for information about missing firmware
[ 3.570916] kvm: disabled by bios
[ 3.646506] kvm: disabled by bios
[ 3.879539] kvm: disabled by bios
However I didn’t have any issues with that for several weeks without touching anything. I still uninstalled those packages to make sure:
apt autoremove mesa-va-drivers
apt autoremove lshw
Then I rebooted but no luck
usually we aim to keep configurations on reinstall.
Thanks for the confirmation. I also tried to do a backup earlier but it failed. Don’t know if it’s related, as some jellyfin files are broken or something.
Anyways, reinstalled, still have the same issue, maybe some settings are causing an issue, but I didn’t change anything in Jellyfin for a while. So my other guess is that some files got corrupted the last time I had to cut the power when it was unresponsive.
in worst case, try to remove Jellyfin, reboot system and install fresh version of Jellyfin.
I thought about it, but then I lose everything. So I’ll keep searching before I use the nuclear option 
Better to loose app settings instead of not able to use it?
I found out with debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u that the file /usr/lib/jellyfin/bin/System.Private.Xml.dll was unreadable, had an I/O error when trying to copy it, while other files alongside it could copy just fine (with root permissions). So I guess it was corrupted like I suspected. I manage to forc-delete it, hoping I could run dietpi-software reinstall 178 again to reinstall Jellyfin but still not working. Now I’m getting:
root@DietPi: ~# debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u
debsums: missing file /usr/share/icons/hicolor/scalable/apps/htop.svg (from htop package)
debsums: missing file /usr/lib/jellyfin/bin/System.Private.Xml.dll (from jellyfin-server package)
And:
root@DietPi: ~# debsums -e | grep FAILED
debsums: missing file /etc/apt/apt.conf.d/01autoremove (from apt package)
/etc/bash.bashrc FAILED
debsums: missing file /etc/init.d/deluged (from deluged package)
debsums: missing file /etc/default/deluged (from deluged package)
/etc/crontab FAILED
/etc/hdparm.conf FAILED
/etc/default/jellyfin FAILED
/etc/systemd/timesyncd.conf FAILED
(That missing htop file warning was there before too, no idea why)
So I guess the “reinstall” function doesn’t copy back all files, maybe something’s not working. Just need that one missing file now, if anyone could send it to me. Tried to download Jellyfin server their 10.8.8 release but I cannot find that dll file anywhere. Even the Windows version doesn’t have it.
EDIT: Oh yeah I forgot to say I’m afraid of running
apt reinstall jellyfin-server
because I know Jellyfin has custom user names, paths, etc so I don’t want to mess anything up.
Jellyfin is installed from apt package source, means on a reinstall we will not force the package installation again if already present.
This, indeed, would need to be done manually using:
apt install --reinstall jellyfin
Do a backup of your system before and perform a restorte if needed.
Forgot to update in case anyone has the same issue or has their Jellyfin completely busted. None of what I tried worked so I endend up making a backup of the whole system via the Dietpi backup system, and completely uninstalled Jellyfin.
Then I reinstalled, forcing all the broken files to be refreshed (it drives me crazy how apt --reinstall doesn’t actually reinstall all the binaries and libraries, feels a bit stupid).
After that, I stopped the Jellyfin service (IMPORTANT I THINK), deleted all the folders containing settings or userdata and recopied the ones from my backup with the same permissions and ownerships via the command rsync:
rm -rf /mnt/dietpi_userdata/jellyfin/
rm -rf /etc/jellyfin/
rm -rf /usr/share/jellyfin/
rsync -ravht --progress /mnt/backup-location/data/mnt/dietpi_userdata/jellyfin/ /mnt/dietpi_userdata/jellyfin/
rsync -ravht --progress /mnt/backup-location/data/etc/jellyfin/ /etc/jellyfin/
rsync -ravht --progress /mnt/backup-location/data/usr/share/jellyfin/ /usr/share/jellyfin/
1 Like
what a pity that apt did not reinstalled all needed files.