Chris Murphy wrote: > Well, mkdosfs defaults to FAT16 and 4K cluster size on a 200M > partition, so that should continue to work, even though the UEFI spec > says to use FAT32 on system partitions. So chances are doing nothing > isn't going to break anything. Understood. And I've even verified at least the Windows 7 installer seems to use a FAT16 just fine, while Windows 8 will still boot from it (didn't try installing to one with Windows 8). I haven't had much time with Windows 10. > In practice, both Windows and OS X use FAT32, but they also use > cluster sizes smaller than 4K. Presumably both of them will transition > to 256+M EFI system partitions, rather than use FAT16. My apologies if I wasn't clear (I should have used the term "sector") ... A storage device, of 4KiB [logical] _sector_ (correcting my prior, inappropriate use of "block") _forces_ a 4KiB+ block/cluster size, so 260MiB now becomes the minimum FAT32. We're now seeing some systems where new Windows 10 systems use 4KiB logical sector size. > https://bugzilla.redhat.com/show_bug.cgi?id=1046577 > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ > and maybe > https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html Okay, I see you there. Thanx for pointing this out! ;) > Ideally there'd be an -E flag for mkdosfs to deal with this. Indeed, that would take it out of the hands of Anaconda et al., and put it in the tool. That way the tool can be changed, and everything downstream using it modified. > The UEFI spec says firmware is expected to support FAT32, FAT16, > and FAT12 so it probably doesn't matter that the spec also says the > system partition (non-removable) should be FAT32, where only > removables get FAT16 or FAT12. The other thing -E would make > possible is ensuring the proper invariant "EFI file system" is what's > actually being created, rather than pure FAT. I like Garrett's comments. ;) If there is a spec that says one thing for one, another thing for another, we might run into a case of such implementation, and suddenly an uEFI implementation that doesn't like FAT16 for an ESP. Murphy's Law. How Anaconda deals with this possible issue, I don't know. But given today's disk sizes, and how 4KiB physical is common, while 512B logical only remains because BOOTMGR was ignorant originally (let alone NTLDR has always been), I'm not sure we're doing the right thing, long-term. -- bjs <off-topic> In any case, and I don't expect Anaconda to be the place where this "greater issue" ever gets addressed ... But with Windows x64 version 7, 8 and 10 OEM guides recommending the #1 and #2 partitions to be the ESP + Reserved partitions (ignoring the separate "Tools" partition in 8 and 10), I've pretty much solved it by using the first 0.5GiB as follows ... 1 - 384MiB (383MiB), EF00h, EFI System Partition (esp) 384 - 512MiB (128MiB), 0C01h, Microsoft Reserved (msftres) With regards to the ESP, using an 383MiB (starting at 1MiB, sector 2048 for 512B, 256 for 4KiB) solves the problem altogether. There shouldn't ever be any issue. I can also load up a shell, tools and other things, which would be cool for a distro to offer (assuming they can be distributed. I'm even partial to rEFInd, which I'd love to see a distro ship as an option, because it solves so many multi-boot issues, but that's another story. With regards to the MS Reserved, if I do a Google research, everyone keeps assuming the 2nd is unused, yet I've done some hexdumps and found bytes _do_ go in there, especially if Windows is installed on the same system (still trying to find a case where just reading the disk in Windows does similarly). I'd also love to see the option to create this as the #2 partition in a new GPT disk label, in an installer, if the system is also going to be multibooting with Windows x64. But again, I understand this is really outside the realm of Anaconda. </off-topic> -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
