New UEFI guide on the wiki

Chris Murphy lists at colorremedies.com
Tue Feb 4 21:45:14 UTC 2014


On Feb 4, 2014, at 12:30 PM, Adam Williamson <awilliam at redhat.com> wrote:

> On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote:
>> On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski <luto at mit.edu> wrote:
>>> 
>>> This reminds me: I *always* install with a GPT partition table, an ESP
>>> partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4
>>> /boot near the beginning of the disk.  All Linuxes seem perfectly
>>> happy to install this way (assuming you can figure out how to
>>> partition the disk like that in the first place) and booting that way
>>> in BIOS or EFI mode.  Given that this wastes at most a few MB, should
>>> anaconda just partition like that by default?
>> 
>> RFE: always create required bootloader partitions in custom partitioning
>> https://bugzilla.redhat.com/show_bug.cgi?id=1022316
>> 
>> I'm not opposed to both ESP and BIOSboot created for every selected
>> disk at install time. But I am opposed to the current behavior of not
>> creating that which is mandatory for operation, while the installer
>> then proceeds to chew me out for not having created it. It knows
>> enough to squawk at me, but it doesn't know enough to just do the
>> thing that needs to be done? Grrr that's not OK.
> 
> One's a lot harder than the other. If you have multiple disks, how do we
> know which one you want the ESP on?

All of them should. But at a minimum, each bootable disk needs one or it isn't a bootable disk, is it? So wherever /boot exists and ESP is needed. Two disk /boot on raid1? Both disk. Three disk /boot on raid5? All three disks.

Otherwise why even let the user create such a thing when it can't boot upon single disk failure? Honestly… why put in the effort to build the bridge to 90% completion and then let the cars just drop one after another into the abyss? If it's offered it should work. If it's not going to work, don't offer it.


> If the layout you created filled the
> whole disk, what do we shrink to fit the ESP in?

It's easier if the ESP size is withheld from Available Space for every selected disk, and every selected disk gets an ESP. But if worry warts don't want ESPs on certain drives well then that's more code that I won't oppose but I'll think is totally unnecessary. 


> You of all people know the consequences of adding more complexity to the
> installer's partitioning codepaths. ;)

Yeah what's complex is error checking whether an ESP is needed, and whether it's present, and the "not present" gripe code, translating into (how many languages are we supporting these days?) and testing all of that. For no good reason.

Windows and OS X? It's one size fits all. Your boot disks get an ESP. No options. On OS X actually, all GPT disks get an ESP whether they're intended for booting or not. There is no option, no visible indication at all that the disk has or will get one and no way to specify the ESP size.

No complexity and and there are no complaints in millions of users!

Do we want an ESP bigger than 200MB? Fine have that conversation if you want. Maybe it ought to be 550MB so that mkdosfs will make our ESP's conform to the UEFI spec by formatting them FAT32 instead of FAT16. And then it'd also be big enough for the fans of the ESP as $BOOT for gummiboot/bootloaderspec. I'm not opposed to it being bigger.

But it is precisely this type of hysterically unnecessary customization creep that has made Custom Partitioning the event horizon for QA testing. We will never ever test most let alone all combinations in Custom Partitioning because of shit just like this.


> I think the improvements for F21 - better error messages, and displaying
> the errors before you leave custom partitioning - should do the job
> fine. I think it was the bad error message and the Where's Waldo routine
> to find it that most confused people/pissed them off in F20 and earlier.

*sigh* yes Adam, it's better in that a flower has sprung up from the pile. Somehow I still prefer getting rid of the turds instead of polishing them approach.

Chris Murphy



More information about the devel mailing list