Bug 1215557 - After upgrading the system from sle12sp5 to sle15sp6, OS fails to boot from snapshot with error "grub_tpm_measure" not found
Summary: After upgrading the system from sle12sp5 to sle15sp6, OS fails to boot from s...
Status: RESOLVED INVALID
Alias: None
Product: PUBLIC SUSE Linux Enterprise Server 15 SP6
Classification: openSUSE
Component: Bootloader (show other bugs)
Version: unspecified
Hardware: x86-64 Other
: P4 - Low : Normal
Target Milestone: ---
Assignee: Michael Chang
QA Contact:
URL: https://openqa.suse.de/tests/12220201...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-21 08:06 UTC by Richard Fan
Modified: 2023-09-22 05:46 UTC (History)
4 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments
grub-cfg (12.04 KB, text/plain)
2023-09-21 08:10 UTC, Richard Fan
Details
y2log (2.35 MB, application/x-bzip)
2023-09-21 08:10 UTC, Richard Fan
Details
snapper.lst (927 bytes, text/plain)
2023-09-21 08:11 UTC, Richard Fan
Details
screen shot (35.08 KB, image/png)
2023-09-21 08:13 UTC, Richard Fan
Details
autoyast file (11.40 KB, text/xml)
2023-09-21 08:15 UTC, Richard Fan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Fan 2023-09-21 08:06:13 UTC
## Observation

The issue can be found with my new qcow2 image installed via autoyast.
https://openqa.suse.de/tests/12219772, I will also upload the autoyast configuration file as well.

openQA test in scenario sle-15-SP6-Migration-from-SLE12-SPx-x86_64-offline_sles12sp5_media_all_full_support_img@64bit fails in
[snapper_rollback](https://openqa.suse.de/tests/12220201/modules/snapper_rollback/steps/1)


## Reproducible

1. Install the system sle12sp5 via autoyast and select all patterns
2. upgraded it to sle15sp6
3. try to rollback to original snapshot
4. we can hit the issue mention at (https://openqa.suse.de/tests/12220201/modules/snapper_rollback/steps/1 [I will try to upload the pic later]

## Logs

Please see attached logs
Comment 1 Richard Fan 2023-09-21 08:10:07 UTC
Created attachment 869641 [details]
grub-cfg
Comment 2 Richard Fan 2023-09-21 08:10:35 UTC
Created attachment 869642 [details]
y2log
Comment 3 Richard Fan 2023-09-21 08:11:25 UTC
Created attachment 869643 [details]
snapper.lst
Comment 4 Richard Fan 2023-09-21 08:13:01 UTC
Created attachment 869644 [details]
screen shot
Comment 5 Richard Fan 2023-09-21 08:15:04 UTC
Created attachment 869645 [details]
autoyast file
Comment 6 Richard Fan 2023-09-21 08:18:39 UTC
I am not sure if current logs and reproduce steps are fine for your kindly investigation.

Please feel free to let me know if any info required.
Comment 7 Michael Chang 2023-09-21 08:54:31 UTC
(In reply to Richard Fan from comment #6)
> I am not sure if current logs and reproduce steps are fine for your kindly
> investigation.
> 
> Please feel free to let me know if any info required.

Could you please help to attach the files after system migrated to 15SP5 ?

1. /etc/sysconfig/bootloader
2. /var/log/pbl.log

And also the command output?

3. btrfs sub list /
4. efibootmgr -v

It seems grub is loading external modules plus it is in an old snapshot for 2.02, this should not happen in our default btrfs configuration and secure boot image. The secure boot image should already have the needed commands to boot a kernel and also the prefix directory for grub modules is exempted from rollback ...
Comment 8 Richard Fan 2023-09-21 09:00:06 UTC
(In reply to Michael Chang from comment #7)
> (In reply to Richard Fan from comment #6)
> > I am not sure if current logs and reproduce steps are fine for your kindly
> > investigation.
> > 
> > Please feel free to let me know if any info required.
> 
> Could you please help to attach the files after system migrated to 15SP5 ?
> 
> 1. /etc/sysconfig/bootloader
> 2. /var/log/pbl.log
> 
> And also the command output?
> 
> 3. btrfs sub list /
> 4. efibootmgr -v
> 
> It seems grub is loading external modules plus it is in an old snapshot for
> 2.02, this should not happen in our default btrfs configuration and secure
> boot image. The secure boot image should already have the needed commands to
> boot a kernel and also the prefix directory for grub modules is exempted
> from rollback ...

Before I provide the info you required. one thing to mention is the vm is Legacy bios boot rather than UEFI secureboot
Comment 9 Richard Fan 2023-09-22 01:26:58 UTC
With kindly comment from Michael. the issue may have something to do with the partition setting on my autoyast file.

1. I set the disk label to gpt [but for sle12spx, it should be msdos by default]
2. A wrong subvolume is created which is used to be set for ppc64le `grub2/powerpc-ieee1275`

Let me try to update the autoyast configuration file and will close it if the issue can't be reproduced.
Comment 10 Michael Chang 2023-09-22 04:15:21 UTC
(In reply to Richard Fan from comment #9)
> With kindly comment from Michael. the issue may have something to do with
> the partition setting on my autoyast file.
> 
> 1. I set the disk label to gpt [but for sle12spx, it should be msdos by
> default]
> 2. A wrong subvolume is created which is used to be set for ppc64le
> `grub2/powerpc-ieee1275`

In addition to correct name the subvolume, you'll also have to make sure it is used by /boot/grub2/i386-pc. The idea is  to prevent installed grub modules from being inadvertently reverted by rollback operation, results in ABI breakage with core image formerly embedded to MBR or bios boot partition.
Comment 11 Richard Fan 2023-09-22 05:46:49 UTC
(In reply to Michael Chang from comment #10)
> (In reply to Richard Fan from comment #9)
> > With kindly comment from Michael. the issue may have something to do with
> > the partition setting on my autoyast file.
> > 
> > 1. I set the disk label to gpt [but for sle12spx, it should be msdos by
> > default]
> > 2. A wrong subvolume is created which is used to be set for ppc64le
> > `grub2/powerpc-ieee1275`
> 
> In addition to correct name the subvolume, you'll also have to make sure it
> is used by /boot/grub2/i386-pc. The idea is  to prevent installed grub
> modules from being inadvertently reverted by rollback operation, results in
> ABI breakage with core image formerly embedded to MBR or bios boot partition.

Yup, it is there and job is passed now. 
https://openqa.suse.de/tests/12229615

Let me close it for now since it is not a product issue.

Only the wired thing for me is that it didn't report any error during the installation phase.