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-21 13:20:12
|
On 07/21/2017 03:08 AM, Johan Myréen wrote: > In summary: we all seem to agree that creating a partition for the data > read by the SoC ROM is a good idea. What we need in this case is a > layout that looks like this: Protective MBR+GPT Header - 1st partition - > Partition Entry Table - Rest of the partitions. No, I don't think that's even legal, since the GPT spec ASSUMES a single uninterrupted range of sectors in which partitions reside. Having one partition before the partition table and a bunch more after it would violate this assumption. I suppose you could hack something together that would look like that, but I shudder to think of what random partitioning tools would do with it. For SoCs that require boot code at sector 2, what's needed is: 1. Protective MBR (1 sector; position cannot change) 2. GPT header (1 sector; position cannot change) 3. Area reserved for boot loader (normally used by partition table) 4. Partition table 5. Area reserved for partitions 6. Backup GPT data structures (end of disk; not an issue here) My previous message was to the effect that reserving extra space between the partition table (4 in the above) and the reserved area for partitions (5 in the above) is pointless and could lead to abuses, since the space would be reserved by the partition table structures but not officially allocated for anything. That could easily lead to contention by different developers who think "ooh, neat, I can use this space for X," and who then overwrite something stored there by another tool created by a developer who thought "ooh, neat, I can use this space for Y." Furthermore, even if gdisk preserves these settings, there's no guarantee that another tool will do so; some other partitioning tool might change the start location of the first partition back to just after the partition table, thus enabling partitions to be created there. In sum, padding THAT area (4-5) just creates the potential for problems. If you need to put something there for some reason, I don't see why creating a regular partition shouldn't be sufficient. If you just want to push out the official point where partitions can begin, you could do it by increasing 3 in the above list, once that feature is implemented; the effect would be the same. If an SoC is hard-coded to read boot loader code from sector 2, then that's another matter; that's what 3 in the preceding list is for. gdisk does not currently support this, but that's what the proposed patch does. I have other problems with the patch, outlined earlier, so my inclination is to implement this in another way (namely, create the partition table as it's done now, but have an experts' menu item that moves the partition table). That's not to say this is a good idea in an abstract sense; IMHO, anything that's hard-coded to boot by reading a fixed sector number these days is pretty brain-dead. The need to support this in tools like gdisk means that some people who don't need this feature will dig a great big hole and fall into it; but if you're stuck with a brain-dead SoC that's hard-coded to read its boot code from sector 2, then you really do need this feature. This is analogous to hybrid MBRs, which are similarly non-standard but that provide needed functionality for some cases. People create hybrid MBRs when they don't need to, thus causing problems for themselves; but Macs need hybrid MBRs to dual-boot with BIOS-mode OSes. I'll look into implementing this soon -- conceivably this weekend, but I can make no promises about that. > On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>> wrote: > > Hello Rod, > > I agree with you that this can cause confusion. But there are hard > restrictions by the SOCs and the GPT concept provides all mechanisms > to do what it needed. So, why not let the user of gptfdisk configure > it? You can put all this stuff in the experts section and leave the > "normal" user with the defaults. > > I was thinking of you objections: is it possible to put a partitions > at LBA 2? That's what I need to do. With the possibility to move the > PTEs itself (e.g. to LBA 512), it should be possible to put a > partition infront of the PTEs, right? > > Nevertheless, the option to put the PTEs to a configurable LBA (not > 2) is very needed. > > 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... > <mailto:rod...@ro...>] > Gesendet: Donnerstag, 20. Juli 2017 19:52 > An: Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>>; > gpt...@li... > <mailto:gpt...@li...> > Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > 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... > <mailto:joh...@gm...>] > > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > > *An:* gpt...@li... > <mailto: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...> > > <mailto: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...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>>] Gesendet: Dienstag, 18. > > > Juli 2017 20:24 An: gpt...@li... > <mailto:gpt...@li...> > > <mailto:gpt...@li... > <mailto:gpt...@li...>>; Priebe, > > > Sebastian <Seb...@ca... > <mailto:Seb...@ca...> > > <mailto: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/ > <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...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>> http://www.rodsbooks.com > > > > > > > > > -- > > Rod Smith > > rod...@ro... <mailto:rod...@ro...> > <mailto: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...> > > <mailto:Gpt...@li... > <mailto:Gpt...@li...>> > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > > > > > -- > 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 > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > ------------------------------------------------------------------------------ > 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... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
