Re: libgparted bug.
- Date: Sun, 11 Feb 2018 18:35:54 +0100
- From: "Thomas Schmitt" <scdbackup@xxxxxxx>
- Subject: Re: libgparted bug.
Gene Heskett wrote:
> The real problem is of coarse that there has not ever been 2 identical sd
> cards made, so a dd image to the end of the card A, will not ever
> install that image on another supposedly identical card B or C, they are
> NOT the same size except in the salespersons mind. Therefore, the image
> must be constrained to a gig or so beyond the end of the used portion of
> the card. And some utility is then invoked to look at the card during
> the initial bootup, that re-expands the last partition to encompass the
> remainder of THAT card.
You could install a bumper partition 8 at the end of the card.
Whatever automat you suffer from, it would have to be extra stupid to
expand partition 7 into the range of the bumper.
Let's assume a minimum size of rounded up 16 billion with a "16 GB" medium.
Then let's subtract a coward's reserve of 100 million bytes, and divide
by the block size:
( 15.5e9 - 100e6 ) / 512 = 30078125
So if you create partition 8 starting at block 30,078,125 and reaching up
to the end of the usable block range, then the image from block 0 to the
end of partition 7 should be portable to any "16 GB" medium.
Ideally you should delete partition 8 before copying from the original
medium. So it does not confuse partition editors after the image was copied
to a new medium.
The GPT header and the backup GPT would have to be re-created with the
new medium size. Partition 8 would have to be re-created from the same
start block up to the end of the usable block range.
gdisk seems to be able to do this.
Start blocks for bumpers:
Rounded up "8 GB" - 50 MB : 14,550,781
Rounded up "16 GB" - 100 MB : 30,078,125
Rounded up "32 GB" - 200 MB : 61,132,812
Rounded up "64 GB" - 500 MB : 123,046,875
Have a nice day :)