Description of problem: anaconda will currently only install the EFI related bootloader bits if EFI is detected on the system. This is an issue if anaconda is used to build images (liveimg compat squashfs image), where EFI is not present at build time, but can likely be present at installation time. The currently solution is to add the necessary packages to the kickstart as described in [1] and [2]. To centralize the knowledge about what packages are required, it would be good if the bootloader directive of anaconda had a switch to enforece that the EFI bootloader bits get instaleld - even if no EFI system was dected. i.e.: bootloader --efi [1] https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html [2] http://lorax.readthedocs.org/en/latest/livemedia-creator.html#kickstarts
This isn't really possible. I looked into doing this for lmc and ran into trouble with grub2 for a start. Various tools detect the system they are running on and change their behavior based on it. If you want to create UEFI disk images you need to create them on a UEFI system, or VM.
Right. I can imagine that setting the EFI bootloader will fail, i.e. grub2-efi, because it can not write the relevant EFI variables. But wouldn't it make sense to at least provide a switch for lmc or anaconda to package the necessary packages? I'm thinking about the use case where lmc is used to generate an liveimg, and then EFI can be installed depending on the target system upon installation. Anaconda will do the EFI installation, but this requires that the necessary packages are part of the liveimg.
If you are building an installer image this already works, you don't need any switches. Simply include the grub2-efi package in the %packages section of the kickstart. eg. https://github.com/rhinstaller/lorax/blob/master/docs/fedora-livemedia.ks
Right, but does this also install support for SecureBoot? And: It's not about adding this package or not to the kickstarts. It is really more about keeping the responsibilities to add this high-level EFI functionality in lmc/anaconda. By keeping this package based solution, the responsibility is on the side of the image builder, to make sure that the right (maybe in future changing) packages are included in the kickstart, if there was a high-level efi switch, then the responsibility would stay in anaconda - like it already is anaconda's responsibility today to add the "right packages" (tm) if an EFI system is detected.
Good question, if you are making a live installer iso and include the @anaconda-tools group it will pull in shim, grub2-efi, etc. Otherwise you will need to add the correct packages for the type of iso you want to build. UEFI disk images should add shim if they aren't including the group. But you have to build a UEFI disk image on a UEFI system (or VM) so shim will get added automatically.
My assumption is that anaconda (and/or lmc) is intended for image builds as well - And under this assumption I don't understand why anaconda/lmc does not bring the features to allow building an image which can also be booted on UEFI machines.
The problem is that many of the tools used by anaconda assume they are running on the targeted platform so the disk image can't be setup for UEFI when built inside a BIOS vm. Creating isos that work on BIOS and UEFI is possible because the boot sequence is created by lmc, not anaconda and associated tools.