Some BLS cleanups and fixes

- 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>
This commit is contained in:
Javier Martinez Canillas 2019-10-17 13:36:25 +02:00
parent 897e388763
commit d3ceae4bfd
No known key found for this signature in database
GPG key ID: C751E590D63F3D69
5 changed files with 200 additions and 1 deletions

View file

@ -0,0 +1,78 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri, 4 Oct 2019 16:43:05 +0200
Subject: [PATCH] Don't add a class option to menu entries generated for
ppc64le
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>
---
util/grub.d/10_linux_bls.in | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/util/grub.d/10_linux_bls.in b/util/grub.d/10_linux_bls.in
index 1b7536435f1..68fbedf2129 100644
--- a/util/grub.d/10_linux_bls.in
+++ b/util/grub.d/10_linux_bls.in
@@ -127,9 +127,7 @@ read_config()
initrd=""
options=""
linux=""
- grub_users=""
grub_arg=""
- grub_class=""
while read -r line
do
@@ -148,15 +146,9 @@ read_config()
"options")
options=${value}
;;
- "grub_users")
- grub_users=${value}
- ;;
"grub_arg")
grub_arg=${value}
;;
- "grub_class")
- grub_class=${value}
- ;;
esac
done < ${config_file}
}
@@ -180,7 +172,7 @@ populate_menu()
for bls in "${files[@]}" ; do
read_config "${blsdir}/${bls}.conf"
- menu="${menu}menuentry '${title}' --class ${grub_class} ${grub_arg} --id=${bls} {\n"
+ menu="${menu}menuentry '${title}' ${grub_arg} --id=${bls} {\n"
menu="${menu}\t linux ${linux} ${options}\n"
if [ -n "${initrd}" ] ; then
menu="${menu}\t initrd ${boot_prefix}${initrd}\n"

View file

@ -0,0 +1,45 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javierm@redhat.com>
Date: Tue, 15 Oct 2019 09:08:25 +0200
Subject: [PATCH] 10_linux.in: Also use GRUB_CMDLINE_LINUX_DEFAULT to set
kernelopts
The GRUB documentation mentions that there are two variables to set the
linux kernel cmdline: GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT.
The former is added to all the menuentry commands and the latter is not
added to the recovery mode menu entries. But the blscfg module doesn't
populate recovery entries from the BLS snippets, so the values set in the
GRUB_CMDLINE_LINUX_DEFAULT variable should also be included in kernelopts.
This is needed because the GRUB_CMDLINE_LINUX_DEFAULT option is mentioned
in the GRUB documentation so users assume that the kernel cmdline options
can be changed by setting this option and running the grub2-mkconfig tool.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
util/grub.d/10_linux.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index 1520b7e47c1..0471464e68e 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -118,7 +118,7 @@ if [ "x${GRUB_ENABLE_BLSCFG}" = "xtrue" ]; then
populate_header_warn
cat << EOF
-set default_kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX}"
+set default_kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
insmod blscfg
blscfg
@@ -134,7 +134,7 @@ EOF
fi
fi
- ${grub_editenv} - set kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX}"
+ ${grub_editenv} - set kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
if [ -n "${GRUB_EARLY_INITRD_LINUX_CUSTOM}" ]; then
${grub_editenv} - set early_initrd="${GRUB_EARLY_INITRD_LINUX_CUSTOM}"
fi

View file

@ -0,0 +1,63 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javierm@redhat.com>
Date: Mon, 14 Oct 2019 17:37:26 +0200
Subject: [PATCH] blscfg: Don't hardcode an env var as fallback for the BLS
options field
If the BLS fragments don't have an options field or if this was set to an
environment variable that was not defined in the grubenv file, the blscfg
module searches for an default_kernelopts variable that is defined in the
grub.cfg file.
But the blscfg module shouldn't hardcode fallbacks variables and instead
this logic should be handled in the GRUB config file itself.
Also, add a comment explaining where the kernelopts variable is supposed
to be defined and what is the process for the user to change its value.
Resolves: rhbz#1710483
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
grub-core/commands/blscfg.c | 4 ----
util/grub.d/10_linux.in | 12 +++++++++++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/grub-core/commands/blscfg.c b/grub-core/commands/blscfg.c
index 1ec89870483..471975fd2e5 100644
--- a/grub-core/commands/blscfg.c
+++ b/grub-core/commands/blscfg.c
@@ -733,10 +733,6 @@ static void create_entry (struct bls_entry *entry)
title = bls_get_val (entry, "title", NULL);
options = expand_val (bls_get_val (entry, "options", NULL));
-
- if (!options)
- options = expand_val (grub_env_get("default_kernelopts"));
-
initrds = bls_make_list (entry, "initrd", NULL);
devicetree = expand_val (bls_get_val (entry, "devicetree", NULL));
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index 0471464e68e..21a6915dca3 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -118,7 +118,17 @@ if [ "x${GRUB_ENABLE_BLSCFG}" = "xtrue" ]; then
populate_header_warn
cat << EOF
-set default_kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
+# The kernelopts variable should be defined in the grubenv file. But to ensure that menu
+# entries populated from BootLoaderSpec files that use this variable work correctly even
+# without a grubenv file, define a fallback kernelopts variable if this has not been set.
+#
+# The kernelopts variable in the grubenv file can be modified using the grubby tool or by
+# executing the grub2-mkconfig tool. For the latter, the values of the GRUB_CMDLINE_LINUX
+# and GRUB_CMDLINE_LINUX_DEFAULT options from /etc/default/grub file are used to set both
+# the kernelopts variable in the grubenv file and the fallback kernelopts variable.
+if [ -z "\${kernelopts}" ]; then
+ set kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
+fi
insmod blscfg
blscfg

View file

@ -180,3 +180,6 @@ Patch0179: 0179-Fix-build-error-with-the-fdt-module-on-risc-v.patch
Patch0180: 0180-RISC-V-Fix-computation-of-pc-relative-relocation-off.patch
Patch0181: 0181-blscfg-Add-support-for-the-devicetree-field.patch
Patch0182: 0182-Set-a-devicetree-var-in-a-BLS-config-if-GRUB_DEFAULT.patch
Patch0183: 0183-Don-t-add-a-class-option-to-menu-entries-generated-f.patch
Patch0184: 0184-10_linux.in-Also-use-GRUB_CMDLINE_LINUX_DEFAULT-to-s.patch
Patch0185: 0185-blscfg-Don-t-hardcode-an-env-var-as-fallback-for-the.patch

View file

@ -9,7 +9,7 @@
Name: grub2
Epoch: 1
Version: 2.04
Release: 2%{?dist}
Release: 3%{?dist}
Summary: Bootloader with support for Linux, Multiboot and more
License: GPLv3+
URL: http://www.gnu.org/software/grub/
@ -515,6 +515,16 @@ rm -r /boot/grub2.tmp/ || :
%endif
%changelog
* Thu Oct 17 2019 Javier Martinez Canillas <javierm@redhat.com> - 2.04-3
- 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
* Wed Sep 18 2019 Javier Martinez Canillas <javierm@redhat.com> - 2.04-2
- A couple of RISC-V fixes
- Remove grub2-tools %%posttrans scriptlet that migrates to a BLS config