There is a bug reported about a system failing to boot with the latest pkg
and the only relevant change was this patch. Drop it just to be sure since
it is fixing a corner case in variable expansion so is not worth the risk.
Related: rhbz#1779611
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
99-grub-mkconfig: Also disable BLS usage for Xen Dom0 hosts
Resolves: rhbz#1761799
blscfg: Fix typo for gfxpayload variable name
Resolves: rhbz#1706489
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
A previous patch disabled BLS usage for Xen Dom0 guests but it turns out
that Xen Dom0 hosts also need to regenerate a GRUB config file since the
menuentries used aren't the generated by 10_linux but by 20_linux_xen.
Resolves: rhbz#1761799
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
The ppc64 big endian support ended in F29 and only ppc64le is supported so
there's no need to check for this architecture.
Also the script wasn't properly tested and the check for Xen DomU machines
isn't correct. Fix the test condition to exit the script.
Related: rhbz#1703700
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
GRUB is used to boot Xen Dom0 hosts so BLS is supported there, but PV and
PVH Xen DomU guests are booted with pygrub that doesn't have BLS support.
This means that only HVM Xen DomU guests can support BLS and others need
a traditional GRUB configuration file that contains menuentry commands.
So to make the GRUB config compatible with all Xen DomU guests, don't use
the BLS snippets and instead call grub2-mkconfig to regenerate the config
on each kernel install and removal.
Even when HVM Xen DomU guests can support BLS, just disable for all DomU
so the configuration is consistent across all Xen DomU guests variants.
And also because even when an installation is made with HVM, this can be
later changed to a DomU variant that uses pygrub and doesn't support BLS.
Resolves: rhbz#1703700
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
For ppc64le a grub config file with menuentry commands is still generated
even when BLS support is enabled. That's because BLS support was added to
Petitboot 1.8.0 and any previous version won't be able to parse BLS files.
To make the BLS snippets the source of truth, these are used to generate
the menuentry commands in the grub config file.
And to keep it consistent across all ppc64le machines regardless of the
firmware used, the grub config file is also generated for machines with
OF that use grub2 and would have BLS support.
The BLS snippets created by the kernel package have fields that are used
to specify the generated menuentry command users and class options. These
fields are not present in BLS snippets created by OSTree though, so the
script generating the menuentry commands will add options with an empty
argument which will lead to grub failing to parse them.
We could check if the field is defined before attempting to add those, but
since the grub2 blscfg module also supports setting these to variables, it
could lead to an empty argument even if was defined in the BLS snippet if
the variable doesn't exist.
So to make more robust, just don't add a class to the menuentry commands
generated by the script. It's better to not have a class for the menuentry
than grub2 failing to parse the command and not populating the boot menu.
Resolves: rhbz#1758225
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>
os-prober 1.75 dropped all the code for handling device mapper
directly in favor of only supporting the use of grub2-mount.
Thus, we now need grub2-mount to be built and packaged so that
os-prober can depend on it. We ship it in the grub2-tools-minimal
package to avoid creating a dependency loop between grub2-tools and
os-prober.
Resolves: rhbz#1471267
Signed-off-by: Neal Gompa <ngompa13@gmail.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 GRUB configuration is switched to BLS using the grub2-switch-to-blscfg
script, which is installed by the grub2-tools package. Among other things,
the script copies the blscfg module from the /usr/lib/grub/$arch directory
to /boot/grub2/$arch.
This is done because for non-UEFI installs (i386-pc and powerpc-ieee1275)
the GRUB core and modules aren't updated on package upgrade, so the blscfg
module won't be the latest that contains the current BLS support.
But the grub2-switch-to-blscfg script is currently executed in grub2-tools
%post scritplet, which means that if the grub2-tools package is installed
before the grub2-pc-modules package (that installs the blscfg module), the
grub2-switch-to-blscfg script won't copy the latest version of the module.
This will make systems to fail to populate the GRUB menu, since its config
will already be migrated to BLS but the blscfg module won't be the latest.
So to make sure that the latest blscfg module is copied regardless of the
grub2-tools and grub2-pc-modules packages install order, run the switch
script in a grub2-tools %posttrans so it's executed at the end of the RPM
transaction once all the packages have been installed.
Resolves: rhbz#1652806
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>
The switch to a BLS configuration was made before in the grubby package
%post scriptlet, but this is wrong since it means that a not up-do-date
grub2-switch-to-blscfg script could be used to do the switch.
Resolves: rhbz#1652806
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grub2-efi package create a /boot/grub2/grubenv symlink that points to
/boot/efi/EFI/fedora/grubenv that's where the real grubenv file is looked
up by GRUB on an EFI installation.
But currently if the grub2-efi is installed on a legacy BIOS install, it
will overwrite an existing /boot/grub2/grubenv file with a broken symlink.
So mark it as %config(noreplace) to avoid loosing an existing grubenv.
Resolves: rhbz#1687323
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
20-grub-install: Replace, rather than overwrite, the existing kernel (pjones)
Resolves: rhbz#1642402
99-grub-mkconfig: Don't update grubenv generating entries on ppc64le
Related: rhbz#1637875
blscfg: fallback to default_kernelopts if BLS option field isn't set
Related: rhbz#1625124
grub-switch-to-blscfg: copy increment.mod for legacy BIOS and ppc64
Resolves: rhbz#1652806
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grubenv file is updated when grub-mkconfig is executed but on ppc64le
is used on each kernel install to re-generate the grub2.cfg file with the
updated entries. So in this case the grubenv file should not be updated.
Related: rhbz#1637875
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
In rhbz#1638405, we worked around the issue of an existing initramfs
being in the way by removing it if it's older than the kernel we're in
the process of installing.
But it was buggy and only worked with some filesystem layouts and paths, and
also possibly had some issues with file creation times causing the shell -ot
comparison to fail in some cases.
This patch changes it to remove the existing kernel (as well as other
related files) in the case that it's going to do the copy, and also fixes the
path issues.
Resolves: rhbz#1642402
Related: rhbz#1638405
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Prarit Bhargava <prarit@redhat.com>
