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: Johan M. <joh...@gm...> - 2017-07-23 12:09:09
|
Thank you for the new version. I did a quick test and ran the new gdisk on a USB stick and put the main table at sector 64. I added a partition and created a UDF file system on it. Both Linux and Windows 7 sees it without problems. Now I can create a standard conforming full-size 128-entry partition table and still have the Allwinner SoC's ROM read what it needs starting at LBA 16. This is still, as you say, "in limbo", i.e. not on a partition, but at least not in the area reserved for partition data and not between the table and the partition data. Regarding the "braindead" SoCs: they don't have enough ROM to be able to parse partition tables, and if they did, then they would probably only support MBR partitions. So they have to make some hard-coded choice. Allwinner generously reserves 8 kB at the start of the storage device for whatever needs to be stored there, but that's not enough for GPT. On 22 July 2017 at 05:20, Rod Smith <rod...@ro...> wrote: > Hi, > > So I've done some hacking this evening, and I've submitted an initial > version of the code to enable moving the main partition table to git: > > https://sourceforge.net/p/gptfdisk/code/ci/master/tree/ > > This is git commit 503e9a. You'll need to pull down the source code and > compile it locally. The NEWS file summarizes the changes. In gdisk, the > feature is implemented via "j" on the experts' menu; in sgdisk, it's > -j/--move-main-table={sector}, where {sector} is the sector number to > which you want to move the partition table; and the ability to change > this value is not implemented in cgdisk. This seems to be working for > me, but I need to hammer away at it to find any bugs or complications > that might be lurking. I'd appreciate it if you can do so, too. Note > that the code may interact with other features. I've added some checks > to the verify code, and functions like partition table resizing, > backups, restores, etc., could all be affected, and I haven't yet > checked them to be sure they're all doing sensible things. > > One quirk I discovered is that fdisk's (util-linux fdisk's) GPT support > creates a gap between the partition table and the first usable sector. > Either before or after this patch to GPT fdisk, my program seems to > handle these disks OK, but there is one important peculiarity, which > makes me a bit wary: The gdisk "use backup GPT" feature ("b" on the > backup/recovery menu), if applied to an fdisk-created disk, moves the > partition table from sector 2 to sector 2016 (from the start to the end > of the space between the main metadata to the first usable sector). This > preserves the first-usable-sector value but shifts the location of the > gap in the GPT data structures. I don't see any way around this; each > GPT metadata structure contains a pointer only to its own partition > table, so the backup data does not provide any clue about whether the > main partition table comes at the beginning or end of a too-big > allocated area (or somewhere in the middle). The current (development) > state of the GPT fdisk code assumes the partition table will go at the > end of the allocation area since that's how the "j" function on the > experts' menu does it. > > Both fdisk and parted seemed to be able to cope with disks created with > a shifted main partition table; however, my testing with them has been > limited. I did a VERY basic test with OS X, but I have yet to test with > Windows, FreeBSD, or anything else. > > 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. > > > > 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 > |
