On 02.07.18 20:40, William Mills wrote:
On 07/02/2018 12:15 PM, Daniel Thompson wrote:
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.
I'm not sure we have seen 4K block devices much in the wild yet have we? I think most vendors are just publishing suggested read & write sizes and leaving the "block size" set at 512.
FWIW most (all?) hard drive vendors went back to 512 logical, 4k physical. But let me CC Hannes to confirm this.
(I don't really know why the LBA size needs to change in the first place. Is 16,777,216 TB not enough for a few years? Drives already publish enough info for OS'es not to dumb things.)
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.
Yes, initramfs would be a good place to fix this. But it means firmware must deal with it. We can make U-boot handle this but what does tianocore do?
This is pretty much how we do all our images today. It works in both Tianocore and U-Boot. We also do resize the image on first boot to the actual target disk size inside initramfs. Works like a charm.
- 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).
fdisk is uneasy if it can't find it via AlternateLBA or is uneasy if that is not the end of the disk?
Yesterday I did find language in the UEFI spec (5.3.2 GPT Header) that talks about what happens when a volume grows so it is an expected case. (They were talking about RAID disks but the same principle applies.)
The wording is a bit strange in the spec. It says its up to platform policy whether it automatically restores the primary GPT with out asking the user but then says it should ask the user. If is not clear if they are talking about the UEFI firmware, the OS during normal boot, or a disk tool like fdisk.
- 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?
I don't think this is academic at all. If the size of LBA is going to start changing on devices we see in the field, we should understand the consequences.
From what I can tell it's not going to change any time soon. Even my
shiny NVMe shows up as 512 byte sector size.
The only case where I'm not sure which direction we'll see things moving are NV-DIMMs. There running with PAGE_SIZE == LBA size seems intuitive.
The instructions for boards today are to use dd or Win32DiskWriter. This works if your writing to a USB stick, an SD Card, a hard disk, or an SSD. It works if the image provider is suppling a whole hard disk like image or an iso.
The instructions for most OS's even for x86 is to download the .iso and dd it to a USB stick. (Actually using a CD/DVD does take extra software).
If dd works for the legacy boot methods but EBBR compliance requires a special USB writer, then I would assume everyone would just stay with the legacy stuff.
Perhaps it will only be SSDs that change the LBA size or perhaps no one will. However, I think I did see wording in the eMMC spec about the block size changing in the future. Does that mean SD will change also?
Even if the block size changes will the OS layers hide it? The real sector size on CDs is 2048 but linux reports 512 to me.
That's because the iso9660 driver in Linux (and U-Boot) simply ignores the actual sector size ;).
I am still trying to figure out if a real issue exists or will soon exist. If this issue is real, I think it should be addressed in UEFI but if not there then in EBBR. We move "disks" around a lot more than other people do.
Yes, let's double check with Hannes :).
Alex