RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1978226 - RFE: grubby: apply current arguments to future kernels
Summary: RFE: grubby: apply current arguments to future kernels
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: grubby
Version: 8.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: beta
: ---
Assignee: Bootloader engineering team
QA Contact: Release Test Team
Jana Heves
URL:
Whiteboard:
: 2008131 (view as bug list)
Depends On: 1969362
Blocks: 1969483 2026666 2129740
TreeView+ depends on / blocked
 
Reported: 2021-07-01 11:08 UTC by Marta Lewandowska
Modified: 2022-11-08 12:54 UTC (History)
7 users (show)

Fixed In Version: grubby-8.40-45.el8
Doc Type: Bug Fix
Doc Text:
.`grubby` now passes arguments to future kernels When installing a newer version of the kernel, the `grubby` tool did not pass the kernel command-line arguments from the previous kernel version. As a consequence, the GRUB boot loader ignored user settings. With this fix, the user settings now persist after installing the new kernel version.
Clone Of:
Environment:
Last Closed: 2022-11-08 10:56:24 UTC
Type: Bug
Target Upstream Version:
Embargoed:
jsvarova: needinfo-

Attachments (Terms of Use)
/boot/loader/entries conf files (518 bytes, application/gzip)
2021-07-01 11:08 UTC, Marta Lewandowska 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RTT-4608 0 None None None 2022-06-03 20:42:39 UTC
Red Hat Issue Tracker RTT-4609 0 None None None 2022-06-03 20:42:44 UTC
Red Hat Issue Tracker RTT-4610 0 None None None 2022-06-03 20:42:48 UTC
Red Hat Product Errata RHBA-2022:7799 0 None None None 2022-11-08 10:56:33 UTC

Description Marta Lewandowska 2021-07-01 11:08:19 UTC 
Created attachment 1796767 [details]
/boot/loader/entries conf files

Description of problem:
SMT (Simultaneous multithreading) disabled by the user on the kernel command line does not remain disabled after installing a newer version of the kernel package

Version-Release number of selected component (if applicable):
grubby-8.40-41.el8

How reproducible:
always (x86-64)
BIOS

Steps to Reproduce:
1. disable SMT: run "grubby --args=nosmt --update-kernel=DEFAULT"
2. reboot system and ensure that SMT is disabled: "nosmt" is present in /proc/cmdline after reboot
3. install new kernel + dependencies
4. reboot automatically into new kernel and check if SMT is disabled

Actual results:
SMT is enabled in new kernel

Expected results:
SMT remains disabled in new kernel

Additional info:
grub2-editenv list: saved_entry=73253daadebc4008a2e458a5a4216a69-4.18.0-319.el8.x86_64
kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet 
boot_success=0
Comment 1 Robbie Harwood 2022-03-18 16:53:38 UTC 
*** Bug 2008131 has been marked as a duplicate of this bug. ***
Comment 3 Jiri Kortus 2022-05-03 14:07:50 UTC 
Please note that this should, as I perceive it, apply also to kernel downgrades.
Comment 4 Robbie Harwood 2022-06-02 20:08:04 UTC 
> 1. disable SMT: run "grubby --args=nosmt --update-kernel=DEFAULT"

DEFAULT here causes it to be applied to the entry which is the default one, not all entries.  I believe this would work if one said --update-kernel=ALL instead.

However, if the machine is not rebooted (your step 2), it may not.  I'd like to use this bug as the RHEL-8 equivalent of #1969362 - to fix the behavior for new kernel installations after setting an ALL.
Comment 5 Marta Lewandowska 2022-06-17 11:01:52 UTC 
fwiw, I tested both --update-kernel=DEFAULT and --update-kernel=ALL, and you're right, Robbie, that the latter works even with the older version of grubby on all arches except s390x, even without the reboot. The new version grubby-8.40-43.el8, unfortunately, acts in the same way: works for all arches except s390. But, it also does not appear to break anything...

https://beaker.engineering.redhat.com/jobs/6725758
Comment 7 Marta Lewandowska 2022-08-15 10:39:56 UTC 
Testing using grubby-8.40-45.el8 passes for all architectures: https://beaker.engineering.redhat.com/jobs/6913883

Setting Verifed: Tested
Comment 10 Marta Lewandowska 2022-08-26 14:50:40 UTC 
grubby-8.40-45.el8.x86_64 is present in nightly compose RHEL-8.7.0-20220826.0

Since this bug was documented, I believe documentation will need to be updated to reflect this [new] behavior..?
Comment 14 Petr Stodulka 2022-10-04 19:15:15 UTC 
Hi, we found several problems with this fix. Checking patches, I guess that it should be:

~~~
diff --git a/grubby-bls b/grubby-bls
index 6357e38..2d18c91 100755
--- a/grubby-bls
+++ b/grubby-bls
@@ -526,8 +526,8 @@ update_bls_fragment() {
 
     if [[ $bootloader = grub2 ]] && [[ ! -f /etc/kernel/cmdline ]]; then
        opts=$(grub2-editenv "${env}" list | grep kernelopts | sed 's/kernelopts=//')
-       if [[ -n $opts ]]; then
-           echo "opts" > /etc/kernel/cmdline
+       if [[ -n "$opts" ]]; then
+           echo "$opts" > /etc/kernel/cmdline
        fi
     fi
~~~

This leads to to one of errors we are hitting when
    # cat /etc/kernel/cmdline
    opts
which produces invalid grub entries with options "opts", so the kernel is unbootable.



There are additional bugs present, e.g. missing 'root=...' on s390x:
~~~~
    [root@localhost yum.repos.d]# cat /etc/kernel/cmdline/
    inst.sshd inst.repo=cdrom inst.ks=cdrom:/ks.cfg nicdelay=60 net.ifnames=0 console=ttysclp0,38400


    [root@localhost yum.repos.d]# grubby --info ALL
    index=0
    kernel="/boot/vmlinuz-4.18.0-425.3.1.el8.s390x"
    args="console=tty0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap net.ifnames=0"
    root="/dev/mapper/rhel-root"
    initrd="/boot/initramfs-4.18.0-425.3.1.el8.s390x.img"
    title="Red Hat Enterprise Linux (4.18.0-425.3.1.el8.s390x) 8.7 (Ootpa)"
    id="7df90c6e34204f03aab8f70bdd5a64f1-4.18.0-425.3.1.el8.s390x"
    index=1
    kernel="/boot/vmlinuz-0-rescue-7df90c6e34204f03aab8f70bdd5a64f1"
    args="console=tty0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap net.ifnames=0"
    root="/dev/mapper/rhel-root"
    initrd="/boot/initramfs-0-rescue-7df90c6e34204f03aab8f70bdd5a64f1.img"
    title="Red Hat Enterprise Linux (0-rescue-7df90c6e34204f03aab8f70bdd5a64f1) 8.7 (Ootpa)"
    id="7df90c6e34204f03aab8f70bdd5a64f1-0-rescue"


    [root@localhost yum.repos.d]# dnf update
    ...[snip]....
    Installing:
     kernel         s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8 8.8 M
    Upgrading:
     bpftool        s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8  12 M
     kernel-headers s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8  10 M
     kernel-tools   s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8 8.9 M
     python3-perf   s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8 9.0 M
    Installing dependencies:
     kernel-core    s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8  30 M
     kernel-modules s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8  10 M
    Installing weak dependencies:
     kernel-devel   s390x 4.18.0-429.el8 brew-task-repo-kernel-4.18.0-429.el8  21 M
    ...[snip]....


    [root@localhost yum.repos.d]# grubby --info ALL
    index=0
    kernel="/boot/vmlinuz-4.18.0-429.el8.s390x"
    args="inst.sshd inst.repo=cdrom inst.ks=cdrom:/ks.cfg nicdelay=60 net.ifnames=0 console=ttysclp0,38400"
    initrd="/boot/initramfs-4.18.0-429.el8.s390x.img"
    title="Red Hat Enterprise Linux (4.18.0-429.el8.s390x) 8.8 (Ootpa)"
    id="7df90c6e34204f03aab8f70bdd5a64f1-4.18.0-429.el8.s390x"
    index=1
    kernel="/boot/vmlinuz-4.18.0-425.3.1.el8.s390x"
    args="console=tty0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap net.ifnames=0"
    root="/dev/mapper/rhel-root"
    initrd="/boot/initramfs-4.18.0-425.3.1.el8.s390x.img"
    title="Red Hat Enterprise Linux (4.18.0-425.3.1.el8.s390x) 8.7 (Ootpa)"
    id="7df90c6e34204f03aab8f70bdd5a64f1-4.18.0-425.3.1.el8.s390x"
    index=2
    kernel="/boot/vmlinuz-0-rescue-7df90c6e34204f03aab8f70bdd5a64f1"
    args="console=tty0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap net.ifnames=0"
    root="/dev/mapper/rhel-root"
    initrd="/boot/initramfs-0-rescue-7df90c6e34204f03aab8f70bdd5a64f1.img"
    title="Red Hat Enterprise Linux (0-rescue-7df90c6e34204f03aab8f70bdd5a64f1) 8.7 (Ootpa)"
    id="7df90c6e34204f03aab8f70bdd5a64f1-0-rescue"
~~~~

See the newly created entry does not contain the "root=" option. So after the reboot system is unbootable again.

This also introduces regression for of in-place upgrades RHEL 8.7 -> RHEL 9.0 (see bug 2129740), where the grub entry for rhel9 could look e.g. like this (see the "opts" string):
~~~
    [root@localhost ~]# grubby --info ALL
    index=0
    kernel="/boot/vmlinuz-5.14.0-70.13.1.el9_0.x86_64"
    args="opts $tuned_params net.ifnames=0"
    initrd="/boot/initramfs-5.14.0-70.13.1.el9_0.x86_64.img $tuned_initrd"
    title="Red Hat Enterprise Linux (5.14.0-70.13.1.el9_0.x86_64) 9.0 (Plow)"
    id="e34284b9133641fca763c5dc2d60499d-5.14.0-70.13.1.el9_0.x86_64"
~~~

Regarding this output, is "$tuned_params" expected value in the args?
Also see bug 1900829 which could be related as well.
The fix for RHEL 9.1 seems to be very different from from this one (bug 1969362) - I haven't tested RHEL 9.1...

This is potential release blocker for RHEL 8.7.
Comment 15 Robbie Harwood 2022-10-05 14:41:07 UTC 
In the future, please keep comments in the other bug.  This simplifies problem investigations.
Comment 16 Petr Stodulka 2022-10-06 08:22:31 UTC 
My mistake, originally I thought the problem is going to be resolved in this bug as I thought it's going to be marked as failedqa regarding the original fix is from my pov invalid.
Comment 22 errata-xmlrpc 2022-11-08 10:56:24 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (grubby bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7799
Note You need to log in before you can comment on or make changes to this bug.