Unsolved
This post is more than 5 years old
7 Posts
0
3262
Optiplex 790 - PXE DHCP Request Times Out
EDIT: Turns out it's newer BIOS versions that break PXE on the 790s. I mistakenly thought that the full-size 790s were running A18, turns out they were working because they were running an older BIOS version. So, it's ALL 790s that have issues with PXE booting, if they're running newer BIOS versions. A17 works perfectly fine, the PXE update in A18 looks like it broke it.
At this point I'm wondering if there's a BIOS setting that I can disable to fix INTEL-SA-00075, without having to run newer BIOS versions that break PXE in our environment.
---------------------------------
Hello all,
We've got 5-6 different models of Optiplex desktop PCs here. We are trying to get them to PXE boot, but one model is not working: SFF Optiplex 790 (strangely enough, the full-size 790's are working just fine). What's stranger, is that it works fine plugged into one of our switches, but not the other (big Cisco chassis, not sure of model).
The DHCP request is timing out, and there doesn't appear to be a way to increase the timeout in the BIOS.
Things we've tried:
-Enabling Cisco Fastboot on the switch port works. However, our networking guys say they aren't going to enable it across the board, and will instead do it on a port-by-port basis. We're wanting to avoid this, as we'd like to be able to shuffle computers around as necessary without needing to have them make that change (they're contract, so it'll take some time).
-Pressing the Pause/Break button on the keyboard to pause the startup process just before the computer goes to obtain an address from the DHCP server works. We'd like to avoid using this workaround as well, as it's just something else that somebody has to do (I've spent many weeks on-and-off optimizing the imaging process to reduce the number of clicks/button presses required, so don't want that added to this).
-They're running the newest BIOS version.
-Doesn't appear to be a way to increase PXE DHCP timeout.
Any ideas?
RoHe
10 Elder
10 Elder
•
44.3K Posts
0
May 24th, 2017 11:00
Just a total WAG, but have you tried changing Deep Sleep settings in BIOS...??
Nate-R
7 Posts
0
June 21st, 2017 11:00
(No, deep sleep is not enabled)
Ok, so after having done some more testing, turns out that it's the newer BIOS versions that cause this problem. It'd be a simple matter of downgrading to the newest version that works properly, but unfortunately with the AMT vulnerability (INTEL-SA-00075) which is fixed in A19, it doesn't sound like that'd be a great idea.
In addition, it turns out that I had mistakenly thought that the full-size 790s we have were running A18 - it turns out that's why they were working and the the SFFs (which were running A18) weren't.
BIOS version A17 works perfectly fine, but is vulnerable.
Is there any way to fix the above vulnerability without upgrading to the newest BIOS version? I'm doing some reading about it now, but it's not entirely clear to me.
RoHe
10 Elder
10 Elder
•
44.3K Posts
0
June 21st, 2017 18:00
I guess you could update one of them to A19 to see if that fixes the PXE DHCP issue too, even if that's not documented.
At this point you either can have PXE work or protect against the AMT problem.
Meanwhile, I'll ping my Dell tech contact to see if he has any recommendations to fix PXE or at least report it so they release another update to fix that too.
RoHe
10 Elder
10 Elder
•
44.3K Posts
0
June 28th, 2017 14:00
Apparently Dell didn't get complaints that BIOS A18 broke PXE after it was released in 2013.
And this is a 7-year old model, so there weren't any updates after the 2013 release, at least until now. Dell released A19 in 2017 to fix Intel's AMT security vulnerability which only recently came to light. So it's highly unlikely there will be another BIOS update beyond A19.
As I suggested, you might want to update one running BIOS A18 to A19 to see if that fixes the PXE issue, along with fixing the AMT issue.
If A19 doesn't fix PXE, you'll have to decide which is more important to your organization, PXE boot or AMT security. If it's PXE, keep A17 on those systems that still have it. If it's security, upgrade ALL of them to A19 and lose PXE...
Nate-R
7 Posts
0
June 28th, 2017 15:00
Unfortunately it's broken in A19 as well.
I've done some reading, and it sounds like there's a way to fix the vulnerability from within the OS. However, it appears that it's a temporary fix that goes away with a re-image. I'll need to look into how it works, and see about adding it to the deployment process.
I did contact Dell directly back on the 21st (shortly after I made the reply), and was recently told to expect a call in the next day or so. Hopefully that will yield some results.
RoHe
10 Elder
10 Elder
•
44.3K Posts
0
June 28th, 2017 18:00
Too bad you didn't report the A18 PXE issue sooner...
If there was a 'reasonable' OS fix for the AMT issue, I'm pretty sure Intel would have had Microsoft roll it out via Windows Update.
Having to update microcode and have every PC OEM release new versions of BIOS, all of which have to be extensively tested before release, for each affected PC model, is time consuming and expensive.
So if it could have been fixed simply, Intel probably would have done it that way, because it's likely costing them a bundle now....
Here's a WAG... Suppose you disable the onboard NIC and install an add-in PCI-e NIC card that supports PXE. Would PXE work with the card or would it fail because a driver for an add-in card won't load until Windows loads...?? Like I said, just a WAG! :emotion-5:
Good luck with your dilemma! Post back if you do find a good OS fix because that would help other users who are still using A17.