On Sun, Jul 01, 2018 at 10:37:49AM -0400, William Mills wrote:
All,
I rely on your greater knowledge to help me understand these questions. Thanks in advance.
- GPT and block size 1A) By querying the device 1B) Some MBR magic?
There's some comments in the fdisk man page that recent Linux kernels "just knows" the sector size and the code to work with GPT partitions in the kernel (block/partitions/efi.c ) will error out of MyLBA does not match the LBA the kernel thinks it is. This means that (unless there' s some fallback code at a layer above the partition parsing code) then if you copy a GPT to a disk with a different sector size it will be broken.
Not sure that matters much though: if you want to fix it up you would arrange for the fixup logic to be part of your initramfs.
- Can GPT be grown?
If the backup table is not found at the end of the disk then Linux will log in the dmesg trace that the partition table is damaged but I think will use it nevertheless.
Tools like fdisk are typically "uneasy" when why cannot find the backup GPT header and will offer recreate it if you let then. IIRC it basically marks the partition table dirty regardless of whether you have changed it or not (so that it will get updated if you write-and-exit).
- Is it actually required that the partition array start at LBA2?
I don't think so, although you'd probably have to author it (or modify a template) by hand.
Assuming the code to validate the primary and backup partition tables is shared (e.g. properly decomposed into functions) the code will naturally end up honouring PartitionEntryLBA.
BTW this last question made me realize that:
a) one of the boards we've always believed to have a boot ROM that mandated MBR might just have a workaround
b) I might have overlooked something in the EBBR text about protective partitioning (a.k.a. is it OK to place the system firmware outside the FirstUsableLBA).
Daniel.
PS Is this merely of academic (or vendor) interest or are you cooking up some crazy addendum for EBBR?