Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)
Brought to you by:
srs5694
Menu
▾
▴
Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)
|
From: Rod S. <rod...@ro...> - 2017-07-20 17:52:31
|
On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > That is another good point. > > I would love the possibility to configure the start sector of the first > partition located at offset 40 in the GPT header independently of the > number of partitions. > > Currently it is calculated from the number of partitions. Why? This gets back to my first objection, when I misunderstood the point of the patch. If you're just blocking off space between the first partition table and the first partition, then a partition is the appropriate way to reserve that space. Using a partition makes it plain that the space is in use and can provide some clue (through the partition type code and/or description) of what its purpose is. Rendering a set of blocks unusable by normal partitions and useless to GPT itself just invites confusion and conflicts in how it might be used. > *Von:*Johan Myréen [mailto:joh...@gm...] > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > *An:* gpt...@li... > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > > > For the record: when booting from an SD card, the ROM in Allwinner SoCs > loads 32 kB of code starting at 8 kB. This makes it possible to use a > shorter, non-standard partition table, but of course it would be nicer > to be able to avoid hacks like this. > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > <mailto:rod...@ro...>> wrote: > > 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. > > > > > > CADCON > Ingenieurgesellschaft mbH & Co. KG > Geschaeftsfuehrer: Robert Bauer > Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: Amtsgericht Augsburg HRA 14521 > > ------------------------------------------------- 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... > <mailto:rod...@ro...>] Gesendet: Dienstag, 18. > > Juli 2017 20:24 An: gpt...@li... > <mailto:gpt...@li...>; Priebe, > > Sebastian <Seb...@ca... > <mailto: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... > <mailto:rod...@ro...> http://www.rodsbooks.com > > > > > -- > Rod Smith > rod...@ro... <mailto:rod...@ro...> > http://www.rodsbooks.com > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > <mailto:Gpt...@li...> > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
