Hi, Gerd Mühlenbruch wrote: > So, it seems to be a problem of nautilus on my computer.
wget -c still has a share in this. But currently i have no ideas how to find out what makes an incomplete nautilus download so confusing for wget. > dd if=debian-11.5.0-amd64-netinst.iso bs=1 skip=400556032 | od -c | less > >Ausgabe.txt (My proposal to pipe into the pager "less" was meant to avoid the need for redirection.) > 1177740 \0 \0 \0 E F I P A R T \0 \0 001 \0 \ > 1177760 \0 \0 \0 302 354 241 223 \0 \0 \0 \0 377 357 \v \0 \0 > 1200000 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 This is a GPT header block signature, but not aligned to a full block of 512 bytes, as GPT prescribes. The "E" of "E F I" is supposed to be at the start of the block. 24 bytes from there on we have a little-endian 8-byte number which tells the intended block address: (gdb) p 0377 + 0357 * 256 + '\v' * 256 * 256 782335 This is the address of the last 512-block of the original ISO: 782335 = 400556032 / 512 - 1 So we have a displaced copy of a GPT backup header with the proper block address which it would have in the netinst ISO. Checking this theory: dd if=debian-11.5.0-amd64-netinst.iso bs=512 skip=782335 | od -c yields 0000000 E F I P A R T \0 \0 001 \0 \ \0 \0 \0 0000020 302 354 241 223 \0 \0 \0 \0 377 357 \v \0 \0 \0 \0 \0 0000040 001 \0 \0 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 \0 \0 \0 0000060 312 357 \v \0 \0 \0 \0 \0 f 027 253 N 247 r 5 B 0000100 215 256 z 9 353 M 314 313 357 \v \0 \0 \0 \0 \0 0000120 320 \0 \0 \0 200 \0 \0 \0 1 231 o 227 \0 \0 \0 \0 0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001000 Both, the existence of the copy 327648 after the original end of the ISO and its non-alignment by -29 (or 483) bytes are hard to explain. Have a nice day :) Thomas
