jlobue10 / SteamDeck_rEFInd

Simple rEFInd install script for the Steam Deck (with GUI customization)
MIT License
520 stars 50 forks source link

Windows 11 boots as default after initially working after rEFInd install. #27

Closed johnlietzke closed 1 year ago

johnlietzke commented 1 year ago

Wonderful project and great documentation.

Unfortunately Windows 11 is hijacking the boot order after every restart where Windows boots. This happens despite rerunning the bootsequence manually in Windows.

I have followed every step of the instructions to no avail.

Any idea what is going on? I may just be daft and can not properly follow clear instructions.

jlobue10 commented 1 year ago

Yes, no worries. Thank you for the kind words and appreciation. Can you give me a printout of what you see when you run efibootmgr from a SteamOS command line? This will provide me with valuable troubleshooting information.

Does rEFInd boot properly after SteamOS was the last booted OS? This would imply that the systemctl daemon is installed properly and doing its job, even if the Windows EFI entry is active, as I suspect it might be.

johnlietzke commented 1 year ago

Firmware Boot Manager

identifier {fwbootmgr} displayorder {bootmgr} {30fc38b0-9087-11ed-8000-806e6f6e6963} {8718ad3f-907e-11ed-bffe-806e6f6e6963} {8718ad3c-907e-11ed-bffe-806e6f6e6963} {8718ad3d-907e-11ed-bffe-806e6f6e6963} {8718ad3e-907e-11ed-bffe-806e6f6e6963} timeout 0

Windows Boot Manager

identifier {bootmgr} device partition=\Device\HarddiskVolume1 path \EFI\Microsoft\Boot\bootmgfw.efi description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {6b64bf2b-8cdb-11ed-9a18-e5cba24cc1ff} displayorder {current} toolsdisplayorder {memdiag} timeout 30

Firmware Application (101fffff)

identifier {30fc38b0-9087-11ed-8000-806e6f6e6963} device partition=\Device\HarddiskVolume1 path \EFI\refind\refind_x64.efi description rEFInd

Firmware Application (101fffff)

identifier {8718ad3c-907e-11ed-bffe-806e6f6e6963} description EFI USB Device

Firmware Application (101fffff)

identifier {8718ad3d-907e-11ed-bffe-806e6f6e6963} description EFI DVD/CDROM

Firmware Application (101fffff)

identifier {8718ad3e-907e-11ed-bffe-806e6f6e6963} description EFI Network

Firmware Application (101fffff)

identifier {8718ad3f-907e-11ed-bffe-806e6f6e6963} device partition=\Device\HarddiskVolume1 path \EFI\steamos\steamcl.efi description SteamOS PS C:\Windows\system32>

johnlietzke commented 1 year ago

Refind does work properly after a SteamOS reboot.

It took several tries to get bcdedit /enum Firmware to work. I had to go into Scheduled Task and manually run the task in order to pull the log.

jlobue10 commented 1 year ago

Okay. I'd also like to see this equivalent from SteamOS (with efibootmgr) if you get a chance (mainly for curiosity, but not necessary if this is annoying for you to get). I see that the rEFInd and SteamOS EFI entries are there.

Is the powershell script that you are trying to run a 1KB size file? Are you trying to run it as administrator (this is required)? I'd suggest downloading the latest release as a zip, or cloning the repository from Windows. If you try to download the powershell script from a webpage, it could be saving it in the wrong format (webpage data included) and would be roughly ~120 - 130KB in size. If you are trying to execute the improperly formatted version of the script, it would error out, and not work correctly.

You can also just create a new .ps1 file, name it whatever you like, and copy and paste the couple of lines from my script that discover the rEFInd entry identifier and automatically set it as next boot's (BootSequence which is missing in your identifier {fwbootmgr} entry section). This script is done this way because it will find the correct identifier for rEFInd, even if it changes in the future. Hopefully, this solves your issue. Please let me know.

johnlietzke commented 1 year ago

I used the script from the zip file just to be on the safe side to begin with.

I redownloaded the zip and dropped a new copy of script into the folder. The query worked perfectly for the logs the first time after reboot.

Here is the SteamOS efibootmgr output:

BootNext: 0001 BootCurrent: 0004 Timeout: 0 seconds BootOrder: 0000,0001,0004,2001,2002,2003 Boot0000 Windows Boot Manager HD(1,GPT,a1d89b5d-de72-7f43-ba26-4bee4ef5c3d9,0x800,0x20000)/File(\EFI\Microso ft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b0039006 4006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330 034003400640034003700390035007d00000000050100000010000000040000007fff0400 Boot0001 rEFInd HD(1,GPT,a1d89b5d-de72-7f43-ba26-4bee4ef5c3d9,0x800,0x20000)/File(\EFI\refind\refind_x 64.efi) Boot0004 SteamOS HD(1,GPT,a1d89b5d-de72-7f43-ba26-4bee4ef5c3d9,0x800,0x20000)/File(\EFI\steamos\steamcl .efi) Boot2001 EFI USB Device RC Boot2002 EFI DVD/CDROM RC Boot2003 EFI Network RC

I am running the latest preview by the way.

jlobue10 commented 1 year ago

Okay, so this is one reason why I like the efibootmgr output better for troubleshooting purposes. I can tell by the * next to the Boot0000 (Windows EFI entry) that it is indeed active. I'd highly recommend disabling it either using EasyUEFI trial from Windows or by running sudo efibootmg -b 0000 -A from a SteamOS recovery image command line (used to work in regular SteamOS, but not currently). This setting should then stay in effect until the next BIOS update that the Steam Deck receives. I much prefer this methodology over renaming EFI files, because when you rename EFI files (another script's method), you will likely run into issues whenever Windows has an update. My version of the script does not have this problem with Windows Updates (just as a little aside and explanation).

Also, I would double check that the path to the powershell script is correct in the scheduled task on Windows side. Since this is a one time manual step, it is possible for human error to occur here. On a fresh boot into Windows, you can tell if the script was effective or not by opening up a Powershell command line window as Administrator and run the bcdedit /enum Firmware command. You should see a BootSequence submenu entry in that identifier {fwbootmgr} entry with the rEFInd identifier next to it. This will confirm the task and script are working properly. With both the systemctl daemon (on SteamOS side) and the powershell script (from Windows side), this script will actually keep rEFInd as the top boot priority, even without disabling the Windows EFI entry. I still recommend disabling it though, especially if you are going to do a triple boot with Batocera or some other Linux distro, etc.

johnlietzke commented 1 year ago

I was fighting disabling the Windows EFI. Works perfect now that it is disabled.

Thanks. I travel frequently and often do not have a keyboard and mouse with me.

Would I be able to boot back into Windows from the USB recover tools and reenable the Windows EFI with EasyUEFI? I know it can be done by command line in SteamOS but looking for an easy quick fix solution on the go.

jlobue10 commented 1 year ago

Yes, you could re-enable the Windows EFI entry any time you like. If you are only running SteamOS and Windows 11 (strictly dual boot), you can actually keep the Windows EFI entry active now as long as both the systemctl daemon and powershell script are both installed and enabled properly.

EasyUEFI is "Easy" to use as name implies, and could be done with the touchscreen on Windows 11, if necessary.

Also, there is nothing inherently wrong with leaving the Windows EFI entry disabled. All that this really means is that if you perform the Volume Down and Power on button combo, the Windows EFI entry (maybe) won't be there (as it's hidden -- possibly a better term). You would still be able to boot into Windows from its EFI file (Volume Up and Power button combo -> Boot From File). No Windows recovery USB would be needed for this. Disabling the Windows EFI entry allows rEFInd to assume the highest boot priority. The way a lot of UEFI firmwares work is that if the Windows EFI file is detected on the EFI system partition (normally in a specific location), and if its EFI entry is active, it will almost always try to assume the top boot priority. This interferes with rEFInd working properly, as rEFInd needs to be the top priority in the boot order to work. Anyways, that's enough for an explanation. Please comment and close if you are satisfied with the solution.