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

[Priebe, S. <Seb...@ca...>]

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. 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.

Greetings,
Sebastian



-------------------------------------------------
              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