Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

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

Add comment

*** Note ***

Comments are welcome. But in order to reject spam posts please consider following rules:
  1. Comments with string http are rejected with message You have no rights to use this tag
  2. All comments are reviewed by hand and thus it usually takes one day until a comment will be published.