Hey, what happens if you add a new boot entry via the bcfg command from the shell2.0? like: bcfg boot add 0 fs0:\EFI\someloader.efi "My new boot option"
BCDedit /enum firmware , shows that it exists but when I reboot the boot entry is not there. I may try to patch it but I'll end up bricking this board.
I think this is the what we have too look forward to, if you want to boot another OS you will need to have Windows installed and use windows boot manager to do it. I haven't sat down and really analyzed the code yet but clearly it is looping through the boot entry's looking for "Windows Boot Manager" then doing something with the boot order. also it looks like a compile time option, if r8d is set to 1 the unpleasantness happens if it is set to 2 then the unpleasantness does not happen.
That sounds more like a bug from msi. Iwould write to the support or get another board. Personally I use rEFIt to choose which OS to boot.
even if it is just a bug, I want to know why "Windows Boot Manager" if being searched for in the boot entries it could be that the code is making sure that "Windows Boot Manager" is the default boot entry when no other valid boot entry's are found and is inadvertently dropping the other entry's. also no response from MSI tech support, if I RMA it I would receive another board with the same problem.
That is also hardcoded in my firmware just like Efi Internal Shell. If found it will use that string in the boot options menu. It's part of the auto detection in case that you clear nvram.
and when I change the description of the bootmgr entry from "Windows Boot Manager" to "Win" the boot entry disappears from the list of entry's
I took some time to analyze the code, and there is no doubt about it it delete's any entry that does not have the label of "Windows Boot Manager" first it does a string compare to "Windows Boot Manager" the result is returned on rax, if rax is 0 then the function exits, else is sets up and calls RuntimeServices->SetVariable with the attributes set to 0 and the size set to 0 which will delete the boot entry. I have also found an unused function that which look's more like the boot entry function in my Asus board. code exists in the bios to do the job right but is unused why? I have no choice but to conclude that this code was developed passed code review and made it to production on purpose. Code: sub_180000758proc near; CODE XREF: sub_1800007F0+33p ; sub_18000083C+45p var_38= qwordptr -38h var_28= byte ptr -28h arg_0= qwordptr 8 mov[rsp+arg_0], rbx pushrdi subrsp, 50h movrbx, rdx movrdi, rcx cmpr8d, 1 jnzshort loc_1800007D9 movrcx, [rbx+18h] leardx, aWindowsBootMan ; "WindowsBoot Manager" movr8d, 14h callStrCmp testrax, rax jzshort Exit moveax, 0FFFFh cmp[rbx+40h], ax jzshort loc_1800007CC movzxr8d, word ptr [rbx+40h] leardx, aBoot04x; "Boot%04X" learcx, [rsp+58h+var_28] callsub_180002960 movrax, cs:RunTimeServices and[rsp+58h+var_38], 0 leardx, unk_180035DF8 ; GUID learcx, [rsp+58h+var_28] xorr9d, r9d; Size = 0 xorr8d, r8d; Attributes = 0 callqword ptr [rax+58h] ; RuntimeServices->SetVariable loc_1800007CC:; CODE XREF: sub_180000758+3Aj movrdx, rbx movrcx, rdi callsub_18000E7A8 jmpshort Exit ; --------------------------------------------------------------------------- loc_1800007D9:; CODE XREF: sub_180000758+14j cmpr8d, 2 jnzshort Exit anddword ptr [rdx+10h], 0FFFFFFFEh Exit:; CODE XREF: sub_180000758+2Fj ; sub_180000758+7Fj ... movrbx, [rsp+58h+arg_0] addrsp, 50h poprdi retn sub_180000758endp
What about patching sub_180000758 or replace the 2 calls to it with calls to the right code? Or compile rEFIt and add it as Windows Boot Manager and choose which OS to boot from its gui. rEFIt does a search on the EFI Partition for all kind of efi bootloader. grub, win, etc... btw does your mobo support the driver-XXXX variable to load additional drivers?