Hi, Gerd Mühlenbruch wrote: > I started my batch by doubleclicking the file in nautilus.
Being a fvwm user i can only riddle whether this start by nautilus has something to do with the problem. But your post of 3 Oct 2022 18:28:08 +0000 says that you started the original download by wget -c. So i assume that nautilus is not significant. > I expected differences in bytes anywhere in the beginning, but comp -l and > comp -b didn't showed such result. > ==>>> cmp: EOF on debian-live-11.5.0-amd64-gnome.iso after byte 2910683136 That astonished me already with your original post. There seems to be a surplus tail appended. What's in that tail ? E.g. what do you get from dd if=Err-debian-live-11.5.0-amd64-gnome.iso bs=1 skip=2910683136 | \ od -c | less Is it all 0 ? Is some human readable text to see ? (It would be more lightweight to inspect Err*-netinst.iso, if you still have it dd if=Err-debian-11.5.0-amd64-netinst.iso bs=1 skip=400556032 | \ od -c | less ) Do you remember how large the ISOs were after their first interrupt ? Are perhaps the differences between oversize and real size the same numbers ? (I compute from your numbers: 4184168 for live and 328163 for netinst.) There are some bug reports about wget -c on https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=wget but none seems to match what you experience. > I'm using debian bullseye with gnome 3.38 and wayland. That's an ideal base for posting a bug report. > However, I can try your lines the next days. It would be better for the bug report if the problem could be reproduced with wget alone. > If you like, I could add the shell selecting in the first line "#...". It would be really odd if wget -c would behave differently depending on the shell which started wget. Have a nice day :) Thomas
