I can't reproduce on my RPi4 or helios64. I will need to try on my RPi5 when I get a chance. I will look at the commands in the backup script again but I think there is something wrong with the zstd package in the arm64 debian repo. Someone will need to file a bug report for that.
[Backup Plugin] dd full disk backup failed - zstd: error while loading shared libraries
-
- OMV 7.x
- FDanee
-
-
That makes sense to me—thank you! I'll wander over there and will file a report if there isn't one already. Thanks again!
-
Here's a copy of the bug report I just filed w/ Debian.
Package: zstd
Version: 1.5.4+dfsg2-5
Followup-For: Bug #1034012
Dear Maintainer,
I am running a clean install of Raspian OS on a Raspberry Pi 5 w/ 8 GB RAM on a 32 GB microSD w/ OMV 7.
When I run the backup plugin, it calls dd and zstd to create a compressed image of the entire drive.
Right now, the compressed image is around 800 MB, so less than 1:32 compression ratio.
zstd runs correctly only ONCE---but somehow breaks itself and/or liblz4-1, such that the backup
will not run (segmentation faults or finds corrupted libraries). When I reinstall those packages,
the backupu (zstd) will gain run correctly ONCE, but breaks itself again.
I checked the brand-new microSD with f3, and it has 0.00 errors.
I did a clean install of the entire system again, but the problem repeats itself.
I upgraded to zstd 1.5.6 testing to see if the bug had been fixed there, but the same problem occurs.
I have not tried the unstable branch.
Thank you very much!
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 12.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 6.6.47+rpt-rpi-2712 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages zstd depends on:
ii libc6 2.36-9+rpt2+deb12u8
ii libgcc-s1 12.2.0-14
ii liblz4-1 1.9.4-1
ii liblzma5 5.4.1-0.2
ii libstdc++6 12.2.0-14
ii zlib1g 1:1.2.13.dfsg-1
zstd recommends no packages.
zstd suggests no packages.
-- no debconf information
-
-
I actually just tested the "unstable" version, and it APPEARS that the bug has been fixed there (zstd 1.5.6+dfsg-1).
-
Well, I rebooted and ... the same bug returned. So ... on my system, the bug has NOT been fixed, even in the unstable branch.
-
Same here, after a omv-regen i had the same problem, reinstalled zstd and it worked.
sudo apt-get reinstall zstd
Also after reboot need to reinstall it again.... weird
-
-
I wrote a new image and configured OMV7 on my RPi5. I just tried the backup four times with a reboot between each one. Not one failure and I didn't have to reinstall.
-
FDanee
Hat das Label gelöst entfernt. -
Do you get the error with the following command as root (not sudo):
zstd -T0 --fast -o /mnt/test.ddfull1.zst < /dev/mmcblk0p1
zstd -T0 -o /mnt/test.ddfull2.zst < /dev/mmcblk0p1
zstd --fast -o /mnt/test.ddfull3.zst < /dev/mmcblk0p1
zstd -o /mnt/test.ddfull4.zst < /dev/mmcblk0p1
-
-
Do you get the error with the following command as root (not sudo):
I tried these while zstd was in a "bad" state, I am getting segfaults on all four:
Code
Alles anzeigenroot@valer:/home/fdanee# zstd -T0 --fast -o /mnt/test.ddfull1.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x555617c4a778] Segmentation fault root@valer:/home/fdanee# zstd -T0 -o /mnt/test.ddfull2.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x5555d0a7a778] Segmentation fault root@valer:/home/fdanee# zstd --fast -o /mnt/test.ddfull3.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x555646e2a778] Segmentation fault root@valer:/home/fdanee# zstd -o /mnt/test.ddfull4.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a7d0) [0x55560b62a7d0] zstd(+0x123ac) [0x55560b5c23ac] zstd(+0x2086c) [0x55560b5d086c] zstd(+0x23c58) [0x55560b5d3c58] zstd(+0x24b10) [0x55560b5d4b10] zstd(+0x8e394) [0x55560b63e394] zstd(+0x8abc) [0x55560b5b8abc] /lib/aarch64-linux-gnu/libc.so.6(+0x7ee30) [0x7fff987bee30] /lib/aarch64-linux-gnu/libc.so.6(+0xe7adc) [0x7fff98827adc] Segmentation fault -
That tells me that the problem isn't a specific option that the plugin is using with zstd.
Does this segfault?
zstd -o /mnt/test.ddfull5.zst -1 < /dev/mmcblk0p1
If it does, then what is the output of:
strace zstd -o /mnt/test.ddfull6.zst < /dev/mmcblk0p1
-
Does this segfault?
zstd -o /mnt/test.ddfull5.zst -1 < /dev/mmcblk0p1
It does not:
Coderoot@valer:/home/fdanee# zstd -o /mnt/test.ddfull5.zst -1 < /dev/mmcblk0p1 /*stdin*\ : 11.78% ( 512 MiB => 60.3 MiB, /mnt/test.ddfull5.zst) root@valer:/home/fdanee# -
-
It does not:
but the other commands are still segfaulting?
-
but the other commands are still segfaulting?
No, they are not, all of them completed fine. Also, I was able to do three dd full disk backups one after another via the web UI (earlier it always failed after one.)
Recap of this last leg of testing:
1. Commands segfaulting:
Code
Alles anzeigenroot@valer:/home/fdanee# zstd -T0 --fast -o /mnt/test.ddfull1.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x555617c4a778] Segmentation fault root@valer:/home/fdanee# zstd -T0 -o /mnt/test.ddfull2.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x5555d0a7a778] Segmentation fault root@valer:/home/fdanee# zstd --fast -o /mnt/test.ddfull3.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a778) [0x555646e2a778] Segmentation fault root@valer:/home/fdanee# zstd -o /mnt/test.ddfull4.zst < /dev/mmcblk0p1 Read: 0 B ==> 0%Caught SIGSEGV signal, printing stack: zstd(+0x7a7d0) [0x55560b62a7d0] zstd(+0x123ac) [0x55560b5c23ac] zstd(+0x2086c) [0x55560b5d086c] zstd(+0x23c58) [0x55560b5d3c58] zstd(+0x24b10) [0x55560b5d4b10] zstd(+0x8e394) [0x55560b63e394] zstd(+0x8abc) [0x55560b5b8abc] /lib/aarch64-linux-gnu/libc.so.6(+0x7ee30) [0x7fff987bee30] /lib/aarch64-linux-gnu/libc.so.6(+0xe7adc) [0x7fff98827adc] Segmentation fault2. The Pi was restarted.
3. No segfaults on any of these
zstd -o /mnt/test.ddfull5.zst -1 < /dev/mmcblk0p1
zstd -T0 --fast -o /mnt/test.ddfull1.zst < /dev/mmcblk0p1
zstd -T0 -o /mnt/test.ddfull2.zst < /dev/mmcblk0p1
zstd --fast -o /mnt/test.ddfull3.zst < /dev/mmcblk0p1
zstd -o /mnt/test.ddfull4.zst < /dev/mmcblk0p1
4. 3 successful dd full disk backups via web UI.
-
I can't explain this behavior. It would be very interesting to see an strace when the command(s) did segfault. I still haven't been able to get my RPi5 to segfault.
-
-
My system is looking for actual libs. I have no idea why your system is looking for what seem to be template file names.
Code
Alles anzeigenaccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=31199, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 31199, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fff4cdd8000 close(3) = 0 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=133520, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 262560, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff4cd6c000 mmap(0x7fff4cd70000, 197024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fff4cd70000 munmap(0x7fff4cd6c000, 16384) = 0 munmap(0x7fff4cda4000, 33184) = 0 mprotect(0x7fff4cd8c000, 65536, PROT_NONE) = 0 mmap(0x7fff4cd9c000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7fff4cd9c000 close(3) = 0 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=198584, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 327696, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff4cd1c000 mmap(0x7fff4cd20000, 262160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fff4cd20000 munmap(0x7fff4cd1c000, 16384) = 0 munmap(0x7fff4cd64000, 32784) = 0 mprotect(0x7fff4cd4c000, 65536, PROT_NONE) = 0 mmap(0x7fff4cd5c000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7fff4cd5c000 close(3) = 0 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/liblz4.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=199056, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 328176, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff4cccc000 mmap(0x7fff4ccd0000, 262640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fff4ccd0000 munmap(0x7fff4cccc000, 16384) = 0 munmap(0x7fff4cd14000, 33264) = 0 mprotect(0x7fff4ccf4000, 98304, PROT_NONE) = 0 mmap(0x7fff4cd0c000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7fff4cd0c000 close(3) = 0 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 -
update: actually the automatic schedule seems to work correctly and complete backup w/o issues
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!