rsync backups may create inconsistent backups with binNMU packages on RaspbianOS Bookworm

[framps]

I backup my Raspberries once a week with rsync and keep a backup history. So I can use the rsync --link-dest option to save backup time and -space.

Recently I setup my Raspberries with the latest RaspbianOS Bookworm. The previous OS was RaspbianOS Buster. The new Bookworm backup used the old Buster backup in link-dest and all following Bookworm backups used the previous Bookworm backups.

Then the SD card on one of my Raspberries died and I restored the latest rsync backup. The restored backup didn't boot. I got /usr/sbin/NetworkManager: error while loading shared libraries: libhogweed.so.4: cannot open shared object file: No such file or directory and it took me a while to find the root cause for this error message:

ldd $(which NetworkManager) | grep rtmp
	librtmp.so.1 => /lib/aarch64-linux-gnu/librtmp.so.1

NetworkManager uses the librtmp shared library. librtmp is a binNMU library. When I compared the date and sha of the shared library on a Raspberry I also upgraded but didn't have to restore the backup

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

with the restored OS

[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

I detected the size of librtmp is identical and also the modification date, Therefore the default algorithm of rsync doesn't update librtmp in the backup and the restored OS Bookworm still used the old librtmp of Buster and caused the NetworkManager issue.

I opened a thread in the Raspberry Pi Forum and the question was whether this is a Debian issue or RaspberryOS issue. I installed Debian12 and Debian12Testing on an x86 system and checked whether a the modification was changed. It was.

Debian Bookworm:

root@Debian12:~$  TZ=UTC stat /usr/lib/x86_64-linux-gnu/librtmp*
  File: /usr/lib/x86_64-linux-gnu/librtmp.so.1
  Size: 122280    	Blocks: 240        IO Block: 4096   regular file
Device: 8,1	Inode: 413353      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-09-26 14:56:57.173554763 +0000
Modify: 2020-07-15 22:27:10.000000000 +0000
Change: 2024-09-26 14:52:53.145545856 +0000
 Birth: 2024-09-26 14:52:53.137545855 +0000

Debian testing

root@Debian12Testing:~$ TZ=UTC stat /usr/lib/x86_64-linux-gnu/librtmp*
  File: /usr/lib/x86_64-linux-gnu/librtmp.so.1
  Size: 122256    	Blocks: 240        IO Block: 4096   regular file
Device: 8,1	Inode: 1081490     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-09-26 15:37:28.083559420 +0000
Modify: 2024-04-07 21:02:10.000000000 +0000
Change: 2024-09-26 15:36:59.384220448 +0000
 Birth: 2024-09-26 15:36:59.376220905 +0000

So it's fixed on Debian to create a new modification date when a new librtmp is built but it's not done on RaspbianOS.