Open jlobue10 opened 1 year ago
The Windows EFI entry can be disabled successfully when we boot from the SteamOS recovery USB using the same exact command. It can also easily be disabled using the EasyUEFI program from Windows.
Windows seems always to add the entry back after booting on my device for some reason. But the bootsequence-rEFInd-first.ps1
script from your repo fixed this issue
The way that workaround functions is that it is basically setting the BootNext EFI entry to be rEFInd. This needs to be refreshed every boot. It is a workaround that I'd rather not need. Hopefully this is actually an efibootmgr
bug that was introduced in 3.4, and they can find and fix the bug. I think only dual-booters would have noticed this anyways. :)
And yes, the firmware tries aggressively to boot Windows if it finds the Windows EFI file on the /esp
partition. If you manually downgrade the BIOS to 110 and then back to 113, you will see that a Windows EFI is active and likely the SteamOS and rEFInd EFI entries have been deleted. I don't know if this is intentional, but I witnessed this behavior multiple times in my testing.
Hi, thanks for the report!
It might be fixed on Beta - at least, my test here worked fine...
$ efibootmgr -V
version 18
$ efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* EFI Hard Drive (S73YNX0T729287-SAMSUNG MZ9LQ256HBJD-00BVL) PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-D7-21-B5-DE-48)/HD(1,GPT,676c28fe-3c8e-e0
4f-8a04-bfc22731e99d,0x800,0x20000)RC
[...]
Boot2003* EFI Network RC
[...]
$ efibootmgr -b 2003 -A
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* EFI Hard Drive (S73YNX0T729287-SAMSUNG MZ9LQ256HBJD-00BVL) PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-D7-21-B5-DE-48)/HD(1,GPT,676c28fe-3c8e-e0
4f-8a04-bfc22731e99d,0x800,0x20000)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003 EFI Network RC
Can you paste your efibootmgr
version, through the command efibootmgr -V
? Also, what BIOS version are you using?
Cheers!
Thanks for getting back to me. Yes, that verbose output looks much more normal than what I'm seeing on the Stable branch. This gives me hope that this is a bug that's being fixed. :)
The efibootmgr
version is also 18 for me, and my Steam Deck is using the F7A0113
BIOS.
Thanks for getting back to me. Yes, that verbose output looks much more normal than what I'm seeing on the Stable branch. This gives me hope that this is a bug that's being fixed. :)
The
efibootmgr
version is also 18 for me, and my Steam Deck is using theF7A0113
BIOS.
You're welcome =)
What is the kernel version you're running? Also, lemme know your output for:
$ pacman -Q|grep efivar
efivar 38-2
Same output for that.
$ pacman -Q|grep efivar
efivar 38-2
and kernel is:
$ uname -r
5.13.0-valve36-1-neptune
Interesting...
What is your output for: efivar -l |grep BootOrder | xargs -L1 efivar -n
?
$ efivar -l |grep BootOrder | xargs -L1 efivar -n
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootOrder"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 03 00 01 00 00 00 08 00 02 00 01 20 02 20 03 20 |........... . . |
GUID: 59d1c24f-50f1-401a-b101-f33e0daed443
Name: "PhysicalBootOrder"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 03 00 01 00 00 00 08 00 02 00 04 00 05 00 |.............. |
OK, makes sense to me. I forgot to ask you the output of efibootmgr -v
- can you paste it here? If there's non-printable chars, you could save it into a file and attach here.
Thanks again
Yes, no problem. Not necessarily garbled, but it definitely doesn't look like a normal output to me either (lots of hex characters)...
$ efibootmgr -v
BootNext: 0001
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0003,0001,0000,0008,0002,2001,2002,2003
Boot0000* SteamOS HD(1,GPT,89b12540-1027-4c4b-a1d3-0eaecb2a5805,0x800,0x20000)/File(\EFI\steamos\steamcl.efi)
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 02 00 00 00 00 00 40 25 b1 89 27 10 4b 4c a1 d3 0e ae cb 2a 58 05 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 73 00 74 00 65 00 61 00 6d 00 6f 00 73 00 5c 00 73 00 74 00 65 00 61 00 6d 00 63 00 6c 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot0001* rEFInd HD(1,GPT,89b12540-1027-4c4b-a1d3-0eaecb2a5805,0x800,0x20000)/File(\EFI\refind\refind_x64.efi)
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 02 00 00 00 00 00 40 25 b1 89 27 10 4b 4c a1 d3 0e ae cb 2a 58 05 02 02 / 04 04 3a 00 5c 00 45 00 46 00 49 00 5c 00 72 00 65 00 66 00 69 00 6e 00 64 00 5c 00 72 00 65 00 66 00 69 00 6e 00 64 00 5f 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot0002* EFI SD/MMC Card (MS 5S8F ,UCX) PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/SD(0)/HD(2,MBR,0x677a4f08,0x3baf0000,0x10000)RC
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 03 01 / 01 01 06 00 00 00 / 03 1a 05 00 00 / 04 01 2a 00 02 00 00 00 00 00 af 3b 00 00 00 00 00 00 01 00 00 00 00 00 08 4f 7a 67 00 00 00 00 00 00 00 00 00 00 00 00 01 01 / 7f ff 04 00
data: 52 43
Boot0003 Windows Boot Manager HD(1,GPT,89b12540-1027-4c4b-a1d3-0eaecb2a5805,0x800,0x20000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 02 00 00 00 00 00 40 25 b1 89 27 10 4b 4c a1 d3 0e ae cb 2a 58 05 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 5c 00 42 00 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00 6d 00 67 00 66 00 77 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 52 43
Boot0004* EFI PXE 0 for IPv4 (00-E0-4C-68-1D-EB) PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/USB(3,0)/MAC(00e04c681deb,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 01 08 / 01 01 06 00 03 00 / 03 05 06 00 01 00 / 03 05 06 00 03 00 / 03 0b 25 00 00 e0 4c 68 1d eb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0c 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
data: 52 43
Boot0005* EFI PXE 0 for IPv6 (00-E0-4C-68-1D-EB) PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/USB(3,0)/MAC(00e04c681deb,0)/IPv6([::]:<->[::]:,0,0)RC
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 01 08 / 01 01 06 00 03 00 / 03 05 06 00 01 00 / 03 05 06 00 03 00 / 03 0b 25 00 00 e0 4c 68 1d eb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0d 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
data: 52 43
Boot0008* ubuntu HD(1,GPT,89b12540-1027-4c4b-a1d3-0eaecb2a5805,0x800,0x20000)/File(\EFI\ubuntu\shimx64.efi)
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 02 00 00 00 00 00 40 25 b1 89 27 10 4b 4c a1 d3 0e ae cb 2a 58 05 02 02 / 04 04 34 00 5c 00 45 00 46 00 49 00 5c 00 75 00 62 00 75 00 6e 00 74 00 75 00 5c 00 73 00 68 00 69 00 6d 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot2001* EFI USB Device RC
dp: 7f ff 04 00
data: 52 43
Boot2002* EFI DVD/CDROM RC
dp: 7f ff 04 00
data: 52 43
Boot2003* EFI Network RC
dp: 7f ff 04 00
data: 52 43
Hmm..mine shows that as well. It's not a problem, the -v
options bring these additional information (device path and the variable data). See here: https://github.com/rhboot/efibootmgr/blob/main/src/efibootmgr.c#L1091
For example, in your case you could try: efivar -l |grep Boot2003 | xargs -L1 efivar -n
- you'll see the pattern 7f ff 04 00 52 43
there!
To avoid printing this data, just drop the -v
and call efibootmgr
with no parameters.
Also, from your output seems 0003 is not active, there's no * there.
Would efibootmgr -b 0003 -a
make it active? Then, -A should again deactivate it.
Understood. I didn't mean to imply that anything was wrong with the verbose output, it's just not the typical verbose output that I've been looking at. If those extra hex characters are normal, then no problem. It just seems different from what I'm used to.
Yes, I disabled the Windows EFI entry though other means. If I try to reactivate it, this is the error I get (same error for disabling).
sudo efibootmgr -b 0003 -a
efibootmgr: Boot entry 3 not found
Could not set active state for Boot0003: No such file or directory
sudo
should probably be required for this, although maybe it's not... same error with or without sudo
Wouldn't it be a stale entry in the BootOrder variable, that points to a non-existing var?
What's your output for efivar -l | grep 0003
?
$ efivar -l | grep 0003
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
OK, this is very weird! I don't think it's bug in the tools, specially since it's the same version I'm using.
Though it's not really what seems a supported use case, I would suggest you to try recreating the entries. Either start with a fresh system or try deleting the Boot0003 and redoing that the way your first created it.
Does efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
show valid output? I already had in the past problems with stale entries in the efivar sysfs, needed a reboot to fix it. It was recently resolved in the kernel, but fact is that efivarfs might get messy, specially in older kernels...
Yes, I understand that dual boot is not officially supported. I am not going to tinker with deleting the Windows EFI entry (annoying to re-add properly with diskpart
and bcdedit
commands), since I have my Steam Deck setup how I want it. This just seems odd to me because before 3.4 (older versions), the sudo efibootmgr -b 0003 -A
command worked just fine. Maybe it is a kernel issue. I don't know. We have workarounds available to bypass this issue, we'd just prefer to get rid of the workarounds if this simple command worked as it is supposed to. Thanks for your troubleshooting efforts.
Output:
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "Boot0003"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 00 00 00 00 74 00 57 00 69 00 6e 00 64 00 6f 00 |....t.W.i.n.d.o.|
00000010 77 00 73 00 20 00 42 00 6f 00 6f 00 74 00 20 00 |w.s. .B.o.o.t. .|
00000020 4d 00 61 00 6e 00 61 00 67 00 65 00 72 00 00 00 |M.a.n.a.g.e.r...|
00000030 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 |..*.............|
00000040 00 00 02 00 00 00 00 00 40 25 b1 89 27 10 4b 4c |........@%..'.KL|
00000050 a1 d3 0e ae cb 2a 58 05 02 02 04 04 46 00 5c 00 |.....*X.....F.\.|
00000060 45 00 46 00 49 00 5c 00 4d 00 69 00 63 00 72 00 |E.F.I.\.M.i.c.r.|
00000070 6f 00 73 00 6f 00 66 00 74 00 5c 00 42 00 6f 00 |o.s.o.f.t.\.B.o.|
00000080 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00 6d 00 |o.t.\.b.o.o.t.m.|
00000090 67 00 66 00 77 00 2e 00 65 00 66 00 69 00 00 00 |g.f.w...e.f.i...|
000000a0 7f ff 04 00 52 43 |....RC |
Yes, I understand that dual boot is not officially supported. I am not going to tinker with deleting the Windows EFI entry (annoying to re-add properly with
diskpart
andbcdedit
commands), since I have my Steam Deck setup how I want it. This just seems odd to me because before 3.4 (older versions), thesudo efibootmgr -b 0003 -A
command worked just fine. Maybe it is a kernel issue. I don't know. We have workarounds available to bypass this issue, we'd just prefer to get rid of the workarounds if this simple command worked as it is supposed to. Thanks for your troubleshooting efforts.
OK, thanks! Let me know if the next release fixes that...I'll be following here
Sorry in advance for the tangent @jlobue10 . How did you manage to get the EFI PXE entries for IPv4 and IPv6 to show up? I've got an official steam deck and have tried enabling in the bios, but they still aren't present.
I must have been plugged in to my dock with an ethernet cable plugged in. I don't think I've changed anything in BIOS other than setting VRAM to use 4GB.
Cool, thanks. That's how I'm setup too. If anyone is docked with ethernet, can they see if they still have those entries when running efibootmgr -v
? I'm guessing either Valve broke something in the last couple months, or something is wrong with my deck/official dock.
Do you have the official dock or a different one?
I do have the official dock, but I never even opened the packaging for it. XD
This efibootmgr -v
output was with a JSAUX dock.
Awesome, thanks so much. Any chance you know which JSAUX you have off the top of your head?
I had to look it up, but the model number is HB0603.
Thanks again. Ordered. I'll report back if that makes a difference.
So that indeed made all the difference. I can get PXE booting going just fine with the JSAux HB0603, but not with the official Steam Deck Dock. That's kinda irksome. :-P
I also tried the dock mentioned in the main google results for "steam deck pxe boot" - https://www.amazon.com/dp/B08FWMWGTD . That one also does not work for me.
So the only dock of the three I have that works is the JSAux HB0603 - https://www.amazon.com/gp/product/B0B7HVZNMB
A quick note in case it helps anyone. The easiest way to test if the dock works for PXE booting is to go into the Steam Deck BIOS (with system off, hold and keep + volume key pressed while turning on via power button) and then go to "Boot Manager". From there you'll see the boot options. Nicely it even refreshes on the fly. Plugging/unplugging the JSAux will cause the PXE options to appear/disappear within 5 seconds. Plugging in either of the other docks will not.
Thanks again for the help and info about your dock.
@aggieNick02 Do you have such issues with JSAux https://www.reddit.com/r/SteamDeck/comments/wn0gc7/review_jsaux_upgraded_docking_station_for_steam/?
So the only thing I've tried (and honestly currently need) on a docking station is pxe booting over a wired network, and that's all I've tried with the various docks. I guess I don't really need a dock and a usb-c ethernet adapter by itself would be enough, but just grabbing the official dock seemed like the easier way to go in the beginning.
Replying to https://github.com/ValveSoftware/SteamOS/issues/982#issue-1576529401
I'm new. How would I disable the EFI entry from the Steam recovery USB exactly?
Replying to https://github.com/ValveSoftware/SteamOS/issues/982#issuecomment-1426823958
How did you disable the Windows EFI through other means?
Hi, was the issue with efibootmgr resolved?
I'm getting the same behaviour on my steam deck where efibootmgr cannot disable the windows boot entry and the order I set is not respected.
Hi, was the issue with efibootmgr resolved?
I'm getting the same behaviour on my steam deck where efibootmgr cannot disable the windows boot entry and the order I set is not respected.
I don't think it was ever resolved. I have just used a workaround for now of booting into a Linux live iso that works for this efibootmgr
functionality. The last time I did it successfully was with Kubuntu 23.10 , I am not sure if it works on Kubuntu 24.04 or not.
Workaround - recreate the boot entries and specify an entry number that does not start with zero, using the -b flag with the usual —create options.
Rationale: when I tried deactivating entry 0002 with efibootmgr -b 0002 -A, the error message said “Boot entry 2 not found”. Noting that it said “2” and not “0002”, I suspect it is failing to process leading zeroes correctly. I tried forcing a number that begins with non-zero, and it worked.
Eg efibootmgr -b 2002 —create —disk /dev/sdb —part 1 —label MyOSnameHere —loader …
Your system information
Please describe your issue in as much detail as possible:
Ever since the update to version 3.4+, the functionality of the command line function
efibootmgr
seems to either be purposefully blocked by permissions or buggy. I maintain this rEFInd installation script repository and before the 3.4+ versions, the ability to disable the Windows EFI entry using a properefibootmgr
command worked just fine. Now I know that official dual boot is not supported yet, but it's easy enough to dual boot by shrinking the/home
partition and installing another OS in that created free space. This post is not about that. I want to know if this change inefibootmgr
functionality is intentional, or if it's indeed a bug. For the sake of reproducing the issue below, let's assume that the Windows EFI entry is 0003.Steps for reproducing this issue:
sudo efibootmgr -b 0003 -A
More information that may be useful in troubleshooting.
The Windows EFI entry can be disabled successfully when we boot from the SteamOS recovery USB using the same exact command. It can also easily be disabled using the EasyUEFI program from Windows.
The output of
efibootmgr -v
from SteamOS 3.4.4 seems garbled, or not normal (not what I'd expect at least). Maybe this is part of the problem or could help narrow down any potential bug.If this indeed a bug, it would be great to have it fixed so that my rEFInd installation script can be simplified again, back to relying on the script successfully disabling the Windows EFI entry (without more complicated workarounds). Thanks!