This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
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 2107634 - [RHEL-9] System boots latest kernel without TBOOT on kernel update
Summary: [RHEL-9] System boots latest kernel without TBOOT on kernel update
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: tboot
Version: 9.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Tony Camuso
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 2107609
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-15 14:41 UTC by Renaud Métrich
Modified: 2023-09-08 17:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-03 01:53:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-2081 0 None Migrated None 2023-09-03 01:53:12 UTC
Red Hat Issue Tracker RHELPLAN-127875 0 None None None 2022-07-15 14:45:18 UTC

Description Renaud Métrich 2022-07-15 14:41:16 UTC
Description of problem:

This is somehow a continuation of BZ #2107621 and related to RFE #2107618.
Upon updating/reinstalling a kernel, the Grub install script /lib/kernel/install.d/20-grub.install usually overwrites the "saved_entry" setting, which leads to booting the newly installed kernel without TBOOT.

Probably the admin would expect to boot the newly installed kernel with TBOOT if it was booted with TBOOT just before.

But it seems there is no way to detect if we were under TBOOT or not.
One way to do this is to rely on "saved_entry" *before* the kernel update/reinstallation occurred.
This however assumes that "saved_entry" can be trusted, hence "save_default=true" is also present in grubenv (this is controlled by GRUB_SAVEDEFAULT=true in /etc/default/grub which is NOT the default).

Assuming it's the case, and because TBOOT and BLS are for now incompatible (see RFE #2107618), in order to boot with newly installed kernel, we would need 2 install scripts:

1. One executing before /lib/kernel/install.d/20-grub.install, responsible to save the "saved_entry" state (which is the one before updating the kernel)

  If "saved_entry" is not a TBOOT entry, nothing has to be done.

2. One executing after /lib/kernel/install.d/20-grub.install, responsible to do the fixing to boot the newly installed kernel under TBOOT, assuming the "saved_entry" before 20-grub.install executed was a TBOOT entry (step 1).

Version-Release number of selected component (if applicable):

tboot-1.10.2-6.el9.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Boot a kernel with TBoot
2. Update the kernel (or install another kernel)
3. Reboot

Actual results:

Newly installed kernel without TBOOT is executed

Expected results:

Newly installed kernel with TBOOT is executed

Comment 1 Renaud Métrich 2022-07-15 14:53:29 UTC
Additionally for now, because TBOOT is not fully integrated into system boot, the admin needs to rebuild the Grub menu upon kernel update, or else no TBOOT entry will be present.
I think this needs to be automated and can be automated through the proposed 2 installed scripts.
However, since modifying /boot/grub2/grub.cfg is risky, it would be better (unless there is BLS integration) to have TBOOT create its own configuration file, e.g. /boot/grub2/tboot which will be re-generated during the kernel installation by the install script. /boot/grub2/grub.cfg snippet would just source that new file, similar to "custom.cfg" for example.

Comment 2 Tony Camuso 2022-08-26 18:03:19 UTC
Please try the following after updating the kernel.

Please try the following:

# tbootentry=$(grep submenu /boot/grub2/grub.cfg | cut -d'"' -f2)

# echo $tbootentry  # <- make sure you got a valid 'tboot-<version>-<revision>'

# grub2-set-default "$tbootentry"
 
Or, if you only want tboot for the next reboot, and not as the default ...

# grub2-reboot "$tbootentry"

Comment 3 Tony Camuso 2022-08-26 19:07:51 UTC
If the grub2-set-default solution is unacceptable, then use this ....

# LATEST_TBOOT_ENTRY="$(grep -w ^submenu /boot/grub2/grub.cfg | cut -d'"' -f2)"

# /usr/bin/grub2-editenv - set saved_entry="$LATEST_TBOOT_ENTRY"

Comment 4 Tony Camuso 2022-09-08 18:29:14 UTC
This can't be fixed until bootloader supports multiboot and grubby and lists multiboot entries.

See bz #2107609
and bz #2107618

Comment 8 Doug Ledford 2023-08-31 15:50:59 UTC
This bug is scheduled for migration to Jira.  When that happens, this bugzilla issue will be permanently closed with the status MIGRATED and all future interaction on this issue will need to happen in the Jira issue.  The new issue will be part of the RHEL project (a project for Jira only issues, which will sync once, then close the bugzilla issue and all future updates will happen in Jira), not part of the RHELPLAN project (which is part of the automated bugzilla->Jira mirroring and which allows ongoing updates to the bugzilla bug and syncs those updates over to Jira).

For making sure you have access to Jira in order to continue accessing this issue, follow one of the appropriate knowledge base articles:

KB0016394 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
KB0016694 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
KB0016774 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774

For general issues with Jira, open a ticket with rh-issues

Comment 9 RHEL Program Management 2023-09-03 01:52:33 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 10 RHEL Program Management 2023-09-03 01:53:16 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.

Comment 11 Doug Ledford 2023-09-08 17:30:47 UTC
Additional information on creating a Jira account to access the migrated issue can be found here:

https://access.redhat.com/articles/7032570


Note You need to log in before you can comment on or make changes to this bug.