Bug 1765250

Summary:	After upgrade RHVH did not boot into latest layer by default on UEFI machine.
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Ameya Charekar <achareka>
Component:	redhat-virtualization-host	Assignee:	Yuval Turgeman <yturgema>
Status:	CLOSED ERRATA	QA Contact:	peyu
Severity:	urgent	Docs Contact:
Priority:	high
Version:	4.3.6	CC:	aromito, cshao, jkho, lsvaty, mavital, nashok, nlevy, pelauter, peyu, qiyuan, sbonazzo, sgoodman, sirao, weiwang, yaniwang, yturgema
Target Milestone:	ovirt-4.3.8	Keywords:	ZStream
Target Release:	4.3.8
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	imgbased-1.1.14	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-13 15:43:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Node	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ameya Charekar 2019-10-24 15:43:36 UTC

Description of problem:
UEFI Hosts have successfully upgraded to layer rhvh-4.3.5.4-0.20190920 from layer rhvh-4.3.5.3-0.20190805.0 but default selection is old layer rhvh-4.3.5.3-0.20190805.0 (second entry in boot menu) and not the new layer which is first entry in boot menu.


Version-Release number of selected component (if applicable):
efibootmgr-17-2.el7.x86_64
efivar-libs-36-12.el7.x86_64
grub2-efi-x64-2.02-0.80.el7.x86_64


How reproducible:
Always on customer's all UEFI hosts.


Steps to Reproduce:
1. Upgrade UEFI host from rhvh-4.3.5.3-0.20190805.0 to rhvh-4.3.5.4-0.20190920
2. Reboot
3.

Actual results:
Default boot option selected is rhvh-4.3.5.3-0.20190805.0 even though it is second entry.

Expected results:
Boot into latest layer

Additional info:
Issue is after upgrading to layer rhvh-4.3.5.3-0.20190805.0, /boot/grub2/grubenv is regular file and no longer a symlink to /boot/efi/EFI/redhat/grubenv.

Hence /boot/efi/EFI/redhat/grubenv has old layer's entry rhvh-4.3.5.3-0.20190805.0 caused second entry in boot menu to be default selection.

Manually copying /boot/grub2/grubenv file to /boot/efi/EFI/redhat/grubenv resolved this issue but same issue persist after upgrading to latest layer.

And each time it is required to copy /boot/grub2/grubenv file to /boot/efi/EFI/redhat/grubenv manually.

Even if we create symlink manually (ln -s ../efi/EFI/redhat/grubenv /boot/grub2/grubenv) but after reboot /boot/grub2/grubenv is again a regular file.

Comment 12 peyu 2019-12-23 02:06:57 UTC

I can not reproduce this bug, but I will do some basic upgrade tests on UEFI machines to verify if there is any problem with the patch.
Would you help to verify this bug once move to ON_QA status?

Comment 13 Ameya Charekar 2019-12-24 01:13:50 UTC

(In reply to peyu from comment #12)
> I can not reproduce this bug, but I will do some basic upgrade tests on UEFI
> machines to verify if there is any problem with the patch.
> Would you help to verify this bug once move to ON_QA status?

Sure but I am also unable to reproduce this bug in my lab environment.

Comment 14 peyu 2020-01-09 08:40:44 UTC

The reporter and I cannot reproduce this bug in the lab environment. In order not to affect the normal work, I will add "qa_ack +" flag.
In the latest version(rhvh-4.3.8.1-0.20200105.0+1 el7.7), I tested many times and did not reproduce this bug.
I will do some more upgrade tests on UEFI machines, if this bug is still not reproducible after multiple tests, it will be considered as fixed.

Comment 16 peyu 2020-01-16 10:30:36 UTC

1. Test based on "redhat-virtualization-host-4.3.8-20200105.0.el7_7"
A few days ago, I selected several build from RHVH-4.1, RHVH-4.2 and RHVH-4.3 and upgraded them to "redhat-virtualization-host-4.3.8-20200105.0.el7_7" on UEFI test server. This bug did not reproduced.

2. Test based on "redhat-virtualization-host-4.3.8-20200115.0.el7_7"
The builds I choose to upgrade:
1) RHVH-4.1-20180426.0-RHVH-x86_64-dvd1.iso
2) RHVH-4.2-20190417.0-RHVH-x86_64-dvd1.iso
3) RHVH-4.3-20190806.1-RHVH-x86_64-dvd1.iso (rhvh-4.3.5.3-0.20190805.0 where the reporter found this bug)
4）redhat-virtualization-host-4.3.6-20191108.0.el7_7 (The build that "/boot/grub2/grubenv" is not symlink to "/boot/efi/EFI/redhat/grubenv")
5）redhat-virtualization-host-4.3.7-20191211.0.el7_7 (rhvh-4.3.7.1-0.20191211.0+1 el7.7)

Upgrade the above builds to "redhat-virtualization-host-4.3.8-20200115.0.el7_7" on UEFI test server and check if system can enter the default boot entry.

This issue has still not been reproduced.

I will move this bug to "VERIFIED".

Comment 17 Steve Goodman 2020-02-06 10:21:33 UTC

If this bug does not require documentation, please set the "requires_doc_text" flag to "-".

Otherwise, please supply doc text.

Comment 19 Joshua Kho 2020-02-12 01:32:09 UTC

Thanks, Siddhant.

Hi Team, Josh here, the customer success manager for a strategic telco customer in Malaysia called Digi. To share business impact and context, Digi has 'decided to put RHV expansion on hold due to frequent host reboot caused by external storage'. Further, Telenor--the parent group of this strategic customer--might consider using upstream kvm (rdo) [nokia cbis 19 and 20] instead of rhv, if this fix takes too long.

If you have questions or feedback, or need help with anything, please feel free to let me know. Thank you.

Comment 24 errata-xmlrpc 2020-02-13 15:43:12 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, 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-2020:0503

Comment 27 Red Hat Bugzilla 2024-01-06 04:26:59 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days