On Mon, Jul 02, 2018 at 02:40:50PM -0400, William Mills wrote:
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?
Good point.
- 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?
Both.
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.
<snip> > 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.
I suspected it wouldn't merely be academic when you started asking the questions ;-). Just wanted to check.
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.
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.
Still thinking on this one.
It feels like we might be able to simplify this down to removable media only. We don't really throw full disk images around much for fixed media any more... tools like fastboot (which reads partition tables and also has special case logic to author them) encourages partition at a time images.
If we can simplify down to removable media only then the question becomes will removable media use 4K addressing... and if it does will there already be a solution for us to copy from the non-embedded world?
Daniel.