Been following this thread for while, and want to interject a couple of considerations ... Chris Murphy wrote: > What's the problem with just extrapolating from Apple's Disk Utility, > and the Windows Explorer? That's how you partition and format drives > on respective OS's, and neither of them show ESPs, ever. OS X for > over a decade. No one complains about what they can't see! I cannot speak to OS X, but I think some are giving the NT 6.1 (7/2008) and 6.2 (8/2012) installers way too much credit. In fact, they will even sometimes create a 2nd ESP and Creator help you if you have a 2nd drive with another ESP. Windows' Pre-Installation Environment (WinPE) gets mighty confused at times, and I've seen a case where it differed with the uEFI firmware target (not fun to clean up with the partition IDs and all). It drives me bonkers when I end up with more than one ESP too. [A] > How much more research is necessary to know that not showing ESPs > is not a problem? I've long had a default stance that ... - Don't overload the user with information - Offer the option to see more information, plus ... - Always display that information if it's pertinent before something negative could happen. E.g., and I'll let those more familiar with the Anaconda code decide if this is feasible and useful, or not ... - When an ESP is detected, show a warning icon (e.g., like red "exclamation" or maybe a red "stop hand" or something better than those suggestions) - Display the extra information if the user clicks that icon - Display the information when the user attempts to delete the ESP The extra information would be ... - Notification that this is an EFI System Partition (ESP) required to boot most (if not all) operating systems - List the first 2 levels of the tree in the ESP, which is typically ./EFI/ plus its subdirectories (e.g., fedora, Microsoft, refind, shell, ubuntu on my triple boot using rEFInd plus EFI shell option). - A reference to a man page, URL or other information if they wish to learn more [B] This would also solve the case where there is more than one ESP (especially if one is bare). The user could "see" which ESP might be the one used for the current implementation, or if both are possibly in use. > ESPs have a range in practice. Microsoft OEMs have been creating > them 100MB. Apple did for a while. Now they're in the 200-250MB > realm for most everyone. Those are Microsoft's OEM recommendations. [799232] [824839] Originally they were 200MiB in NT6.0 (Vista). They shrunk them to 100MiB with NT6.1+ (7+/2008+), but there can be newer cases in NT6.2+Update (8.1+SP/2012R2+SP) and NT10 where they are 260MiB because of support for 4KiB logical. [A] > I agree I'm being x86_64 centric. > If we'd hurt embedded users by hiding the ESP in custom, we're also > hurting them with the wrong default in automatic. So their respective > WG or SIG needs to do the necessary customization to make sure the > ESP size default is set for that arch, I'm pretty sure that's possible > now. As I mentioned, Microsoft expects (although doesn't require) FAT32, and FAT32 must be a minimum of 260MiB for 4KiB logical. Even though most of the world is still 512B logical, even for 4KiB physical, because 4KiB logical booting wasn't supported prior to NT6.2+Update (8.1+SP/2012R2+SP). So we might want to start considering a default, "recommended" size, which the user can override. > I honestly have no idea what you're talking about. I've only done > several hundred Fedora installations after Windows XP, Vista, 8 and 10 > and in every case Fedora did the right thing, except when it didn't > and in every case it didn't it was a legitimate bug. So no the user > doesn't have to know about chainloading and where the Windows > bootloader is located - Windows users don't even know that stuff. Fedora's Anaconda is definitely the best out there right now, and I've tested a lot of Windows + Ubuntu, Debian and Debian-based combinations. > You're apparently talking about something that breaks and *then* you > have to know esoterics. I'm saying now with this current behavior and > bug under discussion you need to know esoterics to avoid breaking > Windows, that's how easy it is to break it. Agreed. But I still would recommend we take care to avoid the most common issues, and stick with minimums that accommodate current and any known future issues. > I agree with that. I've asked the Desktop WG if they want to be more > permissive with dual boot and that's a no. There were multiboot (3+) > discussions in QA a while back and that was soundly rejected as > nuttastic, and the user is on their own. It's just too > non-deterministic to support actual multiboot vs dual. If people are running more than one Linux and one Windows, it gets to be problematic in general. I mean, even the EFI string used by efibootmgr gets to be messy in Windows, with Windows overwriting any existing that matches too. The user needs to be very experienced with firmware-boot aspects and it's something we cannot easily accommodate automagically. However, we can give them information, and more helpful, references to more information. -- bjs DISCLAIMER: I speak for no entities I work on-behalf, am employed or currently assigned to. I just share my general experiences based on those engagements and related testing. o References: [799232] TechNet Article 799232 - Understanding Disk Partitions (NT6.1 - Windows 7/2008) - https://technet.microsoft.com/en-us/library/dd799232.aspx [824839] TechNet Article 824839 - Configure UEFI/GPT-Based Hard Drive Partitions (NT6.1 - Windows 8/2012) - https://technet.microsoft.com/en-us/library/hh824839.aspx o Notes: [A] This is why I always pre-create at least a 260MiB FAT32 near the beginning (or to start) the disk, per [799232] [824839]. Again, Windows expects FAT32, and 4KiB logical requires at least 260MiB for FAT32, which will becoming more commonplace, not just 4KiB physical w/ 512B logical. This is not only for uEFI/GPT, but also for BIOS/MBR because Windows will use the latter as its "System" drive under BIOS too. It just solves a lot of WinPE detection-usage issues in general. To go one step further, I actually use the first 0.5GiB of the disk for ... - 1MiB reserved (MBR or GPT header, respectively) - 383MiB for ESP (EF00h, GPT-only) - 128MiB for MSFTRES (0C01h, GPT-only) If there was a way to also put in a note about or reference to the MSFTRES partition, that would be nice too. But ultimately that's something that should already be there, if they've installed Windows first. Despite common rhetoric, the MSFTRES _does_ get used, and _avoids_ the need for unpartitioned, "hidden" sector usage, like Microsoft would commonly pull on BIOS/MBR disks. [B] This is similar to the "header" (follows) I asked to be added by Anaconda to /etc/fstab in releases over the last half-decade, when I had customers complaining about switching to UUID and other references they didn't understand. References to additional info never hurts, and can fit in a single line (or two). # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info -- Bryan J Smith - http://www.linkedin.com/in/bjsmith _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
