On 07/02/2018 02:40 PM, 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. >>> >>> 1) 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?
https://en.wikipedia.org/wiki/Advanced_Format """Since April 2014, enterprise-class 4K native hard disk drives have been available on the market.""" > I think most vendors are just publishing suggested read & write sizes > and leaving the "block size" set at 512. > > (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? > >> >>> 2) 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. > > >> >>> 3) 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. > > 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. > > Bill > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
