bug-xorriso
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Robins
Subject: Re: [Bug-xorriso] PMBR sizing with appended_part_as=gpt
Date: Tue, 08 Jan 2019 16:25:55 +0000

Thomas,
There is no time pressure on my side in terms of a final fix, as I can correct the PMBR manually and mess with the partition layouts after ISO creation, so these features would just eliminate some work in my scripts.

In terms of the alignment of partitions and the recreation of ISO files, once the ISO has been written to a read-write medium I plan to use it as a 'normal' hard disk with an MBR (or GPT in this case) and update it by modifying only the pseudo ISO partition and EFI partition entries as required, and then `dd`ing the updated versions. The ultimate goal is that the boot machinery for each platform is kept as a unified blob at the start of the volume which is consistent no matter what media.

I don't mean to imply that you should write these features either, if you are happy with the conceptual design then it is up to me to implement them. For my purposes I don't require that the produced ISO should need to be updated, and I have yet to dive into that portion of the code. I will most likely be producing new ISOs with a default appended partition, which is only there if there is no existing partition on whatever is being updated.

With regards to padding, my intention was to support absolute start addresses for appended partitions only. The production mechanism I have been using is simply to build the ISO without appended partitions and add 64MiB to the last partition entry, that alone is sufficient for my needs, but I appreciate adding it as a feature requires more thorough support. I don't know how append_partition interacts with modifying ISO files so I will have to learn that first. Assuming the padding is implemented simply as a space in the GPT between the end of the HFS+ partition and the start of the appended partition, I would assume that space could be consumed in modification safely.

Thank you for the details of the limitations for GPT sizing, I did read a little about the APM overlap technique but I don't have a deep enough knowledge yet. 12 partitions will undoubtedly be fine, the specification only contains root partitions for 4 architectures I am interested in, and I can always use LVM if required as grub has support for this.

Please take as much time as you like.
Paul

On Tue, 8 Jan, 2019 at 3:55 PM, Thomas Schmitt <address@hidden> wrote:
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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]