![]() I have not updated my firmware and I have not upgraded any packages in between my posts. But I actually cannot explain it how I got lucky again this time. Just want to report back that some how I managed to add the new boot entry I want using efibootmgr successfully. ![]() Post added at 07:09 PM - Previous post was at 01:46 PM. So, first I must get hold of a *working* user space tool that allows me to manipulate the boot entries. I read that some version of Asus firmware provides interface to add boot entry but unfortunately not my UEFI BIOS firmware. boot/efi/EFI/boot/boot圆4.efi (as per UEFI specification) boot/efi/shell圆4.efi (as suggested by ArchWiki) Some how it only does that for removable-devices, like thumbdrive. As I said before, the version of Asus UEFI BIOS firmware that I currently use does not automatically add a new boot entry when a new bootloader efi or shell efi is installed in the ESP of the disk. I have already read the article in ArchWiki before you posted. When I have time tomorrow, I will see whether I could use Windows BCDEdit to create a new boot entry. I have not upgraded my UEFI BIOS firmware in between my posts in this thread. I don't believe I just got lucky *again* with Win7 installer. Both tests return non-zero exit status silently. I repeated my "efibootmgr -c" test case just now and it still failed. So, I don't believe for my case it is really caused by nvram not enough space. I have also just installed Win7 on my /dev/sda5 with the "Windows Boot Manager" (bootmgfw.efi) installed on /dev/sda1 under /EFI/Microsoft, the Win7 installer also successfully added a new boot entry for Windows Boot Manager permanently. ![]() If I hook up my bootable external drive, thumb-drive, and put in Fedora installation media into my DVD at the same time, they are all dynamically added as new boot entries in the Asus UEFI boot manager. But I know one thing for sure, my nvram still has room for more boot entries. I am not expert enough to understand all the stuffs they spoke off in the bug reports. Last edited by GoinEasy9 17th May 2013 at 05:37 PM. Leaving these around will eventually prevent new UEFI variables from being created."Īlthough I find my /sys/fs/pstore/ directory is empty. They are saved in UEFI NVRAM, which is a very limited resource. "Additionally, ABRT should delete these files from the /sys/fs/pstore/ directory. Could it be that there was a bug in the ASUS UEFI code, or, could it be that NVRAM was cleared during the update? I considered clearing CMOS on the motherboard, but, I figured that would happen once my experimenting was over, and, I was sure I could use efibootmgr in rescue mode.Įdit: Or, could I be the victim of what is explained in the first post of this bugzilla: The first bugzilla link mentions that updating the ASUS UEFI bios solved the problem for some. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |