A space in the THE_PACKAGES list makes it impossible to install
the system.

$$(EFI_BOOTLOADER)) is a bootloader for STAGE1 only.

Module efivars will be loaded by udev now.

This is necessary to prevent unintentional assignment of rEFInd
as EFI_BOOTLOADER.
I also want to hope that memtest86.efi can be made to work from
grub-efi in the future.

Signed UEFI loader not required for aarch64.

NB: i586 images don't need UEFI SB either
and 32-bit shim is used for x86_64 images
along with proper 64-bit one.

These got removed from Sisyphus during OpenSSL 1.1 transition.

Those few places lacking "; @:" replacement for a real recipe
have been finally -spotted- identified with `make check'
and fixed.

THE_* variables serve user needs while shim belongs
to either SYSTEM or COMMON level packages, not needed
explicitly for stage1 though (mkimage will put it there
when needed) so it's just COMMON.

It's been missing roughly from the start there :-/

It's not supported anymore:
http://git.altlinux.org/tasks/archive/done/_133/136193/

The newly-introduced STAGE1_KCONFIG variable serves
to keep those kernel configuration options that are
required to be present in the kernel to boot.

That reflects the packaging and distribution practice
having formed during last year or so...

This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.

Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit.  Feel free to
provide constructive criticism :)

Some path-related bitrot has also been fixed while at that.

I've noted that this bit of code should be fixed up
before pushing but managed to overlook that in the end :(

mkimage version bump is due to the somewhat changed layout
of EFI packages and binaries within those (linked message in Russian):
http://lists.altlinux.org/pipermail/devel-distro/2013-December/001283.html

It's at least as worthy as sbsigntools are.

It's implemented just like EFI_SHELL and will definitely
change someday but so far it's like this...

We chose to provide methods to sign packages but to avoid
signing these by default (with some arbitrary test keys)
the signatures are being added *after* the build by means
of rpmrebuild-pesign; all of this is made significantly
more complicated if there are separate -signed subpackages.

So these are being dropped in the packages; account for that.

This feature is more generally applicable indeed;
might result in duplication due to the installer
components adding "efivars" independently but that
is to be sorted out later in those components:
- check whether it's added already sometime soon;
- maybe stop adding that at some point in the future.

install2 and rescue roots still need this too though.

Bump it to account for the useful fixes in mkimage-0.2.7.

It's possible that use/efi/signed target has fired already
at the time when use/efi/shell is invoked; shouldn't clobber
the signed shell with unsigned one.

Its support is quite mature and practically useful by now.
Let's also add a convenient alias.

Helps with #28470 (FAT not being recognized) which is critical
due to ESP being FAT by spec :-/

Thanks timonbl4@ for the hint.

Was an oversight to miss it.

It's aimed at providing UEFI shell implementation which is very
useful for repairs and debug; if the "signed" mode is requested
then the signed variant is used either.

Please note that there are two distinct uses:
- a shell lying around on a filesystem to be copied by hand;
- a shell available in EFI part of boot media to be launched
  by firmware's or standalone boot manager (e.g. refind).

UEFI shell is pretty valuable debugging and fixup tool.

When one has to mess with Restricted Boot, openssl and
some PE signing tools might come handy either; see also
http://www.rodsbooks.com/efi-bootloaders/secureboot.html

Its bootloader autodetection capabilities can prove quite useful;
this particular addition has been "sponsored" by this thread:
http://lists.altlinux.org/pipermail/sisyphus/2013-January/subject.html#359481

The variables are best influenced by targets and not directly
to avoid architecture dependent clashes.

mkimage > 0.2.5 should have received enhanced UEFI support
including the ability to setup refind (#28349);
make the feature ready for that.

The implementation goes the shim[1] way as described here[2];
many thanks to Matthew Garrett and Rod Smith.

[1] http://mjg59.dreamwidth.org/20303.html
[2] http://www.rodsbooks.com/efi-bootloaders/secureboot.html

The rescue feature intentionally doesn't pick up THE_PACKAGES
and THE_LISTS into stage2, so add EFI ones explicitly.

There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops).  Just drop it on the floor.

As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.

The initial approach required some quite involved postprocessing
as described in http://www.altlinux.org/UEFI#HOWTO; after having
ironed out the kinks so that initial EFI support could be merged
into mkimage proper we're better off just using it, eh?

EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.

Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.