[parted-devel] Partition tables and ARM booting
Danny Milosavljevic
dannym at scratchpost.org
Sat Dec 9 05:07:09 UTC 2017
Hi,
some ARM CPUs (for example Allwinner A20, Allwinner R40 etc) put the boot block at some weird place which could happen to be right inside a GPT partition table.
There are various manual workarounds (to shrink the GPT to fewer possible entries etc), but it would be nice if parted had a built-in function to do that, if possible. After all, parted knows best just how many partition table entries fit before some (boot) sector.
A straightforward API would be something like
* gpt_max_partition_count_by_sector which would tell the user how many partition table entries fit before the given sector.
* gpt_limit_partition_count (or gpt_resize, or gpt_set_max_primary_partition_count) which would resize the partition table to support at most this many partitions.
And a minimal simple API would be
* gpt_limit_partition_count_by_sector which would do something similar to what gpt_get_max_supported_partition_count already does (!). gpt_get_max_supported_partition_count already contains the calculation needed, although the sector number is hard-coded to 34 there.
struct _PedDiskOps would have also to be extended in order to export those (just limit_partition_count_by_sector would be enough, too).
Just to be clear, it would be nice if this *especially* supported modifying an existing partition table of a disk with data on it.
What do you think?
I'm also not sure whether all the other partition table types allow storing (remembering) the number of the first sector usable for partitions. If not, this change wouldn't do much good since the user could just create a partition right over the boot block even after this change.
More information about the parted-devel
mailing list