When updating args for ALL kernels, grubby clobbers all variables
in /etc/default/grub that start with GRUB_CMDLINE_LINUX and renders
that line multiple times, for each variable that exists. This breaks
using recovery mode. Fix so this doesn't happen anymore.
Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
The BLS snippets have the options field set to a kernelopts variable by
default, which is set in GRUB's environemnt block to the kernel cmdline.
When the kernel command line parameters are modified for all the entries,
the value of this kernelopts variable is modified. But if the cmdline is
modified for a single entry, then the kernelopts variable is expanded and
the resulted modified value stored in the BLS snippet.
The grubby tool expanded all the variables in the options field, but it's
possible that some of these variables are managed by another tool. For
example the tuned program adds a tuned variable that shouldn't be changed
by the grubby tool. Otherwise it will mangle the tuned configuration set.
To prevent this, let's make grubby to only expand the kernelopts variable.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Currently the grubby script re-generates a GRUB config file that contains
menuentry commands for every /boot/loader/entries/*.conf file snippet.
But this is only needed for ppc64le machines that have a Petitboot version
that doesn't support parsing BLS snippets. Instead of generating a config
on any ppc64le machine, restrict this for the case where is really needed.
The /etc/grub.d/10_linux script already takes this into account and does
not add menuentry commands unless is needed. But the grubby script didn't
check this, causing changing kernel cmdline params to not work on ppc64le.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If the options field in a BLS file has the same value than the kernelopts
variable in grubenv, the options is replaced with the kernelopts variable.
This was done to keep the options in the BLS files in sync when possible,
but having the kernel cmdline as a variable in the grubenv file was proven
to be fragile. Instead, the kernel cmdline will be stored in the BLS files
to make the configuration more robust. This will work even if the grubenv
gets corrupted or is deleted.
Since we want to get rid of the kernelopts variable, don't attempt to use
that in the BLS snippets anymore.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The option makes grubby to not update the GRUB_CMDLINE_LINUX variable in
the /etc/default/grub file when the --update-kernel=ALL option is used.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The forward slash character is used as the delimiter for sed substitutions
so this is escaped before calling sed.
But this was only done before removing parameters from the kernel command
and not when adding it. Use it for all the cases when the parameters are
replaced in the update_args() function.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If a kernel command line parameter has a '=' character, grubby fails
to update the options field in the BLS snippet, for example:
$ grubby --update-kernel=foo --args="bar=https://test?token="
sed: -e expression #1, char 30: unknown option to `s'
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grubby --update-kernel=ALL option is used to update the kernel command
line parameters for all the boot entries. But the updated cmdline is lost
if the grub2-mkconfig command is executed, since in that case the cmdline
is changed with the value set by GRUB_CMDLINE_LINUX in /etc/default/grub.
To prevent the cmdline set by users to be overridden by mistake, keep the
value of GRUB_CMDLINE_LINUX in sync with the current cmdline.
Related: rhbz#1287854
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Since PowerNV machines can have a Petitboot versions that still don't have
BLS support, grubby re-generates the grub.cfg file on all ppc64le machines.
But this has the side effect that the grubenv file is updated, which will
overwrite any value that was set by grubby itself. To prevent that run the
grub2-mkconfig with the --no-grubenv-update option.
Related: rhbz#1726514
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The logic to check if a kernelopts variable is defined in a BLS entry was
wrong and caused grubby to expand the variables even when it was defined.
Resolves: rhbz#1726514
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If there are no BLS snippets, an empty array of strings is passed to the
rpm-sort tool and it will print an error that just confuses grubby users.
Resolves: rhbz#1731924
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If the /boot directory is a mount point, then the paths of the kernel and
initramfs images paths in the BLS snippet have to be relative to the root
of the boot partition. So the /boot prefix has to be stripped from paths
in this case.
But the function was wrongly stripping the entire path instead of only the
/boot prefix, which prevented having kernels and initrds in subdirectories.
Signed-off-by: Yuval Turgeman <yturgema@redhat.com>
Using grep is wrong and fragile, so let's use the mountpoint command
instead to make it more robust.
Resolves: rhbz#1706091
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The script prints an error if --args option is used without --update-kernel
but it's also valid to use it with the --add-kernel option.
Resolves: rhbz#1691004
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Currently there's no way to update the kernelopts variable defined in the
grubenv by using the grubby wrapper. Updating it with grub2-editenv - set
is tedious and error prone so let's use --update-kernel=ALL option for it.
This command currently iterates over all the BLS entries and update them
individually, but makes more sense to update the kernelopts grubenv var
and only update the BLS entries that don't have the $kernelopts var in
their options field.
If after an update one of these BLS entries have exactly the same params
in their options field than the ones set in $kernelopts, set the options
field to $kernelopts again since the parameters have converged again.
That way the modified BLS entries will only have a custom options field
while its value diverged from the $kernelopts defined in grubenv.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The --args and --remove-args options can only be used when the kernel to
update is specified using the --update-kernel option. Print an error if
the latter option is not provided.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If the default entry is removed, this can't be set as the default anymore
for zipl. Otherwise the zipl tool will fail since it won't exist an IPL
section for the one set as the default.
For grub2, if the saved_entry doesn't exist it will fallback to the first
entry. But still the correct thing to do is to unset the default there.
Resolves: rhbz#1668329
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
- Correctly set LDFLAGS to include hardened flags (pjones)
Related: rhbz#1654936
- grubby-bls: expand all variables in options field when updating it
Resolves: rhbz#1660700
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
There is a grub2-set-default script that can be used to set the default
entry. It can take an entry id, title or index as a parameter so grubby
should be able to also lookup a default entry using the title on grub2.
Related: rhbz#1654936
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
a BLS file is generated at build time and stored in /lib/modules/$kernel
but this default BLS file assumes that /boot is a mount point and so the
kernel and initrd paths are relative to the root of this boot partition.
This is not the case if /boot is not a mount point or if the bootloader
is zipl, since zipl expects the absolute path to be in the BLS snippet.
The kernel-install scripts takes care of this and modifies the BLS file
if needed, but grubby doesn't do that. So instead just generate the BLS
always even if there is one for the kernel version of the added entry.
Resolves: rhbz#1653365
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grub2 bootloader allows the BLS snippets fields to contain environment
variables instead of constants. This is useful for example to define the
kernel command line parameters only once in the grubenv file and set this
variable in the BLS snippets.
But this can be confusing for users when the information is printed by the
grubby script, so expand the variables if they can be looked up in grubenv.
Resolves: rhbz#1649785
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The kernel command line can contain parameters that are specified multiple
times. This is supported by the old grubby tool but ins't supported by the
grubby BLS wrapper. Allow the grubby wrapper to do the same.
Resolves: rhbz#1652486
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The absolute path to the kernel and initramfs images is printed by the
--info option, but it's not printed by the --default-kernel option.
Resolves: rhbz#1649778
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The old grubby tool printed the root parameter separated from the other
kernel command line arguments. Make the wrapper have the same behaviour.
Resolves: rhbz#1649791
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The BLS file "linux" and "initrd" fields expect a relative paths from the
root of the partition that contains the kernel and initramfs. The grubby
tool was printing the value of thse fields and not their full path.
So if there is a partition and /boot is a mount point, he BLS would have:
linux /vmlinuz-4.18.0-38.el8.x86_64
initrd /initramfs-4.18.0-38.el8.x86_64.img
And grubby would print:
kernel="/vmlinuz-4.18.0-38.el8.x86_64"
initrd="/initramfs-4.18.0-38.el8.x86_64.img"
But the old tool used to print the full paths of the images, so should be:
kernel="/boot/vmlinuz-4.18.0-38.el8.x86_64"
initrd="/boot/initramfs-4.18.0-38.el8.x86_64.img"
Resolves: rhbz#1649778
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Most bootloaders use the BootLoaderSpec "title" field to name the entries
in their boot menu. The zipl bootloader used the "version" field instead,
since it was wrongly assumed that the zipl boot menu didn't support names
that contained spaces, which are usually present in a BLS "title" field.
But this is not the case, names with space characters are supported by the
IPL and is just a constraint of the section heading in the zipl.conf file.
To be consistent with all the other bootloaders, zipl now uses the "title"
field to populate the boot menu entries from BLS files. So change grubby
to use the "title" field to set the default entry of the "version" field.
Related: rhbz#1645200
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grub2 bootloader expects the BLS linux and initrd fields values to be
set to a relative path to the root of the boot partition and the zipl tool
expects these to be an absolute path to the kernel and initramfs images.
So the grubby wrapper was removing the prefixes from the kernel and initrd
paths before doing any comparision with the BLS fields. But this shouldn't
be done if the /boot directory isn't a mount point.
Resolves: rhbz#1642078
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The BLS files name convention used is ${MACHINE_ID}-${KERNEL_VERSION}.conf
but this means that there can only be a single entry for a given kernel.
Allow the grubby wrapper to add many entries for the same kernel image,
since the old grubby tool was able to do that. To differentiate from the
original BLS entry and to specify that it's a customized entry, add a
[[:digit:]]~custom suffix after the kernel version number.
This will also sort the custom entries before the original entry, that's
also what the old grubby tool did.
Resolves: rhbz#1634752
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
For the debug BLS entries a -debug suffix was added so they are sorted after
the kernel entries, but that only works with version sort and not rpm sort.
So instead use ~debug prefix so rpm sort algorithm could sort it correctly.
Related: rhbz#1638103
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The wrapper is using the title before to store the default entry, but we
are now using the entry id for grub2, so make the wrapper query the id.
Resolves: rhbz#1638103
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The ! character was used as the delimiter, but this doesn't work when the
param uses this character, for example "memmap=1G!1G".
Resolves: rhbz#1640017
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The BLS entries use a global kernel command line parameters that's set as
kernelopts variable in the grubenv file. But users may want to have custom
parameters for some entries, so make a copy of the current kernelopts and
set the "options" field value to the modified parameters.
Resolves: rhbz#1629054
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grubby --info option didn't check if an entry existed for a kernel and
printed wrong information about it. Fix this and also for --update-kernel
and --set-default options that have the same issue.
Resolves: rhbz#1634712
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The grubby wrapper sets the saved_entry in grubenv to the entry title
field since that's done by grubby. But for BLS the id is the filename
without the .conf extension, this saved_entry is set to this when a
new kernel is installed.
So for consistency also use the entry id for the --set-default option.
Related: rhbz#1638103
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
