Chris Murphy wrote: > You don't want it supported, but you want it as an option? I don't > know what that means either. If it's there, it needs to be run by > UI/Ux folks, needs plain language clarity, needs to be translated, Yes, I understand that. Again, understand the context ... 1) _Only_ when creating a _new_ GPT disk label (wiping the disk) 2) Come up with as generic of a text as possible, e.g., "Format this new GPT disk to maximize compatibility with several non-Linux OSes" > and needs a significantly larger matrix of tests by QA/QE > than exists now for Windows installed before Fedora. Absolutely _not_. Period. The _opposite_. There is *0* guarantees because that OS installs _after_ will work. All it does is ... A) Reserve the 128MiB type 0C01h partition (msftres) as partition #2 after the ... B) >=260MiB FAT32 EF00h EFI System Partition (esp) partition #1 That's it! *0* guarantees, just "maximum compatibility." Again, I recommended 1-384MiB (383MiB) and 384-512MiB (1288MiB), respectively, using the first 0.5GiB of the disk. > I don't see on what basis this option goes in if it's not assured > of being understandable and working. Just because most IT people are ignorant GPT doesn't mean it's not ideal. I.e., a lot of people think the type 0C01h partition is "optional" and "not used" for GPT when running Windows x64. That's hardly the case. It's also the order Microsoft has, and continues, to recommend. > If it's not proven to work, why have it in there? What are you talking about?! This has been Microsoft _own_ recommendations since original NT6.0 Vista x64 release, and continues through today for _all_ x64 releases. The 0C01h (msftres) partition _removes_ the need for hidden sectors and other crap. It's there for a reason. At most they've changed the "minimum" FAT32 ESP recommendation, and now they are starting to recommend larger because 4KiB sectors requires at least 260MiB -- something that has nothing to do with the OS, but the FAT32 file system itself. We've only avoided it to date because most OSes implement "logical" sector size separate from "physical." So ... I was recommending we honor > And proving that it works will take a ton of effort compared to the > current way of doing it which expects Windows first. > The other factor is that the vast majority of OEM Windows installers > are not Microsoft installers. Microsoft's will install to free space. > The OEM installers typically don't. They obliterate the target drive > in its entirety in favor of a fixed layout that can't be modified by > the user at all. Obviously you haven't heard a word I said. Of course OEMs pre-install Windows, and then people install Linux after. That's _not_ who I'm attempting to address. I'm talking about professionals, corporations and others who install their own OSes, the ones with Microsoft and Red Hat Enterprise agreements, as well as enthusiasts at home or in development enviroments. Last time I checked, that's a lot of workstations, as many do _not_ come pre-installed. We're talking a lot of the higher-end systems here. I'm not talking Jane or Joe user who does it the way you said. I already and purposely pre-create GPT disk labels for this reason, and I'm _not_ the only one. We create a disk label with maximum compatibility, ensuring we avoid issues. > It's convincing that the ESP needs to use 4KiB clusters to support 4kn > drives. But I'm unconvinced any UEFI spec mandates that the ESP needs > to be FAT32. So ... why not give the user the option of FAT32 without confusing them? "Format this new GPT disk to maximize compatibility with several non-Linux OSes" We don't have to go into all the asterisks and nooks'n cranies. One checkbox makes ... A) FAT32 ESP of at least 260MiB B) Reserves the 128MiB type 0C01h partition Done. One option, so many potential issues avoided for a *new* ... again ... *new* GPT disk label. > It's suggested that this ought to be true but the > language I've seen so far doesn't say it must be true. And I'm trying to get you to understand that this is a very, very valid option for people who _wipe_ their disks and create a _new_ GPT disk label. Something we can do in Anaconda. > So either mkdosfs needs a special flag to do the logic ensuring on > 4kn drives it uses 4/8KiB clusters, or some component within the > installer needs to pass mkdosfs that option, otherwise obviously the > system will not boot. Again, I thought the "way forward" was to look at this was to address several "realities" of modern uEFI (w/o CSM) multi-booting. That includes looking at the fact that it goes beyond just the ESP too. One checkbox, so many issues avoided ... But _only_ when the installer is creating a _new_ GPT disk label. -- bjs P.S. Please, please understand that I'm just trying to avoid a lot of issues that many people run into, with a simple checkbox when someone installs Linux on a new or wiped disk (not an existing one). -- 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
