Hi! Sorry for my bad English...
Intel NUC7PJYH2 BIOS Upgrade to 0058 causes boot failure Linux and Unix-like operating systems
Intel BOXNUC7PJYH2 Version #: J67992-404, Date of Manufacture: 22 May 2020.
With previous BIOS 0057 all OK with Linux, Unix-like OSes and Windows. After upgrading the BIOS by F7 to version 0058 and F9 - Load defaults and configure Bios (with Linux or Windows boot profile and disable Secure Boot), Windows 10 installer is loading successfully from USB stick, but Linux and Unix-like (FreeBSD and NetBSD) are not loaded.
1. Please remove Intel NUC7PJYH Bios 0058 from Download Center to avoid problems with Linux and Unix-like users.
2. Please fix this Bios bug for Linux users
Probably this is a problem with ACPI BIOS settings for Linux and Unix-like OSes.
Why wouldn't it work? You take the old binary, or revert all changes and rebuild the blob, bump the version number and sign it or whatever mechanisms are used to secure it. And if there are sub-firmware blobs that can't go backwards, you do the same with those. Looks like a new release, but internally reverts the code back. I work in software, but we've had our firmware guys do exactly this on more than one occasion. Not that there wasn't a way to go backwards, but because it was simpler/easier to deploy.
As a customer I don't give c*** about this security nonsense. I don't want an expensive paperweight. There are ways to securely provide rollback mechanisms.
To be honest, I don't understand why it would be against security policies to "downgrade" the BIOS for affected users, but it's acceptable to send users a new unit with a lower BIOS version. Makes little sense to me and the environmental impact is not good at all.
Now my unit will be picked up soon, which is another bummer: I have to be available over a six hour timeframe, in case the parcel service rings my bell. I wasn't allowed to just bring the package to the post office myself. And I'll only get a replacement once my unit was received by Intel. Guess they handle it different here in Europe than in the US.
While I'm happy that some of the Intel staff have answered here, I feel the whole process is really everything but customer friendly. No time frame for a fix, a tedious process of shipping that requires time and effort (put documents in, write a number on the package, print package label) and not knowing when or even whether my "new" NUC will get the security update.
A unit with an older BIOS can always be upgraded if the included mitigations are considered a requirement. A unit that can be downgraded can be abused by bad actors; if they downgrade the BIOS, they can then use the vulnerabilities that had been mitigated to do the nefarious. Frankly, I don't get why you folks don't understand this.
Intel first shipped a (chipset-based) Management Engine (ME) in the 965 chipset. That was 14 chipset generations ago. Every single one of those Management Engines has enforced this rule; once an update is installed, it cannot be uninstalled (downgraded). The NUC team cannot do anything about this; the ME team sets the rules.
Not customer friendly? Obvious you don't deal with many companies' support services (I use that term loosely). I consider Intel Customer Support one of the best around. Unfortunately, that's not saying much.
Fact is, Intel Customer Support (and volunteers like me who are under NDA) simply cannot provide any information regarding features, schedule or availability. It simply isn't allowed. Intel had to inject this rule because people treated guesstimates as hard and fast commitments and sued Intel if they were late. If you want someone to blame, blame the trolls taking advantage of this.
As for the returns, you don't have to do it. You can always just wait for the fix...
That's such a lame excuse.
If Intel was serious about security they wouldn't implement the backdoor security nightmare called Management Engine in the first place. Who knows what unauthorized stuff may be running in the ME already that Intel knows nothing about. As long as ME is there, a "bad actor" rolling back my bios is the least of my worries.
Put a simple physical jumper on the board to allow downgrades then. If you have physical address to the box a bad actor can do anything anyway. Like swap the board, memory chip, whatever, add bad stuff...
I get it, they have their silly rules. Whatever. I just know that I will no longer upgrade the firmware unless I really don't have another choice. The risk is simply not worth it.
@n_scott_pearson I should have explained why I put the "downgrade" in quotes. I was referring to the idea posted by another user, that Intel could simply release a higher version of the previous bios as a hotfix, until a solution is available. This way no malicious downgrade could take place, since the version got incremented (although the code would be that of a previous version).
I'd love to not return my NUC, but since no one puts any kind of estimate here (I somewhat understand your explanation here) and I don't know if this will take days, weeks or even months, I can't. I need my NUC to work properly.
And not to mention the risk of having to ship back a unit for an exchange. That assumes that the new unit isn't intercepted and manipulated in transit. Rolling back yourself may be the more secure option. Maybe it's a little far fetched, but who knows. All depends on who you are. Maybe ME saves my encryption keys? Maybe it even sends them out to interested parties if it's connected to the internet. Would you send back a harddrive with sensitive data for warranty? I wouldn't. I'd destroy it. There's no 100% security. To me, being able to roll back software if it causes issue is one of those basic things that I just take for granted. IT admins do it every day. And sometime that means re-introducing known security issues. Booo
I was a bit lucky when I discovered this topic about 2 weeks ago. I purchased the NUC a day before in an online webshop as a private person. By the (EU) law, I have 14 days to return the device and the seller have to accept the return without any question and give full refund.
When the NUC became a brick, I returned it and purchased exact same device, same day.
If the same law exist in your country, I would initiate the RMA to Intel ASAP and purchase an other NUC temporarly. Yes, you need to invest a bit, but you will get back your money at the end, on the other hand you will have a working device during the RMA process.
Gee, this happens to be is EXACTLY the guidance that Intel always provides.
Having physical access is not acceptable in a chassis design that does not support a locking capability.
man, i wish they'd heeded your advice earlier and removed the 0058 from the downloads. i grabbed it on the 16th or 17th. luckily a google search brings up this post or i'd have been way more upset.
i was able to boot using acpi=off, but my machine felt craz slow. i installed cpu-g and it's reporting only a single core. not sure if that's from the acpi flag or something else in the bios "upgrade".
Sorry, I forgot that Monday was a holiday for the Intel Oregon folks (Martin Luther King day). None of them were online on Monday. They didn't see my alert until Tuesday.
It's good that you mention that tidbit. There may be a clue in that information that could help speed up issue identification.
hmm... poking around "acpi=off" seems to cause linux to get confused about the core counts. so it's not part of the root issue, it's a side effect of the workaround. so it's not a paperweight, it's just horribly crippled until a fix.
You can only use one CPU because APIC provides the MADT (Multiple APIC Description) table contains all the information to discover the other cores and APIC. So, without ACPI the OS has to assume that your system only has one CPU, there's no way to use more than one core.
I dont really have much to add to this conversation other than apologize for the issue caused with BIOS 0058 and offer warranty replacement for the affected NUCs.
Please reach out to our Intel Customer Support Service via phone, chat, or web ticketing (we don't provide warranty services over the Intel Community) and make reference to case number 4937159.
Here is our contact reference information:
I got a call from Intel customer service staff yesterday about the case I submitted earlier on this bios issue. She asked me whether I want to do RMA replacement. If we can get a bios fix in a few weeks I can wait but if it is going to take more than that for new bios to be released I will go with RMA.
my guess is they can't really give a timeframe on a fix. i they offer an rma, i'd be inclined to take it. i filed a support ticket a few days back but haven't heard anything...
I've been struggling with the same problem for a few days, tried every combination. Won't boot from hard drive or USB stick. I upgraded to Bios 58 only because I thought it might solve the problem that I was having with the SD card slot not being recognized by the OS - it shows up fine and is enabled in the Bios Setup. BOXNUC7CJYH1 running Ubuntu 20.04. Can't restore Bios, and can't downgrade (if that option is not available, why do they even have it in their power button menu? It would be a good idea if Intel provides an interim upgrade - God I hope that will work, while they fix the problem. Otherwise they will have a lot of "bricks" showing up on their doorstep.
On the bright side, you now have the most secure firmware that can't even be rolled back. It's so secure, it doesn't even run the security nightmare called Linux. It's so secure, it won't even show up on your network anymore, so there's a whole lot fewer security risks now.
Thanks for posting this case on Intel Forums concerning bios update that cause Linux OS unable to boot and stuck at blank screen. The day you post your issue is the exact date when I also experienced a blank screen when I try to reinstall LMDE4 on my dual-booting NUC7PJYH1. After recent bios update, when I select LMDE4 to operate, I got stuck on Initial ramdisk and nothing happens after that. I try to use a live-usb with LMDE4 on it to try to nomodeset just to fix this issue but it stuck to blank screen. I even try to use several live-usb from Ubuntu 18.04.5, Ubuntu 20.04.1, Ubuntu Mate 20.04.1, Linux Mint 20.1 Mate, and even try the lightweight RPI Desktop but to no avail. I tried those live-usb on my laptop, it did boot up and have no problem with it. Surely, Intel will fix this problem with another bios update to be able to boot the Linux OS kernel esp on dual-booted PC. Glad you presented this well so that they can address this issue as soon as possible.
Same issue here with my NUC7PJYH, 0058 BIOS has been pulled offline now, so its definitely a BIOS issue.
Had alive chat with support, and they tried telling me that because Ubuntu isn't officially supported, so it's not their fault? I've had ubuntu running fine on it for 2 years.
The normal work around is to uncheck the UEFI boot option box and the enable it again, but they have the box greyed out on this version of the bios.
I've tried every method to downgrade the BIOS, and tried the recovery bios method, all with no joy.
anyone else find a fix?