Red Hat Bugzilla – Bug 1023284
Anaconda should partition the default /boot partition based on the boot loader specification
Last modified: 2014-02-21 12:39:08 EST
Description of problem:
Anaconda should follow the partitioning layout for the boot specification for the /boot partition on (u)efi installs so alternative boot loaders such as gummiboot as well as kernel updates can work without a hitch.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The partition tool of anaconda is for me like some adventure. You specify your layout and come back to the parent page. There you see that your layout is wrong (there is an error) but you get no hint what is wrong (this was the same thing in the last versions). I hoped it would have improved for Fedora 20 but nothing. I was disappointed and it took me the whole afternoon to setup my system the way I wanted it.
First you have to find out that anaconda insists on a separate /boot/efi partition. This could be avoided - and this is what I tried - by simply formatting /boot with vfat. But as soon as /boot/efi is missing you get an error. But you get no explanation from anaconda that the reason for the error is that /boot/efi is missing. This you have to find out with trial and error.
Now the next surprise: even if you give the /boot/efi partition to anaconda and you try to format /boot with vfat to be prepared to install gummiboot: then anaconda is giving you again an error. Then you change to ext4 for /boot and then it works.
In the end I installed the system anaconda wanted it to have and then used a chroot environment and gdisk to remove the /boot/efi and reformat the /boot partition with vfat in order to work with gummiboot.
Handling something like this is very straight forward with Arch Linux but pain in the ass with Fedora.
(In reply to Jóhann B. Guðmundsson from comment #0)
> Description of problem:
> Anaconda should follow the partitioning layout for the boot specification
> for the /boot partition on (u)efi installs so alternative boot loaders such
> as gummiboot as well as kernel updates can work without a hitch.
Conspicuously absent from this spec: anything about secureboot and how this spec is supposed to work with a shim-loaded bootloader.
No thanks, we already have one of those