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.
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?
(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.
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.
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".
If this bug does not require documentation, please set the "requires_doc_text" flag to "-". Otherwise, please supply doc text.
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.
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days