Bug 1978449
| Summary: | [RHEL-8.5] [anaconda] request option to ignore "Failed to set new efi boot target" message | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | PaulB <pbunyan> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.5 | CC: | bcl, bgray, efuller, ernunes, gbaker, jbastian, jstodola, msalter, natashba, pbunyan, pjones, rasibley, rvr, sbarcomb, ttracy |
| Target Milestone: | beta | Flags: | pbunyan:
needinfo-
|
| Target Release: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-12-02 13:51:26 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: | |||
Anaconda team, May we have an option to override this issue, please? Something like: bootloader --ignore-errors or some means of answering yes auto-magically. Best, pbunyan Please attach the logs from /tmp/*log as individual text/plain attachments. This is a real error message and should not be ignored, it means that the bootloader could not be setup. program.log may contain useful output from the efibootmgr command when it tries to update the boot order. (In reply to Brian Lane from comment #2) > Please attach the logs from /tmp/*log as individual text/plain attachments. > > This is a real error message and should not be ignored, it means that the > bootloader could not be setup. program.log may contain useful output from > the efibootmgr command when it tries to update the boot order. Brian, From one of the systems I installed (and opened this BZ for), I see nothing I could share in /tmp. Is there anything in /var/log that would be helpful? Particularly, anaconda.log and/or syslog? [root@nvidia-jetson-agx-01 anaconda]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.4 (Ootpa) [root@nvidia-jetson-agx-01 anaconda]# uname -a Linux nvidia-jetson-agx-01.khw4.lab.eng.bos.redhat.com 4.18.0-305.el8.aarch64 #1 SMP Thu Apr 29 08:58:53 EDT 2021 aarch64 aarch64 aarch64 GNU/Linux [root@nvidia-jetson-agx-01 anaconda]# ls /tmp systemd-private-c8cc64f5199a41ccb5f134951af7c97e-chronyd.service-jtnmig [root@nvidia-jetson-agx-01 anaconda]# ls /var/log/ anaconda btmp chrony dnf.log firewalld hawkey.log-20210613 hawkey.log-20210627 kdump.log private samba tuned audit btmp-20210701 dnf.librepo.log dnf.rpm.log hawkey.log hawkey.log-20210620 hawkey.log-20210704 lastlog rhsm sssd wtmp [root@nvidia-jetson-agx-01 anaconda]# Best, pbunyan If it isn't in /tmp then there should be a /var/tmp/anaconda/program.log which should contain the output from running efibootmgr which is what tries to set the new boot target. (In reply to Brian Lane from comment #4) > If it isn't in /tmp then there should be a /var/tmp/anaconda/program.log > which should contain the output from running efibootmgr which is what tries > to set the new boot target. Nope. [root@nvidia-jetson-agx-01 tmp]# pwd /var/tmp [root@nvidia-jetson-agx-01 tmp]# ls systemd-private-c8cc64f5199a41ccb5f134951af7c97e-chronyd.service-DR5E7e [root@nvidia-jetson-agx-01 tmp] But there is a program.log in /var/log/anaconda: [root@nvidia-jetson-agx-01 anaconda]# pwd /var/log/anaconda [root@nvidia-jetson-agx-01 anaconda]# ls anaconda.log journal.log packaging.log BZ1978449-anaconda-program.log ks-script-0kbliknx.log program.log dbus.log ks-script-1lv2x69r.log storage.log dnf.librepo.log ks-script-43rd1mvb.log syslog hawkey.log lvm.log X.log pbunyan uploaded /var/log/anaconda/program.log Best, pbunyan N That's odd. Is this from right after the failure or from after a reboot? It should be in /tmp/program.log right after the failure. Something else to look at is the output from 'efibootmgr -v' and the kernel logs after the failure to see if they mention problems with the efivars. Hi Brian, efibootmgr fails because there is no runtime write support for boot variables. The variable store is on an sdcard which Nvidia wants to expose to the linux kernel. Because the firmware and kernel cannot share the same device, the firmware tells efibootmgr that there is no support. But if we tell anaconda to continue with the install anyway, the firmware will see the new boot entry and add it to the boot list. I don't think this is a valid way to implement UEFI, reassigning to efibootmgr. No, this is a bad plan. This isn't the right way to support EBBR-like devices *at all*. What we need to do is: 1) create another shim-$EFIARCH package (as part of the shim-signed srpm) along the same lines as grub2-efi-$EFIARCH-cdboot, that puts things at paths specifically useful to live-only images (including cloud and EBBR-like use-cases) 2) make kernel query the RuntimeServicesSupported EFI variable and expose it somewhere in sysfs before calling ExitBootServices() 3) make anaconda check if RuntimeServicesSupported has all of EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME, EFI_RT_SUPPORTED_GET_VARIABLE, and EFI_RT_SUPPORTED_SET_VARIABLE set (i.e. var & 0x70 == 0x70), and if not, select shim-$EFIARCH-live and grub2-efi-$EFIARCH-cdboot instead of shim-$EFIARCH and grub2-efi-$EFIARCH. (We can add a mechanism to efibootmgr for the variable check if we need to.) Anyway, I'm giving this high-level overview back to anaconda. Feel free to file more bugs for the components it depends on. (In reply to Peter Jones from comment #10) > No, this is a bad plan. This isn't the right way to support EBBR-like > devices *at all*. What we need to do is: > > 1) create another shim-$EFIARCH package (as part of the shim-signed srpm) > along the same lines as grub2-efi-$EFIARCH-cdboot, that puts things at paths > specifically useful to live-only images (including cloud and EBBR-like > use-cases) > 2) make kernel query the RuntimeServicesSupported EFI variable and expose it > somewhere in sysfs before calling ExitBootServices() > 3) make anaconda check if RuntimeServicesSupported has all of > EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME, EFI_RT_SUPPORTED_GET_VARIABLE, and > EFI_RT_SUPPORTED_SET_VARIABLE set (i.e. var & 0x70 == 0x70), and if not, > select shim-$EFIARCH-live and grub2-efi-$EFIARCH-cdboot instead of > shim-$EFIARCH and grub2-efi-$EFIARCH. (We can add a mechanism to efibootmgr > for the variable check if we need to.) > > Anyway, I'm giving this high-level overview back to anaconda. Feel free to > file more bugs for the components it depends on. Brain, Any follow up on this issue? Just trying to keep this BZ from getting stale. Thank you. Best, pbunyan All, The Nvidia Jetson Xavier platform is no longer supported. Closing this BZ with "wont fix" best, pbunyan |
Description of problem: When installing Nvidia Jetson Xavier devices, we hit the following issue: The following error occurred while installing the boot loader. The system will not be bootable. Would you like to ignore this and continue with installation? Failed to set new efi boot target. This is most likely a kernel or firmware bug. Please respond 'yes' or 'no': If we just respond with yes the install will complete. However, this manual intervention is a problem for automation(obviously) :/ Version-Release number of selected component (if applicable): anaconda: 33.16.5.1-1.el8 distro: RHEL-8.5.0-20210626.n.0 kernel: 4.18.0-316.el8 How reproducible: 100 % Steps to Reproduce: 1. Install Nvidia Jetson Xavier device with RHEL-8.5* 2. Actual results: ---%<-snip->%--- The following error occurred while installing the boot loader. The system will not be bootable. Would you like to ignore this and continue with installation? Failed to set new efi boot target. This is most likely a kernel or firmware bug. Please respond 'yes' or 'no': ---%<-snip->%--- Expected results: Successful installation of device. Additional info: