Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)

[Rod S. <rod...@ro...>]

On 07/19/2017 02:16 AM, Priebe, Sebastian wrote:
> Hello Rod,
> 
> thx for your quick reply.
> 
> To your first problem point: Many SOCs don't care about any
> partitioning during their boot process. E.g. the Freescale (NXP) SOCs
> I work with load the LBA block 2 into RAM and expect some special
> proprietary data there.

OK, thanks. I was mis-reading the code; I thought it was simply moving
the first usable sector for partitions, not moving the partition table
itself. If an SoC is stupid enough to require boot code at sector 2,
then that conflicts with the standard GPT positioning, so moving it may
be the only solution.

> Currently the gptfdisk tools always put the
> PTEs there. There is no way around that. I also don't like having
> some "hidden" data on the disk, but that’s just the way it is. I also
> don't see a way of putting bootcode in a partition for the Freescale
> case as there are no free blocks available.
> 
> I can't say anything to your other points, as I haven't looked into
> the details yet.

I'll give it some more thought. I'm now inclined to do something about
this, whether it's accepting some variant of the patch or doing
something else, liking a new option (analogous to the existing "e"
option on the experts' menu) to relocate the main partition table entries.

> ------------------------------------------------- Wir ziehen um! Ab
> dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, 86167
> Augsburg -------------------------------------------------
> 
> CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert
> Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht:
> Amtsgericht Augsburg HRA 14521 -----Ursprüngliche Nachricht----- Von:
> Rod Smith [mailto:rod...@ro...] Gesendet: Dienstag, 18.
> Juli 2017 20:24 An: gpt...@li...; Priebe,
> Sebastian <Seb...@ca...> Betreff: Re:
> [Gptfdisk-general] [PATCH] Support padding between Partition
> Header(LBA1) and Entries(LBA2)
> 
> On 07/17/2017 06:38 AM, Priebe, Sebastian wrote:
>> Hello,
>> 
>> there was a mail to this list in March 2016 with a patch adding the
>> option to change the starting LBA of the PTE (byte 72 in the GPT
>> header): 
>> https://sourceforge.net/p/gptfdisk/mailman/message/34955352/
>> 
>> Has somebody reviewed or tested that patch?
> 
> I think I missed that the first time around.
> 
>> As written in the original message this option is needed for many
>> embedded devices as many SoC vendors tends to have their
>> constraints on where to load its bootcode which may conflict with
>> the default starting LBA (2) of GPT fdisk.
>> 
>> Why has this patch not been included?
> 
> After reviewing the code, I have a number of problems with it. Most
> of these are minor, but the first is major:
> 
> * I don't understand why this is needed. Why not create a partition
> (a BIOS Boot Partition or something analogous) to hold the SoC boot
> code? By disabling the 2048-sector alignment policy, such a partition
> could easily be located starting at sector 34, which is the first
> sector that would be safe to use anyway. This strikes me as a
> superior solution compared to creating a significant chunk of the
> disk that's "in limbo" -- neither allocated to partitions or official
> GPT data structures nor available for allocation. It was the reckless
> use of such space under MBR that led to numerous conflicts between
> boot loaders and other low-level disk utilities with MBR and
> BIOS-mode booting. Encouraging something similar with GPT strikes me
> as a Bad Idea. * Creating a new "j" option on the experts' menu that
> replicates what "o" does on the main menu would create confusion. *
> The change to "o" on the main menu makes it harder to use. If this 
> functionality is really needed, that may be unavoidable -- or perhaps
> a new function could be added to adjust this setting, leaving "o"
> unaffected. * Perhaps adding "j" was done so that sgdisk's -o could
> be left to work as it always has. If so, that might be better done
> by adding an OPTIONAL parameter to -o. I'm not 100% sure that's 
> possible, though; I'd need to dig into the POPT documentation. * The
> patch included no documentation changes. I could write that myself,
> of course, but at a minimum, a description of when a non-standard
> (that is, non-0) padding size is appropriate would be helpful, since
> I'm unfamiliar with the SoC boot loaders that you say would benefit
> from such a change.
> 
> If you can make a case for why putting SoC boot loader code in a
> partition, even if that means adjust the alignment policy, won't
> work, then I'll consider this patch. If not, though, I think it's
> best to reject this patch, since I don't want to contribute to old
> BIOS/MBR problems infecting the EFI/GPT world.
> 
> If a partition will do the job, but if you don't think the BIOS Boot
> Partition is the right type code, then you can create such a GUID and
> submit a patch that adds it. (It would help if you have some
> authority in the field and can get buy-in for using that type code.)
> There might even be ways to tweak the alignment code to minimize
> problems from having a single unaligned partition on a disk, if
> that's likely to be an issue.
> 
> -- Rod Smith rod...@ro... http://www.rodsbooks.com
> 


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com