- 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>
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>
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>
- Add riscv64 support to grub.macros and RISC-V build fixes (davidlt)
- blscfg: Always use the root variable to search for BLS snippets
- bootstrap.conf: Force autogen.sh to use python3
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
- Various grub2 cleanups (pbrobinson)
- Another fix for blscfg variable expansion support
- blscfg: Add support for sorting the plus ('+') higher than base version
Resolves: rhbz#1767395
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
- 20-grub-install: Don't add an id field to generated BLS snippets
- 99-grub-mkconfig: Disable BLS usage for Xen machines
Resolves: rhbz#1703700
- Don't add a class option to menu entries generated for ppc64le
Resolves: rhbz#1758225
- 10_linux.in: Also use GRUB_CMDLINE_LINUX_DEFAULT to set kernelopts
- blscfg: Don't hardcode an env var as fallback for the BLS options field
Resolves: rhbz#1710483
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
- A couple of RISC-V fixes
- Remove grub2-tools %%posttrans scriptlet that migrates to a BLS config
- Add blscfg device tree support
Resolves: rhbz#1751307
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
This change updates grub to the 2.04 release. The new release changed how
grub is built, so the bootstrap and bootstrap.conf files have to be added
to the dist-git. Also, the gitignore file changed so it has to be updated.
Since the patches have been forward ported to 2.04, there's no need for a
logic to maintain a patch with the delta between the release and the grub
master branch. So the release-to-master.patch is dropped and no longer is
updated by the do-rebase script.
Also since gnulib isn't part of the grub repository anymore and cloned by
the boostrap tool, a gnulib tarball is included as other source file and
copied before calling the bootstrap tool. That way grub can be built even
in builders that only have access to the sources lookaside cache.
Resolves: rhbz#1727279
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
This change reorganizes and cleanups our patches to reduce the patch number
from 314 patches to 187. That's achieved by dropping patches that are later
reverted and squashing fixes for earlier patches that introduced features.
There are no code changes and the diff with upstream is the same before and
after the cleanup. Having fewer patches makes easier to manage the patchset
and also will ease to rebase them on top of the latest grub-2.04 release.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Building the multiboot and multiboot2 modules was disabled for EFI builds.
But that made the menu entries created by the Xen package to stop working
since they use the multiboot2 module.
The modules were disabled modules because they can be used to bypass the
Secure Boot mechanism. But it's enough to not include these modules in the
grub2 EFI binary that's signed, which is the case already in the grub2 pkg.
Having them as modules if the user installs the grub2-efi-x64-modules is
a valid use case. And since module loading isn't allowed when Secure Boot
is enabled, it doesn't represent any security threat.
Resolves: rhbz#1703872
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Fix failure to request grub.cfg over HTTP
Some ARM fixes (pbrobinson)
Preserve multi-device workflows (Yclept Nemo)
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Fix --bls-directory option comment in grub2-switch-to-blscfg man page
Resolves: rhbz#1714835
10_linux_bls: use '=' to separate --id argument due a Petitboot bug
grub-set-bootflag: Print an error if failing to read from grubenv
Resolves: rhbz#1702354
10_linux: generate BLS section even if no kernels are found in /boot
10_linux: don't search for OSTree kernels
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The blscfg module isn't compatible with the GRUB core.img installed by any
release older than Fedora 21.
This is because the blscfg module calls to the grub_file_size() function to
check if the BLS file size is correct, but the struct grub_file used as the
parameter for this function changed in the GRUB version used in Fedora 21.
So the function returns a wrong file size due the .size field offset being
different in the older GRUB from Fedora 20 and earlier.
This is causing all the BLS files to be ignored due having a wrong size and
leading to GRUB menu not being populated on boot.
Related: rhbz#1652806
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
GRUB has an user-space program emulator that allows to parse config files
and execute boot entries using the kexec tool. Add a grub2-emu subpackage
to install the emulator.
The subpackage is disabled on ppc64le architecture for now since grub2-emu
fails to build there.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The generated menu entries have a --users $grub_users option but this will
fail on old versions of GRUB, since it expects the --users option argument
to either be a constant or a variable that has been set.
The latest GRUB version fix this but the GRUB core isn't updated on a GRUB
package update, so this will cause the entries to not be shown in the menu
after a system upgrade.
Since can cause issues and because the entries that weren't generated from
the BLS snippets didn't have the --users option either, just don't add it.
Resolves: rhbz#1693515
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
There was an error in the logic that stored the parsed BLS snippets in the
sorted linked list that is used to populate the GRUB boot menu entries.
Also add a fix found by coverity scan about a possible undefined behaviour
due grub_efi_status_t having the wrong type.
Resolves: rhbz#1691232
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Commit bfc756f8d86 ("Set blsdir if the BLS directory path isn't one of the
looked up by default") attempted to set blsdir if /boot/loader/entries was
not the real path of the directory containing the BLS snippets. Which may
be the case if for example /boot/loader/entries is in a btrfs subvolume.
But in the case of ostree, /boot/loader is a symlink to the directory with
the entries for the current deployment. So with ostree the blsdir will be
wrongly set, since GRUB is able to follow the symlinks just fine. In fact,
it has to follow the symlink since otherwise GRUB will always use the BLS
files for the deployment that the symlink pointed out when blsdir was set.
So only set blsdir if /boot/loader/entries is in a btrfs or zfs partition.
Related: rhbz#1688453
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
