If there's no GRUB config in the ESP, generate one. This is a full config
but later the posttrans script will convert it to the minimal config stub.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The efi-srpm-macros package contais a macro for the ESP vendor directory
to make sure that the correct one for each distro is used. But the grub2
package is instead hardcoding it to "fedora", use the macro instead.
Signed-off-by: Benjamin Herrenschmidt <benh@amazon.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Also simplify the logic to determine the filesystem UUID of the partition
that contains the /boot/grub2 directory.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If there is no grub config, for example when installing the
system via anaconda, there is no need to attempt a grub
configuration unification. It will indeed actually break
because it will try to copy a non-existent file.
Resolves: rhbz#1933085
The previous commits, especially b14117, unified the grub config
locations across all platforms. In brief, this means that in the
case of EFI, the config file in the EFI System Partition (ESP)
is now meant to be a small stub config file that will in turn
load the main configuration in /boot/grub2, which is used on
all other platforms as well. For new installations all this is
done by the Anaconda installer. But existing installations also
need to be adapted.
Add a %posttrans script to the grub2-common package that will,
if a non-unified installation is detected, transition it into
a unified one. This is done by moving the main grub.cfg file
from the ESP to /boot/grub2, creating minimal stub on the ESP
instead. Additionally, the grubenv file is also moved from the
ESP to /boot/grub2.
The detection of the non-unified installation is done by
checking if the grub.cfg on the ESP contains the 'configfile'
directive. If so, it is assumed the system has a unified
grub configuration.
Signed-off-by: Christian Kellner <christian@kellner.me>
- Remove -fcf-protection compiler flag to allow i386 builds (law)
Related: rhbz#1915452
- Unify GRUB configuration file location across all platforms
Related: rhbz#1918817
- Add 'at_keyboard_fallback_set' var to force the set manually (rmetrich)
- Add appended signatures support for ppc64le LPAR Secure Boot (daxtens)
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The GRUB configuration files layout on EFI platforms isn't consistent with
other non-EFI platforms (e.g: legacy BIOS x86 and Open Firmware ppc64le).
On platforms using EFI, the GRUB config file (grub.cfg) and environment
variables block (grubenv) are stored in the EFI System Partition (ESP),
while for non-EFI platforms these are stored in the boot partition (or
/boot directory if not boot partition is used).
The reason for this is that the path where the GRUB bootloader searches
for its configuration file varies depending on the firmware interface.
For EFI the GRUB binary is located in the ESP and it expects to find its
config file in that location as well. But this creates the mentioned
inconsistency, because the GRUB configuration file has to be stored in
/boot/efi/EFI/fedora/grub.cfg while for non-EFI platforms it has to be
stored in /boot/grub2/grub.cfg.
To allow all platforms to have the GRUB config file in the same location,
only a minimal config file could be stored in the ESP and this will load
the one that is stored in /boot/grub2.
Related: rhbz#1918817
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
GRUB uses -march=i386 to build the x86 BIOS code but recent changes in the
default %{optflags} enabled the -fcf-protection flag that's not compatible
with pre-i686 CPUs.
This led to a build error in the grub2 package. To avoid this failure and
let the package to build again, remove the -fcf-protection flag for now.
Related: rhbz#1915452
Signed-off-by: Jeff Law <law@redhat.com>
Users can unintentionally remove the grub2 packages and break their system
by deleting the bootloader. To prevent this mark them as protected by DNF.
Resolves: rhbz#1874541
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The /boot/grub2/grubenv file is not installed by the grub2 packages but
is either a symbolic link created on %install or a regular file created
by Anaconda during installation.
This is causing the tps-rpmtest to fail in some architectures since the
file attributes don't match what's expected by the package. Because is
a special file, make verification to ignore the size, mode, checksum
and mtime attributes.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
OSTree doesn't support installations that don't have a boot partition. The
BLS snippets assume that there will be one, so this has to be checked and
only mark GRUB as supporting BLS in OSTree systems have a boot partition.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The Default Boot Behavior for EFI if no BootOrder and Boot#### variables
are found is to look for an ESP and start \EFI\BOOT\BOOT{$arch}.efi.
This is usually fallback.efi installed by the shim package, but since shim
isn't used on armv7, there's no \EFI\BOOT\BOOTARM.EFI installed in the ESP.
So install GRUB as \EFI\BOOT\BOOTARM.EFI for armv7 so there is a default
EFI binary to be started.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Since GRUB 2.04 there is support for TPM measurements in a tpm module that
uses the verifiers framework. So this is used now instead of the previous
downstream patches that we were carrying.
But we forgot to enable this module when rebasing to 2.04 which leads to
GRUB no longer measuring the kernel, initrd and command line parameters.
One side effect of using the verifiers framework is that if measurements
fail, GRUB won't be able to open the files since the errors from the tpm
module are propagated. This means that a firmware with a buggy tpm support
will prevent the machine to boot, which was not the case with the previous
downstream patches. Don't propagate the measurement errors to prevent this.
Resolves: rhbz#1836433
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The kernel cmdline was stored as a kernelopts variable in the grubenv file
and the BLS snippets used that. But this turned out to be fragile since the
grubenv file could be removed or get corrupted easily.
To prevent the entries to not have a cmdline if the grubenv can't be read,
a fallback variable was set in the GRUB config file. But this still caused
issues since the config needs to be re-generated to change the parameters.
Instead, let's store the cmdline in the BLS snippets. This will make the
configuration more robust, since it will work even without the grubenv
file and the BLS entries will contain all the information needed to boot.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
blscfg: Lookup default_kernelopts variable as fallback for options
Related: rhbz#1765297
10_linux.in: fix early exit due error when reading petitboot version
Resolves: rhbz#1827397
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The logic to parse the BLS configs to generate a set of menuentry commands
that's needed on ppc64le machines with bootloaders that don't have support
to parse BLS config directly, was implemented in a 10_linux_bls script.
But there's no need to have a separate script just for this and this logic
can be merged into the 10_linux script to avoid code duplication.
Also since the blscfg module will also now be used by ostree-based distros
there is a possible corner case in which a user set the blsdir variable to
a BLS directory path that is different than the default used by ostree.
So to avoid possible issues, only drop the marker file to specify that the
bootloader has support to parse BLS files if this variable hasn't been set.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
