Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv
 

I recently had to restore a backup created by a rsync backup created by raspiBackup because my SD card died. The restore was successfull but NetworkManager didn't start :-(. With sudo journalctl -n 100 -u NetworkManager.service I detected the error message

/usr/sbin/NetworkManager: error while loading shared libraries: libhogweed.so.4: cannot open shared object file: No such file or directory

It took me a while to find the root cause of the issue. Finally it's not an issue with raspiBackup but with librtmp1 and the way it's packaged in RaspbianOS.

 

 

Root cause is librtmp.so.1 does not get a new creation date when updated and still has the same size. Therefore rsync doesn't detect the file changed and doesn't update librtmp1 in the backup. During restore an old outdated librtmp1 is restored and this creates the issue. If you compare the timestamp it's identical, even the size is identical, but the contents is different.

Restored system with old backlevel librtmp:

root@troubadix3:~# ls -la /usr/lib/arm-linux-gnueabihf/librtmp.so.1
-rw-r--r-- 1 root root 100440 May 21 2018 /usr/lib/arm-linux-gnueabihf/librtmp.so.1
root@troubadix3:~# shasum /usr/lib/arm-linux-gnueabihf/librtmp.so.1
aba5825822e83e12a33d58677f6a9e97928d64ca /usr/lib/arm-linux-gnueabihf/librtmp.so.1

Original system with correct librtmp:

root@troubadix:~ $ ls -la /usr/lib/arm-linux-gnueabihf/librtmp.so.1
-rw-r--r-- 1 root root 100440 May 21 2018 /usr/lib/arm-linux-gnueabihf/librtmp.so.1
root@troubadix:~ $ shasum /usr/lib/arm-linux-gnueabihf/librtmp.so.1
ceafd4687907362b93bb0a028b2ed7c772df44ea /usr/lib/arm-linux-gnueabihf/librtmp.so.1

 

If you know about this the fix is quite easy:

sudo dhclient eth

sudo apt reinstall librtmp1

 

You can also use option -c (checksum) with rsync. rsync then will create a checksum for each sour and target file and detect the file was updated even date and size are identical and copied into the backup.

Actually this happened for me because I had buster installed on the system and at some point in time installed a fresh bookworm. librtmp1 changed but date and size were identical so that rsync didn't copy the new librtmp1 into the backup.

This is no issue with raspiBackup. It's an issue for all backup tools which use rsync and use the standard to check only date and size to detect file updates.

Root cause of this issue is that all Debian libLMU packages don't update the date. If now the size doesn't change rsync does not detect a file was updated and will not copy the new file into the backup.

apt list --installed | grep -E "^.+\+b" 

 can be used to find all binLMU packages.

 

References

Kommentar schreiben

*** Hinweis ***

Kommentare sind erwünscht. Aber um lästige Spamposts abweisen zu können gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare mit dem Text http werden sofort zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden. zz
  2. Kommentare werden manuell überprüft und es dauert deshalb in der Regel einen Tag bis sie veröffentlicht werden.