Fedora Account System
Red Hat Associate
Red Hat Customer
Installation of the system failed: Installing boot loader org.fedoraproject.Anaconda.BootloaderInstallationError: Failed to set new efi boot target. This is most likely a kernel or firmware bug. Asus Zenbook laptop UX363E ---[ System & Environment Information ]--- OS: Fedora Linux 44 (Workstation Edition) Anaconda version: 44.30 Anaconda UI version: 68
Created attachment 2142092 [details] Log file: /tmp/journal.log
Created attachment 2142093 [details] Log file: /tmp/anaconda.log
Created attachment 2142094 [details] Log file: /tmp/storage.log
Created attachment 2142095 [details] Log file: /tmp/program.log
Created attachment 2142096 [details] Log file: /tmp/packaging.log
Created attachment 2142097 [details] Log file: /tmp/anaconda-webui.log
*** Bug 2480342 has been marked as a duplicate of this bug. ***
I've proposed a bug fix in this pull request: https://github.com/rhinstaller/anaconda/pull/7074
*** Bug 2481062 has been marked as a duplicate of this bug. ***
*** Bug 2480598 has been marked as a duplicate of this bug. ***
*** Bug 2479726 has been marked as a duplicate of this bug. ***
*** Bug 2481485 has been marked as a duplicate of this bug. ***
Per https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893 , I believe the purported 'fix' here and its explanation were pure LLM hallucinations and had nothing at all to do with the actual bug. The actual bug is very likely a firmware issue we cannot do anything about, but if there's a real bug anywhere it's in efibootmgr, so re-assigning. Reporter, you may possibly be able to resolve this by updating the system firmware, or deleting some EFI boot manager entries if you have a lot, or...something. All we really know is we tried to create an EFI boot manager entry for Fedora and it failed. Aside from that, as with all the other reports: please do not make yourself the assignee for downstream bugs in components of which you are not a maintainer, or close them prematurely.
Thanks for investigating this further. I was able to resolve the issue and I am assuming it is an issue with the asus laptop uefi. The issue was resolved by deleting the secure boot keys on the motherboard which put the platform mode into setup mode. Secure boot was always turned off but the uefi was in deployed mode. It appears that being in setup mode, allowed efibootmgr write access. The fedora installer then completed successfully. It does seem that split_lock_detect had some influence as it consistently changed the error from 'Cannot allocated memory' when default to 'Failed to remove old efi boot entry' when set to off. The installation succeeded with split_lock_detect=off but I did not test it with it set to on
That's more likely to do with whether there was an existing EFI boot manager entry called "Fedora" or not. If there is one, anaconda attempts to remove it. If that fails we get the "Failed to remove old efi boot entry" error and we never reach the attempt to create the *new* boot manager entry. If there is no existing entry called "Fedora", we go straight to trying to create a new entry.
That explanation makes a lot of sense! I had attributed it to split_lock_detect=off but the timing makes sense with there being a "Fedora" entry there. The uefi appeared to create its own EFI boot manager entries on startup, but these were never capable of booting the system.
I achieved installing windows, parrot os, and fedora on the laptop. I enabled secure boot in contrast to most instructions to disable it, but in this computer ASUS F1605ZA, when you enable it you enter the user mode and it is there that you are able to delete these keys in the key management option found in the UEFI. These keys give windows the edge to change boot order and once that is establish other problems occur with ext4 partitions that parrot uses. So I thought about enabling the boot-loader that Fedora provides but that will not do the trick because when Parrot loads ext4 UEFI re-enables the crypto keys. So if you run Fedora and Windows, it is worth looking at the option to reenable the crypto keys UEFI makes to be sure that only registered OS'es in its boot-loaders remain intact after change is established by UEFI. Regardless, some administrative service are required periodically for this option when enabling it for pc that have windows and fedora installed, if you are not into that like myself, add a administrator password for the UEFI and delete the existing tokens and hope no other update will change the setting in the nearby future. This problem is a system firmware issue, the thing is i installed fedora on the laptop without messing with the keys, and it worked for four days. Regardless i had to do a lot of changes and one day from the other my partition disappeared. After doing the research on the suspected firmware, i figured out that the keys are linked to the problems i encountered periodically, after performing an update on the linux system and rebooted.
*** Bug 2481757 has been marked as a duplicate of this bug. ***
*** Bug 2484056 has been marked as a duplicate of this bug. ***