-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange calls during network boot #649
Comments
I do observe something similar with Dell Latitude 3590, OptiPlex 3040 and others. Checking wiht
The last packet seems incorrectly parsed by It feels like some kind of bad memory access — "Onboard" is one of the EFI boot options on my end, probably the same holds true for "USB" in @raddirad s case. The strange character is |
I've made some progress trying to understand the changes between 15.6. and 15.8. Adding: return EFI_SUCCESS; right here: Line 415 in 14d6339 (i.e. after the special case handling several devices), things work again with my affected systems. Of course, that's not a real solution, but it highlights how the bad loader name appears. So it seems that the Since the garbage does not start with |
maybe @julian-klode or @vathpela could take a look at this? Thanks in advance |
That looks like a I have absolutely no idea why this is being passed in the load options, but "is this a fully formed boot variable" is a thing that certainly could be tested for and ignored. |
Okay to be fair a little bit weird boot variable - the structure is like this psuedocode:
So that's: |
So in summary: 1) I have no idea why there's a boot variable hanging out here, 2) I have no idea why the device path list in the boot variable has this weird vendor device path, but 3) it is basically a reasonably well formed boot variable, and we could probably test for that, but I'd rather know why Dell is doing this, because it doesn't really seem like they should be. |
Was there a path chosen to help with this issue on the shim side? I have all Dell systems with this issue. My only choice at this time seems to be to downgrade shim-x64 to a 15.6 version. |
Also, I know it affects at least the Dell Optiplex 5040, 7040, 3060 and 5060 and Latitude 5400. For me, it's any Dell desktop or laptop I've needed to PXE install to so far. |
Have you tried going into the UEFI settings and in the 'boot sequence' section, unchecking the 'onboard nic' and 'usb' choices? You can still use f12 to choose a single-boot target of usb or network boot, but if you are permanently netbooting systems that won't work, obviously. |
I've not tried that path yet.
Part of our use case is to also utilize the "wake on lan + PXE" BIOS option
to auto install from an offline condition at a *remote* location. I'll need
to check if that is still possible. Sadly the older Optiplex (older than
##60) are not WMI capable and will physically need to have options changed.
The newer ones I can change BIOS via the SYS file system
(/sys/devices/virtual/firmware-attributes/dell-wmi-sysman/) from the
command line.
I will not be at a location to check/test until next Wednesday, however.
PJ
…On Thu, May 23, 2024 at 8:24 AM nathan-omeara ***@***.***> wrote:
Was there a path chosen to help with this issue on the shim side? I have
all Dell systems with this issue. My only choice at this time seems to be
to downgrade shim-x64 to a 15.6 version.
Have you tried going into the UEFI settings and in the 'boot sequence'
section, unchecking the 'onboard nic' and 'usb' choices? You can still use
f12 to choose a single-boot target of usb or network boot, but if you are
permanently netbooting systems that won't work, obviously.
—
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2ANMFFZQPZSHVA2HG2QLTZDXUZZAVCNFSM6AAAAABFM7P5UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXGEYDEOBXG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*Disclaimer*
The information contained in this communication from the
sender is confidential. It is intended solely for use by the recipient and
others authorized to receive it. If you are not the recipient, you are
hereby notified that any disclosure, copying, distribution or taking action
in relation of the contents of this information is strictly prohibited and
may be unlawful.
This email has been scanned for viruses and malware, and
may have been automatically archived. Cassens
|
We are installing the OS via PXE/UEFI Netboot, and thus disabling boot choices is not an option. In addition the shim doesn't even try to load the grub via PXE/UEFI Netboot and hangs at the error described in OP. |
Yes, if you are only installing the OS, you can press f12 to do a one-time boot to PXE, even when PXE is not in the 'boot sequence' list. That is how I have been able to work around this bug to install the OS via network boot. |
In our case we are loading the shim via PXE and this bug happens before the shim chainloads the grub via PXE. |
Yes, that is how this bug is occurring. I would still suggest you try the workaround. It isn't a great solution, but it seems to work, and still allows you to interactively network boot for OS install. |
Ok, now I get it. Yeah for me personally this is doable, but I can't tell our customers to this things if they have a lot of affected devices. |
Indeed, thanks for the proposed workaround, in fact in our case we reinstall nodes without user interaction (i.e. by triggering a PXE boot remotely, by adding it to the boot order temporarily, then rebooting), so this does not help with the many distributed desktop machines we operate. |
This is the commit that introduces this issue. If I revert it, I can boot my dell (that I finally got hands-on with) with the Onboard devices still in the boot sequence. So, I'm guessing this is getting confused by the weird Dell boot entries, and screwing up the load path for grubx64.efi |
Possible fix: Lines 1262 to 1263 in 0287c6b
Add TFTP_ERROR here: if (!use_fb && (efi_status == EFI_INVALID_PARAMETER ||
efi_status == EFI_NOT_FOUND ||
efi_status == EFI_TFTP_ERROR)) { In my testing, this gets it booting over network again. |
Any guess as to how long a change like may take to make it into a updated release package? |
maybe @vathpela @jsetje or @julian-klode could say more on if this might get upstream |
Thank you for getting my attention. Just testing for the extra error is probably reasonable, but I'm also curious why we get a variable that looks like that. Since I exposed this, I'll certainly help get a fix in. |
All of your help is much appreciated! Thank you for helping to resolve this
issue.
PJ
…On Tue, Jun 4, 2024 at 8:12 PM Jan Setje-Eilers ***@***.***> wrote:
Thank you for getting my attention. Just testing for the extra error is
probably reasonable, but I'm also curious why we get a variable that looks
like that. Since I exposed this, I'll certainly help get a fix in.
—
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2ANMDP55MFP6GTPQJP7WTZFZQZJAVCNFSM6AAAAABFM7P5UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGY3TKMJWGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*Disclaimer*
The information contained in this communication from the
sender is confidential. It is intended solely for use by the recipient and
others authorized to receive it. If you are not the recipient, you are
hereby notified that any disclosure, copying, distribution or taking action
in relation of the contents of this information is strictly prohibited and
may be unlawful.
This email has been scanned for viruses and malware, and
may have been automatically archived. Cassens
|
I started asking around to see if I could find a system to test this with, which made me wonder about a 2-in-1 with a built in NIC. So I looked at the original report again. I bet that this all has something to do with how the docking station brings the NIC in. |
It definitely isn't specific to docking stations. I have one dell on-hand with the issue, a Latitude 5300 (built-in NIC, no external NIC). But I also have one other dell, one HP, and one MS surface that do not show this issue, all 3 of those using USB NICs only. It's worth noting that USB boot technically has the same basic issue, but the fallback code kicks in on USB boot, because the error handling I pointed out handles the error when it's on a filesystem, it just doesn't handle it when it's on TFTP. I also wonder if HTTP(s) boot would be another error code that would need to be added there, but my only on-hand device with HTTP(s) boot support is the dell that doesn't demonstrate this issue. If you pay attention on USB boot, you can see the same error, followed by the message here: Line 1265 in 0287c6b
This is what led me to try adding EFI_TFTP_ERROR to that statement. |
Hmm, yeah, forced a (similar?) error by renaming grubx64.efi on my http boot server and booting my other dell. I'm guessing because 0x23 (35?) is relatively new, and I'm using fedora's shipping version of shim 15.8 which was probably compiled with an earlier version of gnu_efi. So I'd suggest adding I certainly wouldn't object to fixing the parsing of the weird values (if there is an actual issue, and it isn't just Dell and Lenovo (and maybe others) doing something that breaks the standard) but harmonizing the fallback behavior between local filesystems and network boot makes sense to me. |
FWIW, we'll have to fix this forward. In addition to the patch that exposed this, we'll need non-hardcoded paths and names for UKIs. Hopefully I can get my hands on a setup that exposes this, but I'm also not opposed to keep trying unless we get a very specific error. |
This is not related to the Dock. I tested the 2-in-1 and a working Dell device. The 2-in-1 failed, the other one succeeded. @olifre mentioned other devices that show the same behaviour ("Dell Latitude 3590, OptiPlex 3040 and others") |
If you want anything tested, I have access to the 2-in-1 convertible I mention in OP. I can test new code |
I can immediately add to the list:
After that, I stopped doing systematic testing, as testing other models (we have an assortment of Dell OptiPlex systems, but no other Latitudes at hand) would mean temporarily stealing them from active users to test them in our test network. I can certainly try to grab a specific model if you know you can get a hand on any OptiPlex, check it and report back here. Combining my list with the information provided by @pjwelsh above, I think the full known Dell list is:
From those numbers, it seems quite likely all the OptiPlex |
I am also able to test proposed patches. I even set up an additional signing key on the latitude 5300 so I can sign my builds and test with secure boot on. |
I was going to submit a PR with the changes I recommended above, but it won't compile with |
Any progress on the PR submission? |
I could submit it without |
Not even sure about gnu-efi... I haven't found it as an RPM package or a
file so far.
…On Thu, Jun 20, 2024 at 10:53 AM nathan-omeara ***@***.***> wrote:
I could submit it without EFI_HTTP_ERROR until gnu-efi is updated. I'm
not sure what you guys need to do to pull in a newer version of gnu-efi.
—
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2ANMCFQZKRSGL4YDMWEPDZIL3GRAVCNFSM6AAAAABFM7P5UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBRGAZTEMZXGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
*Disclaimer*
The information contained in this communication from the
sender is confidential. It is intended solely for use by the recipient and
others authorized to receive it. If you are not the recipient, you are
hereby notified that any disclosure, copying, distribution or taking action
in relation of the contents of this information is strictly prohibited and
may be unlawful.
This email has been scanned for viruses and malware, and
may have been automatically archived. Cassens
|
It's a submodule, and it looks like each release of shim has a specific gnu-efi revision/branch tagged: Lines 1 to 4 in 0287c6b
That gnu-efi shim-15.8 branch does not contain |
…boot Only certain errors trigger fallback to the default loader name. This change allows fallback when encountering `EFI_TFTP_ERROR` as well. And ideally would also handle `EFI_HTTP_ERROR` the same way, but that requires updating gnu-efi to a version newer than the shim-15.8 branch. This fixes the issue reported in rhboot#649 that prevents boot on some models of PC.
…boot Only certain errors trigger fallback to the default loader name. This change allows fallback when encountering `EFI_TFTP_ERROR` as well. And ideally would also handle `EFI_HTTP_ERROR` the same way, but that requires updating gnu-efi to a version newer than the shim-15.8 branch. This fixes the issue reported in rhboot#649 that prevents boot on some models of PC. Signed-off-by: Nathan O'Meara <Nathan.OMeara@tanium.com>
…boot Only certain errors trigger fallback to the default loader name. This change allows fallback when encountering `EFI_TFTP_ERROR` as well. And ideally would also handle `EFI_HTTP_ERROR` the same way, but that requires updating gnu-efi to a version newer than the shim-15.8 branch. This fixes the issue reported in rhboot#649 that prevents boot on some models of PC. Signed-off-by: Nathan O'Meara <Nathan.OMeara@tanium.com>
For reference, I can confirm that PR #666 indeed fixes the issue for our machines when I recompile shim with that patch (we are using TFTP boot). Many thanks! |
I can also confirm, that adding |
Hi
I have a problem with shim 15.8 and a Dell Latitude 5300 2-in-1 Notebook.
This Noteboot uses the latest Firmware 1.29
It is connected to Ethernet via a Thunderbolt USB-C Docking Station.
We do a lot of netbooting with a current shim 15.8. This shim is signed by Micrsooft, although the problem isn't Secureboot related.
When Netbooting on this specific machine we get a strange request via TFTP
Then the system fails and boots in a SupportAssist mode by Dell.
To verify it's not related to our shim i took the latest 15.8 shim from Canonical, with the same result.
Other systems, like Dell 5430 or vSphere or Proxmox VMs aren't affected. As for now this is the only system I know that has this issue
Other systems request the grub binary as expected after the revocations.efi is not found.
The text was updated successfully, but these errors were encountered: