Hi, i proposed (poking with a long stick in the fog): > > dd if=/dev/sdd bs=512 skip=16500703 count=66 \ > > of=rock-img-shrunk.img seek=16500703
Gene Heskett wrote: > Which was an instant return claiming 66 blocks had been copied. Yeah. Fast. But sufficient only if i did not miscalculate again. The full copy with 131072 chunks of 64 KiB from fully unmounted /dev/sdd* would be the safer variant. > gdisk is still fussing. > gene@coyote:~/rock64.imgs$ gdisk -l rock-img-shrunk.img > 7 262144 16500735 7.7 GiB 8300 root But at least we seem to have defaced the backup GPT which caused the gdisk refusal after gdisk itself wrote it to that place. The file size of rock-img-shrunk.img should now be 8,448,393,728 bytes. If so, then it should be safe to let gdisk fix the problems which it detected in the partition tables. But as said, this is of interest mainly on the final storage device, where the backup GPT is a good protection against mishaps by clumsy partition editors. > All three of these cards will boot the rock64, but two snags. > [...] > Oh, and 3. it did not autoresize part7 during the boot, so I am assuming > a need to touch a file to make that happen again. Should the booted system do that ? Did i miss you mentioning this ? Googling "rock64": The power of a 10 year old workstation in the size of a credit card. Zero noise, i hope. > Many Thanks, Thomas Schmitt. Give your wife a big hug from little Thomas from germany. Have a nice day :) Thomas