Bug 236323 - [mkimg] Allow specifying (minimum) partition table size where applicable
Summary: [mkimg] Allow specifying (minimum) partition table size where applicable
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Marcel Moolenaar
Depends on:
Reported: 2019-03-06 15:40 UTC by Marcel Moolenaar
Modified: 2019-03-06 15:41 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Moolenaar freebsd_committer 2019-03-06 15:40:55 UTC
By default, mkimg(1) creates a disk image that uses a partition table size that is large enough to hold the partitions given to mkimg(1). Rounding of the number of partition entries, as implemented for bin/236238, is possible where it makes sense but does not structurally provide a way to make sure there are free partitions.

Arguably, the -p option can be used to add a few empty partitions, but in the GPT case this gets painful if the user really desires a GPT partition table that has the default number of partition entries in it. The default number is 128, requiring 128 -p options, of which more than 100 are for padding purposes only.

The APM scheme has a similar problem in that each partition entry is in its own sector. Once the disk image has be created and the first sector of the first partition is adjacent to the last sector of the partition table, no more partitions can be added.

And that's fundamentally the point of this bug: provide a way to make sure that either
1) the number of entries can be specified, or
2) the number of extra entries can be specified.

It's not clear which approach works better as a generic solution given that it won't apply to some schemes like MBR.