USB3stick might do compression and deduplication internally. Older Sandforce controllers in SSD (sandisk) did that for example. I would compare files with off-device copies. Maybe you also did that. Then still Pi5 USB3 port is not the same as a port on a PC. Both have a firmware/BIOS and a Linux driver, so 4 objects that could differ.i confirmed that the vmlinuz and initrd files in /boot (ext4) matched the ones in /boot/firmware (fat32)
its highly unlikely that any corruption would hit both copies of the file in the same way
Code:
[root@amd-nixos:/mnt/boot]# md5sum vmlinuz-6.6.62+rpt-rpi-271267edebfe3ca51955dd7d4361f68d5431 vmlinuz-6.6.62+rpt-rpi-2712[root@amd-nixos:/mnt/boot]# md5sum firmware/kernel_2712.img67edebfe3ca51955dd7d4361f68d5431 firmware/kernel_2712.img[root@amd-nixos:/mnt/boot]# cat ../var/lib/dpkg/info/linux-image-6.6.62+rpt-rpi-2712.md5sums | grep 'vmlinuz-6.6.62+rpt-rpi-2712'67edebfe3ca51955dd7d4361f68d5431 boot/vmlinuz-6.6.62+rpt-rpi-2712
initrd is harder, because it gets generated dynamically, but the kernel logs should still print before it unpacks the initrd, so that cant matter
i'm just lazy with the capsThat is really weird. I would expect something about nine magnitudes faster.![]()
![]()
![]()
Maybe your "shift" key is unreliable?
Code:
[root@amd-nixos:~]# ddrescue /dev/sdd /nas/drives/pi5-128g-usb3.imgGNU ddrescue 1.23Press Ctrl-C to interrupt ipos: 124117 MB, non-trimmed: 0 B, current rate: 40566 kB/s opos: 124117 MB, non-scraped: 0 B, average rate: 74634 kB/snon-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 124117 MB, bad areas: 0, run time: 27m 42spct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/aFinished[code]that would be the speeds when i imaged the entire disk[code]Creating file 82.h2w ... 77.29% -- 2.04 MB/s -- 1:28:31
Statistics: Posted by cleverca22 — Fri Apr 04, 2025 5:26 pm