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>
- Fix GCC warnings about possible string truncations and buffer overflows
- grubby-bls: unset default entry if is the one being removed
- grubby-bls: show absolute path when printing error about incorrect param
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>
- grubby-bls: also print the absolute path in the --default-kernel option
Resolves: rhbz#1649778
- grubby-bls: allow to specify the same kernel param multiple times
Resolves: rhbz#1652486
- grubby-bls: expand kernel options if these are environment variables
Resolves: rhbz#1649785
- grubby-bls: always generate the BLS snippets when adding new entries
Resolves: rhbz#1653365
- Improve man page for --info option (jstodola)
Resolves: rhbz#1651672
- Make the old grubby take precedence over grubby-bls if is installed
Related: rhbz#165484
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Not all bootloaders used in Fedora have BLS support, for example extlinux
doesn't. So when using extlinux the old grubby tool has to be installed.
Currently the grubby-bls wrapper has precedence over the old grubby tool,
which means that even if grubby-deprecated is installed, the wrapper will
executed when calling grubby. Make the old grubby take precedence instead.
Related: rhbz#1654841
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>
- installkernel-bls: remove unnecessary check for GRUB_ENABLE_BLSCFG=true
Resolves: rhbz#1647721
- grubby-bls: use title field instead of version for zipl default entry
Related: rhbz#1645200
- grubby-bls: print the absolute kernel and initramfs images paths
Resolves: rhbz#1649778
- grubby-bls: make info print the root parameter if is present in cmdline
Resolves: rhbz#1649791
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>
A BLS configuration is the default and in this case the installkernel-bls
script is used. For a non-BLS configuration the grubby-deprecated package
installs an installkernel that uses the new-kernel-pkg script.
So there is no need to check for GRUB_ENABLE_BLSCFG=true. Also, this check
is wrong for s390x and was causing the installkernel-bls script to no call
kernel-install on this platform.
Resolves: rhbz#1647721
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
By default the old grubby tool isn't installed anymore and it's part of
the grubby-deprecated package. Instead the grubby wrapper that modifies
BLS config files is installed for backward compatiblity with old grubby.
So on postinstall the bootloader configuration has to be changed to BLS
since non-BLS bootloader configuration won't be updated anymore without
the old grubby tool and the new-kernel-pkg script.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Now that Anaconda defaults to a BootLoaderSpec setup on installation, the
the grubby package should also install the grubby BLS wrapper by default.
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>
- Make the temporary config wrapper be what "grubby" contains, and put
traditional grubby in grubby-deprecated (pjones)
- Re-enable debuginfo generation (pjones)
Related: rhbz#1619344
- Install installkernel-bls here as well, not just in the grub2 package,
since s390x doesn't have grubby packages (pjones)
Related: rhbz#1619344
- Make grubby-bls execute grub2-mkconfig on ppc64
Resolves: rhbz#1636039
- grubby-bls should only check if kernel exists and not if was installed
Resolves: rhbz#1634740
- Use ! instead of , as sed delimiter in grubby-bls script
Resolves: rhbz#1634744
- Print information about the entry set as default
Resolves: rhbz#1636180
- grubby-bls: make "id" be the filename, and include it in --info=ALL (pjones)
Related: rhbz#1638103
- grubby-bls: Make grubby-bls sort everything the same way grub2 does (pjones)
Resolves: rhbz#1638103
- grubby-bls: Consistently use the filename as the bls id
Related: rhbz#1638103
- grubby-bls: check if entry exists before attempting to print its info
Resolves: rhbz#1634712
- grubby-bls: make a copy of the cmdline if is modified for an entry
Resolves: rhbz#1629054
- grubby-bls: escape delimiter character before replacing the options field
Resolves: rhbz#1640017
- grubby-bls: grubby-bls: use id instead of title to get the default entry
Resolves: rhbz#1638103
- grubby-bls: use ~debug instead of -debug as suffix to sort correctly
Related: rhbz#1638103
- grubby-bls: allow to add many BLS entries for the same kernel image
Resolves: rhbz#1634752
- grubby-bls: fix --default-* options for s390x
Resolves: rhbz#1644608
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>
This information can be useful for users to know what's the BLS entry
that was set as the default.
Resolves: rhbz#1636180
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The script uses sed to modify the options field in the BLS entries, but it
is using a ',' character as the sed delimiter. It's total valid to have a
kernel command line parameter that contains that character, for example:
$ grubby --add-kernel=/boot/vmlinuz --args="console=ttyS0,115200n81" \
--initrd=/boot/initrd.img --make-default --title=install
sed: -e expression #1, char 42: unknown option to `s'
Fix this by using a different delimiter that won't be present in a cmdline.
Resolves: rhbz#1634744
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
When a new BLS entry is added, the script checks if the kernel image exists
and also if it was installed from a rpm package. But the latter isn't really
needed, it should be valid to just copy a kernel image and add a BLS entry.
Resolves: rhbz#1634740
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
When booting an ppc64 machine on bare-metal (PowerNV) the OPAL firmware
interface is used. The firmware contains the Petitboot boot-loader that
can be used to parse the BootLoaderSpec (BLS) snippets in a BLS setup.
But machines could have an older version of Petitboot that doesn't have
BLS support, so on ppc64 machines can't be assumed that just modifying
the BLS files is enough for those changes to be reflected in the boot
menu. Instead, grub2-mkconfig is executed so the BLS can be parsed and
produce a grub config file that can be used by any Petitboot version.
Resolves: rhbz#1636039
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
So what's happened here is this:
- we planned on not having the grubby binary in this package at all
anymore
- when we did test builds like that, find-debuginfo.sh broke
- since it was completely inconsequential, we disabled building
debuginfo
- then we re-thought the package layout, and decided to build that
binary anyway, but forgot to turn debuginfo back on
- also we build the binary as -fPIE, which file(1) says is a "shared
object"
- brp-strip does not act on shared objects, so it didn't strip
As a result, rpmdiff noticed our binary was not stripped.
This patch re-enables debuginfo, which will cause our binary to get
stripped, as well as to have the correct debuginfo packages in the
output.
Related: rhbz#1619344
Signed-off-by: Peter Jones <pjones@redhat.com>
We need to cary this in f29 until we have the anaconda patches in and
get grubby out of the default install, so we'll have BLS configs and not
need grubby to update them.
Signed-off-by: Peter Jones <pjones@redhat.com>
Add a grubby wrapper script that allows to manage BootLoaderSpec files by
using the same command line options supported by the grubby tool. This is
provided for backward compatibility for grubby users that swtich to BLS.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
When grubby is not installed, the zipl configuration has to be changed
to use the BLS configuration files.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
