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>
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>
cmurf and javierm noticed[0] that we don't have zstd enabled, and that could
cause issues in some cases for /boot on btrfs subvolumes. This adds it to our
module list.
[0] https://github.com/rhinstaller/anaconda/pull/2255#discussion_r359123085
Related: rhbz#1418336
Signed-off-by: Peter Jones <pjones@redhat.com>
This gets rid of the vestigial remnants of the now-obsolete
release-to-master.patch , and moves gnulib to be earlier in our source list.
Signed-off-by: Peter Jones <pjones@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>
- drop deprecated groups from the macros file, already gone from main spec.
- don't ship arch specific bits in tools-extra that are already special cased in tools
- move grub2-glue-efi to tools-efi, it's Mac specific and there's othe Mac efi tools there
- drop tools-extra dep for efi binaries, all in tools-efi and anaconda deals with that
- put grub2-install man page in the right package with the util
- other minor cleanups
- 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>
PV and PVH Xen DomU guests boot with pygrub that doesn't have BLS support.
Also Xen Dom0 use the menuentries from 20_linux_xen and not the ones from
10_linux. So BLS support needs to be disabled for both Xen Dom0 and DomU
and use a traditional grub.cfg file generated by the grub2-mkconfig tool.
Resolves: rhbz#1703700
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
The id field isn't used anymore by the blscfg module and instead the BLS
filename without the .conf is used as the id for the generated menu entry.
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>
Releng attempted to build the grub2 package as a part of the Fedora 31
mass rebuild [0], but this failed due lack of credentials to build the
grub2 package. Do a manual build for the rebuild to succeed.
[0]: https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The BLS files are copied from /lib/modules/$(uname -r)/bls.conf and this
file has a SELinux label of "system_u:object_r:modules_object_t" like all
the other files that are installed by the kernel package.
But the files in the /boot directory are expected to have a SELinux label
of "system_u:object_r:boot_t". For all the other files that are copied to
/boot by the kernel-install script, the SELinux security contexts are
restored to the default but that was missing for the BLS files.
Resolves: rhbz#1726020
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The btrfs snapshot submenu was removed because it broke the old grubby tool
since it searched for "menuentry". But now that a BLS config is supported,
this can be added again as long as grubby isn't used.
This patch also moves the grub2-probe tool to the tools-minimal package to
prevent a circular dependency since the grub2-tools package depends on the
os-prober package, but os-prober package needs grub2-probe as a dependency.
So instead of making os-prober to depend on grub2-tools, it can be made to
depend on the grub2-tools-minimal subpackage.
Resolves: rhbz#1715994
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 rpm-build's "debugedit" program will silently corrupt .debug_macro
strings when a binary is compiled with -g3. Later in the build phase,
gdb-add-index is invoked to extract the DWARF index from the binary,
and GDB will segfault because dwarf2read.c:parse_definition_macro's
'body' variable is NULL.
Resolves: rhbz#1708780
rpmdiff noticed the following:
Detecting usr/sbin/grub2-ofpathname with not-hardened warnings '
Hardened: grub2-ofpathname: FAIL: Gaps were detected in the annobin coverage. Run with -v to list.
Hardened: grub2-ofpathname: FAIL: Not linked with -Wl,-z,now.
Hardened: grub2-ofpathname: MAYB: The PIC/PIE setting was not recorded.
Hardened: grub2-ofpathname: FAIL: Not linked as a position independent executable (ie need to add '-pie' to link command line).
' on ppc64le
This is because while we made the CFLAGS get some new options, LDFLAGS never
got the same treatement, and we disabled %{_hardened_build} to avoid getting
its options in the TARGET_{C,LD}FLAGS variables.
This patch duplicates the infrastructure for {HOST,TARGET}_CFLAGS into
{HOST,TARGET}_LDFLAGS, and adds the %{_hardening_ldflags} and
%{_hardening_cflags} to both HOST_{C,LD}FLAGS.
Additionally, it fixes the CPPFLAGS definitions, since rpm doesn't define any
CPPFLAGS at all, and makes the -I$(pwd) be there exclusively, not on CFLAGS as
well, since they're always used in concert.
Signed-off-by: Peter Jones <pjones@redhat.com>
There's no point on executing the script if GRUB_ENABLE_BLSCFG has already
been set. Currently was checking if an user explicitly set it to false to
avoid enabling the BLS configuration, but it should also be avoided if was
already set to true by a previous package update or during installation.
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>
