Re: libgparted bug.
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
Reply to: