Hi all,
Seems to be a bit of a reoccurring issue with my DietPi setup. Every month or so I will slowly start to get errors with my DietPi setup, which don’t know if it is related to what I have running on it or not.
The current Dietpi is a RPi 4 Model B (aarch64) running v7.2.3 with the following programs:
PiHole
qBittorrent
Lidarr
Sonarr
Radarr
Jackett
and when I log into it through PuTTY, I get the following error in the console
- Device model : RPi 4 Model B (aarch64)
- CPU temp : 36'C : 96'F (Cool runnings)
- LAN IP : 192.168.1.102 (eth0)
curl: error while loading shared libraries: /usr/lib/aarch64-linux-gnu/libk5cryp to.so.3: invalid ELF header
At the same time, it seems the suite of arr programs all stop working and have the following issues:
Lidarr - on the home page shows “database disk image is malformed database disk image is malformed”
Sonarr - doesn’t load anymore
Radarr - on the home page shows “Structure needs cleaning”
I don’t know if I’m putting 2 + 2 = 5, but when this has happened previously, I’ve always ended up rebuilding it as seems the quicker option (I’m not a linux guy). Last time it happened I switched to a different memory card on the off chance the existing one was slowly dying.
Any help would be appreciated 
It seems to me that something is wrong with the filesystem. Have you run a fsck on boot to check the root filesystem? I hope you are not storing whatever is you are downloading on the SD.
Just tried doing a fsck as you suggested and got the following:
root@DietPi:~# fsck
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
/dev/mmcblk0p2 is mounted.
e2fsck: Cannot continue, aborting.
As for storage, no, everything is kept on a NAS drive 
fsck can be executed on unmounted deviced only. Means you would need a 2nd linux box to be able to carry these out. As well you need to check bootFS than rootFS. In theory it will looks like this, where sda would need to be replaced with the device name your SD card will get on these 2nd linux box
dosfsck /dev/sda1 #vfat partition
fsck -a /dev/sda2 #ext4 partition
Anyway you would do following to perform some basic check
> /forcefsck
reboot
# then after reboot
journalctl -t systemd-fsck
I ran the bit you mentioned here and it has come back with:
-- Logs begin at Thu 2019-02-14 10:11:58 GMT, end at Tue 2021-06-22 13:30:14 BST. --
Jun 22 12:19:55 DietPi systemd-fsck[134]: e2fsck 1.44.5 (15-Dec-2018)
Jun 22 12:19:55 DietPi systemd-fsck[134]: Superblock last mount time is in the future.
Jun 22 12:19:55 DietPi systemd-fsck[134]: (by less than a day, probably due to the hardware clock bei
ng incorrectly set)
Jun 22 12:19:55 DietPi systemd-fsck[134]: rootfs: clean, 44930/3771392 files, 1264319/15201280 blocks
Jun 22 12:19:56 DietPi systemd-fsck[253]: fsck.fat 4.1 (2017-01-24)
Jun 22 12:19:56 DietPi systemd-fsck[253]: /dev/mmcblk0p1: 316 files, 63481/516190 clusters
How does the file look like?
ls -l /usr/lib/aarch64-linux-gnu/libk5crypto.so.3
stat /usr/lib/aarch64-linux-gnu/libk5crypto.so.3
Result of the commands is:
root@DietPi:~# ls -l /usr/lib/aarch64-linux-gnu/libk5crypto.so.3
lrwxrwxrwx 1 root root 18 Nov 19 2020 /usr/lib/aarch64-linux-gnu/libk5crypto.so.3 -> libk5crypto.so.3.1
root@DietPi:~# stat /usr/lib/aarch64-linux-gnu/libk5crypto.so.3
File: /usr/lib/aarch64-linux-gnu/libk5crypto.so.3 -> libk5crypto.so.3.1
Size: 18 Blocks: 0 IO Block: 4096 symbolic link
Device: b302h/45826d Inode: 2013 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-01-21 21:45:57.000000000 +0000
Modify: 2020-11-19 16:42:57.000000000 +0000
Change: 2021-01-21 21:46:25.390878418 +0000
Birth: -
Let’s try to reinstall the library:
apt install --reinstall libk5crypto3
Sorry for the delay in responding on this, but due to other constraints I ended up reflashing the memory card with a fresh image, then restored from backup.