Bug 2107634

Summary: [RHEL-9] System boots latest kernel without TBOOT on kernel update
Product: Red Hat Enterprise Linux 9 Reporter: Renaud Métrich <rmetrich>
Component: tbootAssignee: Tony Camuso <tcamuso>
Status: CLOSED MIGRATED QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.0CC: bdonahue, darcari, tcamuso
Target Milestone: rcKeywords: MigratedToJIRA, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-09-03 01:53:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2107609    
Bug Blocks:    

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