Re: [Bug-xorriso] PMBR sizing with appended_part_as=gpt

[Thomas Schmitt]

Hi,

Paul Robins wrote:
> Do you have any preference on the features I requested?

I will try to keep them in mind when exploring the reasons of the requesting
of a protective partition in partprepend_writer_compute_data_blocks().
There must be some reason for this and i need to know it before i decide
the final bug fix.

Adding features about partitions is not easy any more. The risk of spoiling
existing use cases is substantial. (I pondered about a complete new
approach to boot equipment description. A clear and systematic language.
But real life hits me whenever i begin to make tangible plans ...)


Some conceptual assessment for a start:

> I need the ability to align the appended partition to
> a particular start position in order to ensure there is some free space for
> the contents of the ISO, EFI etc... partitions to grow.

Sounds somewhat tricky to handle on your side.

For my side it will be a challenge to create a partition table for the new
ISO which matches the old partitions which stay in place.
How shall the pre-partition padding be defined with the first ISO version
and how to re-use this definition in subsequent ISOs which might grow or
shrink ?

(First a relative offset to give the first ISO a certain wiggle room
 and later absolute partition start addresses ?
 Shall the production process of the subsequent ISO read the partition table
 of the first ISO ? Which partitions stay fixed ? Which may change ?)


> it would be useful to be able to use more
> than 4 GPT partitions, and set the type ID

For now the appended GPT partitions are just a variation of MBR partitions.
I will have to look where the restriction to 4 partitions is enforced
or presumed.


> -append_to_gpt 1-65535 guid partition-file

Well, we only have 31 KiB for the GPT entries, because the first 1024 bytes
are occupied by MBR and GPT header block and at 32 KiB begins the ISO 9660
Primary Volume Descriptor.
This means that at most 31 * 8 = 248 partition entries can be allocated.
The number shrinks substantially if APM is used, too. (The APM block size
of 2048 is part of the trick to make it combinable with GPT. But it is
also a big waste because each partition table entry occupies a block.)

So i think about 12 partitions might be possible with additional APM and
248 without any APM.


>  Thanks for your unbelievably quick response!

The further steps will take more time.


Have a nice day :)

Thomas