On Thu, Oct 15, 2015 at 1:18 PM, Máirín Duffy <duffy@xxxxxxxxxx> wrote: > > > On 10/15/2015 02:58 PM, Chris Murphy wrote: >> >> To be fair - many of the users who are ignorant of bootloader blocks >> are also ignorant of why they'd want to go beyond the default FS / >> partition layout choices and wouldn't end up in custom partitioning >> anyway. >> >> >> I see no such correlation. I routinely see users who only have ever used >> custom partitioning (not just Anaconda, but other distro installers as >> well) > > > You can't really compare our install setup to other distros at this point. > It's too different. > > The body of people installing their own distros today is also not the same > body of people who are generally ignorant of bootloader blocks (that > population is much, much larger) and it is also not where Fedora can (or > should) grow as a distribution given a mission to spread software freedom. > (If you've already got it, it's not getting spread if you use it.) > > There are *plenty* of people using the installer who don't use the custom > partitioning feature, and they are blissfully ignorant of bootloader blocks > and many other technical details I think the user population you're thinking > of are quite aware of. I'm not comparing installation setups among distros. I'm questioning the assertion that users ignorant of bootloader esoterics are somehow less likely to use custom partitioning. I see sufficient evidence to the contrary. The desire for a user to have a separate /var volume, a larger / volume than default, or an /opt volume, is completely orthogonal to bootloader knowledge. As a matter of where to spend limited resources, you'll get no argument from me that it should be in making the automatic path as bulletproof as possible. > >> have no idea what firmware their computer has, why that matters, >> how it affects what partition scheme is used, what partitions are >> created, the fact that grub2-install no longer applies, myriad changes >> that are thrust upon the user as a result of not so much the UEFI spec >> but because of this very weird (to me) installer idea that users need to >> see all partitions just because that's they way it's always been. >> >> And by so doing, they are now getting into trouble in ways they never >> previously got into trouble. And in ways they don't get into trouble >> with other OS partitioning tools that don't show them the whole story. > > > It's just a new way to get into trouble. There's tons of other ways to get > into trouble in any partition editing scenario that would remain if we hid > ESPs, but because they've been there longer they're harder to get rid of and > their removal would most certainly piss populations of users off. I think it's a new old way to get into trouble. Since it's not a user serviceable part, don't point it out. Old axiom. > > (see > https://fedoraproject.org/wiki/User:Duffy/FundamentalTheoremOfDevelopingFLOSS > #1 and #5 particularly) Ok I'll be one of the last people to encourage these things as theories or axioms. They might be humorously true, but they're bad behaviors to coddle in users as if there's some entitlement to old boogers we've finally flicked off. Angry users have much difficulty explaining their use case in relation to how UI inhibits arrival at their goal, yet somehow they have no end of solutions for the problem, those being pretty much always terrible even when the use case is legitimate. > If a user doesn't want to see all the partitions - they shouldn't use the > custom partitioning tool. Oh I'm not saying the user doesn't want to see all. I'm saying they either don't know what they want, or what they want is flawed. There is no obligation to show them all just because it's custom partitioning - this is provable by the existence of two custom partitioning GUI tools used by millions of users that do not show ESPs, always creates them at the time the drive is GPT partitioned just in case something needs an ESP on that drive one day. And the user complaints they can't see these hidden partitions? It's zero. Meanwhile in just the redhat bugzilla, and the Fedora users lists and forums, there are nearly a dozen bugs and must be hundreds of emails demonstrating sufficient problems and confusion directly from showing BIOSboot and ESP to users. > If they want to work with partitions but don't > like how anaconda displays them, they certainly have the knowledge and > capability to use a 3rd party partitioning tool to do exactly what they > want. Remember that anaconda's primary directive here is to install the > operating system, not to be a general purpose partition manager. Ok but this is my argument. If they want to see all partitions, CLI tools do that now. There is literally no advantage, and yet Exhibits A, B, C, D, and so on, disadvantages to showing users these bootloader partitions. That will not change. They will not get better at this over time. >> This issue does not affect custom partitioning with MBR gaps either. >> That is, it doesn't happen on BIOS+MBR systems. The user cannot delete >> the Windows bootloader even in custom partitioning on such systems. They >> literally can't get into trouble. > > > Actually they can, and I have in the past. They could overwrite the MBR. I > believe part of the redesign involved making that no longer possible, but > for many years it was possible to wipe out your ability to boot windows. a. I'm not arguing what can or could happen. I'm arguing what does and does not happen. On UEFI the problem always happens when following the reproduce steps. On BIOS the problem never happens when following the reproduce steps. b. On BIOS installations the Windows bootloader is on the Windows system volume, so unless the user obliterates that system volume, they aren't actually deleting the Windows bootloader because it's not on a shared volume. c. The jump code in the MBR is always overwritten in proper dual boot installations because we need to jump to GRUB instead of jumping to the Windows bootloader. This is normal, expected, and overwhelmingly it works correctly. When it doesn't, it's an edge case or a bug. What's completely new here is the user needs to know that the ESP specifically contains the Windows bootloader, and deleting that partition will render Windows unbootable. And that should not be prerequisite knowledge to avoid nerfing Windows bootability while using custom partitioning. Really. > >> Replicate that behavior, is what I'm suggesting, rather than falling >> into this trap of showing partitions for the sake of showing partitions, >> when doing so does not aid user success. > > > I think we need a lot more info/research into how that might affect folks > before we can safely do something like that. 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! How much more research is necessary to know that not showing ESPs is not a problem? > I agree in principle generally > with what you're suggesting, but the devil is certainly in the details. > Aren't MBRs are a lot smaller on disk than ESPs?; MBR gap is now 1 MiB. But so is BIOSBoot yet that is shown. And neither MBR gaps nor BIOSBoot are mountable, yet one is shown and the other isn't. There really is a totally specious attachment to showing the actual partition table in the GUI is all I can't discern here. Not that it's actually useful information or a good idea. 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. > if there isn't an ability > to evaluate space taken up by ESPs and offer their management as an option > in custom part, would we (for random potentially stupid example) be hurting > some embedded users with very limited storage capacity? This isn't a simple > change and needs to be considered a bit more deeply. 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. > >> The consequence of showing them such things is that we're effectively >> telling users for the first time in free software OS installer history >> they need to understand how Windows boots. They never had to understand >> the Windows bootloader esoterics before, > > > Again, they absolutely had to. Your last sentence there is absolutely > untrue. I have had to manually set up a bootloader to access a Windows > install I unwittingly rendered unbootable via a Linux multiboot installation > before. Multiple times. Multiple distros. 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. 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. > >> but now they do, in order to >> avoid trouble in custom partitioning. And that's not a ding on just >> Anaconda, all the other distributions do this too by exposing these >> bootloader structures to the user. And confusion ensues. > > > This all affects folks in multi-boot scenarios, which are the majority case > nor really should they be. In 2015 this is an extremely limited user > population we're talking about here: an edge case. 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. -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
