Alternate location for GPT partition entry table

Question

The GPT header (usually in LBA 1) has a PartitionEntryLBA field (see 5.3.2 GPT Header in the spec). There is language in various references (such as the wikipedia GPT entry) describing that field that says it should point to LBA 2.

The spec says "The primary GPT Partition Entry Array must be located after the primary GPT Header and end before the First Usable LBA."

In that context there seems to be some wiggle room associated with "after". That doesn't necessarily mean immediately after - the first partition entry could be some number of LBAs after the header and still meet that guidance in the spec.

I am using an embedded processor that looks for a 4k vector table at the second sector of a storage card (e.g., SD). So I can't put the GPT partition entries there. So I'd like to write GPT partition entries after that table (5k byte offset assuming 512 byte sectors). I think this is reasonable, but haven't looked at any standard GPT partitioning tools (e.g., parted on linux) to see if / how that might be supported. Nor whether standard boot loaders (e.g., u-boot) will be able to find a partition entry table at such a location.

So I'm interested in hearing about practical experience with atypical GPT partition entry table locations (i.e., not at LBA 2 for the primary copy of the table) with various partitioning tools and boot loaders. Preference toward bsd/linux, but I'm interested in hearing about other environments as well (even anecdotes about certain commercial operating systems).

That's a bit of an open-ended inquiry. Worded somewhat more specifically, are there any known failure cases with atypical GPT partition entry table locations and existing partitioning tools and/or boot loaders?

You can get to the UEFI specs here: http://www.uefi.org/specifications. I was looking at the latest (revision 2.4, errata C).

I do not yet have a membership in UEFI (http://www.uefi.org/join), so I don't have access to the forum there (http://www.uefi.org/FWOSForum).

p.s. There seems to be an even stronger requirement (?) that the primary GPT header be at LBA 1 even though there's a StartingLBA field in the PMBR (at LBA 0). The spec does specifically spell out that the StartingLBA field there should be LBA 1. But why bother having the field if it must be at LBA 1? Why not allow the GPT header to be at LBA 10 if a situation calls for it? This isn't necessary in my current use case and the questions are somewhat rhetorical in this forum (probably better posed in the official UEFI forums).

Answer 1

I could have sworn I'd seen something like this in some hybrid ISO images (the sort used for Linux distributions so that they can be burned to a CD-R or written to a USB flash drive without post-processing); however, I just checked a few and they don't seem to be doing this. Maybe I'm not remembering correctly, or maybe I've just not checked the right ones. I also don't see anything about this in the isohybrid man page -- but I'm not sure this is what's most commonly used to create these images. Still, you might want to follow this lead further than I did....

FWIW, I'm the author of GPT fdisk. It's been quite a while since I've had to touch the relevant code, but a quick review suggests that GPT fdisk should read a disk in which the primary partition table does not begin at LBA 2; however, GPT fdisk does not support changing this location, and I can't promise it would save the table back at the original location even if it could successfully read such a disk. You might be able to hack it to start that table elsewhere for experimentation purposes. In fact, I just gave that a try, but there are a number of places in the code that use hard-coded "1" or "2" values to populate the LBA values, and I didn't find them all in my initial attempt, so I ended up writing the header into the middle of the partition table, which of course was not pretty. If you want to try, look at the gpt.cc file. Start by looking for where partitionEntriesLBA and firstUsableLBA are set -- but some of the relevant constants are in function calls, too.

As to the location of the primary GPT header, I doubt if you could change that. The protective MBR isn't really part of the GPT data structures per se; its purpose is to identify the disk as a GPT disk and to keep GPT-unaware tools from mucking with the disk, not to identify where GPT data structures begin. The StartingLBA field there exists because it's part of the MBR data structure, not because GPT uses it for anything. I suppose it's possible that some tools might use the start point of the MBR protective partition as a pointer to the primary header, but I doubt if a majority would do that. Certainly GPT fdisk doesn't; it hard-codes LBA 1 as the location of the primary header.

If you have more questions about this, you might want to post on the edk2-devel mailing list. Lots of EFI developers hang out there, and it's possible that some of them know of precedents for what you're trying to do, or know of alternative ways to accomplish your goal.