Community
cancel
Showing results for 
Search instead for 
Did you mean: 
MLaut
Beginner
1,280 Views

NUC8i7HVK and EFI Problem / strange effect

Hi all,

I've had a very strange effect that I'd like to understand. Here is the situation:

I bought a NUC8i7HVK, installed a fresh M.2 disk and 16GB RAM. After that I installed a fresh Debian system and I deactivated Secure Boot in the BIOS. All worked well. Unfortunately one or both fans seemed to have a problem. Whenever I stressed the CPU and the fans increased their rotation speed a very loud noise came up. As if a fan touched something. So, I ordered a replacement.

A couple days later I had a replacement NUC8i7HVK. So, I took the RAM and M.2 from the previous system and installed them in the new one. Did the BIOS settings and .... could not boot. I always got the message that no boot disk had been found. But I could boot from the Debian live USB system. So, I wondered what was wrong. Same system, same settings ....but no boot disk was recognized. I tried the other M.2 slot, but no luck.

So, I removed the first disk and installed another spare disk and again, installed Debian. Then, I could suddenly boot from this disk. I installed the first disk again but still got the message, that no boot disk had been found. So, I booted once again from the live USB and cloned the system to the spare M.2. I installed the spare M.2 with the cloned system and - of course - got the "no boot device" message. I then booted again from the live USB and reinstalled GRUB (apt-get install --reinstall grub-efi via chroot). After that I could boot from the cloned disk!

Now the interesting part. I installed the first M.2 again and ..... suddenly could boot from this one too. Though I had not changed anything on this disk! All I had done happened on the second disk. Since then, I rebooted a couple of times and it just works.

Could anyone explain, why I cannot simple move a disk from one system to another and boot it up? And why does the NUC8i7HVK suddenly recognize my first disk as a bootable device though I have done all my experiments on another disk?

Cheers,

Marcel

0 Kudos
10 Replies
idata
Community Manager
148 Views

Marcel_2k18: We will assist you with your inquiry.

There is not an specific reason to describe the behavior of the NUC, but there are several factors that may have caused this:

 

1. BIOS version. Updated BIOS versions may include firmware updates not realized in older BIOS versions.

 

2. BIOS settings. Initially you stated you "installed a fresh Debian system and I deactivated Secure Boot in the BIOS."

 

Enabling or disabling Secure Boot may have resolved the initial issue with the drive not booting.

 

3. Unit model: The Intel® NUC model may be a factor as well. Even though you purchased the same 'Box code' the revision may have been different.

For further details please visit the link below:

QDMS Search PCN Database

 

Search: PCN Title = NUC8i7HVK

 

https://qdms.intel.com/Portal/SearchPCNDataBase.aspx%3Fmm%3D961309 https://qdms.intel.com/Portal/SearchPCNDataBase.aspx?mm=961309

Regards,

 

Alberto R.

Intel Customer Support Technician

 

Under Contract to Intel Corporation
MLaut
Beginner
148 Views

Hi Alberto,

thank you for your detailed explanation. Here are my answers regarding your points.

1. BIOS Versions are the same (0050, https://downloadcenter.intel.com/download/28185/BIOS-Update-HNKBLi70-86A-?product=126143 Download BIOS Update [HNKBLi70.86A] ) for both products

2. BIOS Settings were done before anything else. That is before I installed Debian. The same is true for both devices.

3. That one I'd like to understand. Why would it have any side effects putting a disk from one equal system (with the same settings, BIOS versions etc) into another? I agree, the are not identical, but does this really matter? I have never experienced something like this. Is there anything special to UEFI? Please, could you provide some more insight here?

I checked the link you posted and did the search. But all I got was a 3-page document that actually did not provide much information except: "The BIOS will be updated from HNKBLI70.86A.0037 to HNKBLI70.86A.0049." and "It is recommended that customers evaluate this new BIOS to ensure a smooth transition.". And actually the latest is 0050

Regards,

Marcel

idata
Community Manager
148 Views

Hi Marcel_2k18: You are very welcome.

 

 

We will do further research on this matter, as soon as I get any updates I will post all the details on this thread.

 

 

Regards,

 

Alberto R.

 

 

Intel Customer Support Technician

 

Under Contract to Intel Corporation
idata
Community Manager
148 Views

Marcel_2k18: Could you please provide the SA number of both NUCs? You will find it on the back of each unit close to a serial bar.

 

 

Regards,

 

Alberto R.

 

 

Intel Customer Support Technician

 

Under Contract to Intel Corporation
MLaut
Beginner
148 Views

I am sorry, I only have one left. The broken one I have returned already. Anyway, here is the SA number of the one I am currently using: J71485-502

Another thing to note: The broken one had Bios version 0037 installed. The one I currently use had Bios version 0029 installed. But I had flashed them both to 0050.

I hope that helps.

idata
Community Manager
148 Views

Marcel_2k18: Thank you for sharing those details.

Since we do not have the SA number of the other unit, we cannot advise why you were having issues moving the M.2 from one unit to another since we cannot confirm if they were actually the exact same model.

If you need further assistance from us, please let us know what is currently the issue with the NUC you have, also please provide the brand and model of the SSD and memory RAM including the speed and quantity of sticks.

Or you can attach the SSU report so we can verify those details:

 

https://downloadcenter.intel.com/download/25293/Intel-System-Support-Utility https://downloadcenter.intel.com/download/25293/Intel-System-Support-Utility

Regards,

 

Alberto R.

Intel Customer Support Technician

 

Under Contract to Intel Corporation
idata
Community Manager
148 Views

Marcel_2k18: I just wanted to check if you saw the information posted previously and if you need further assistance on this matter?

 

 

Regards,

 

Alberto R.

 

 

Intel Customer Support Technician

 

Under Contract to Intel Corporation
RSlot
Beginner
148 Views

I'm pretty sure this has to do with the EFI boot entries. Try seeing a list of boot entries with "efibootmgr -v"

You'll see that the boot entries will refer to a unique code that is called a GUID (globally unique identifier) or UUID, (universaly unique identifier). Now, I have no idea how exactly these things are given to disks or partitions, or where they are stored, but it seems likely that your problem has been caused by a mismatch of these numbers.

Basically, you moved the drive to a new computer without telling the computer what exactly it should boot from.

Now, you might wonder why a live usb would boot without problems. I think that's because such disks always have an obvious file on them (/efi/boot/bootx64.efi is what I found on my usb) while your linux install doesn't.

MLaut
Beginner
148 Views

Sorry for the late answer. I must have overlooked my notifications ....

First of all, thank you NucUser9. for your reply. After some reading I can tell now: you are partly right.

The reason why it worked in my specific case simply seems to be that by reinstalling grub-efi I reconfigured/modified the UEFI boot manager (which keeps its settings in Non Volatile RAM) and created an entry like this: Boot0001* debian HD(1,GPT,33e108c3-c484-4667-9b40-d6083a24bc8c,0xffff,0xf851e)/File(\EFI\debian\grubx64.efi).

And since the partition UUIDs on the clone and the original disk are the same I could now actually boot from both disks!

I'd definitely prefer to do this from withing the firmware UI than from a LiveCD. So I'll check the firmware UI again. Maybe I'll find an option to configure the boot manager from there.

But with one aspect you are right. I'll have to tell the firmware what exactly it should boot from. That's the big difference to a BIOS where there are so many (de-facto) assumptions. Though I only have to do this because there is no fallback path on my system, that is I do not have a file like /efi/boot/bootx64.efi. In addition the legacy (BIOS-compatibility) option might have been a fallback option, too. But this was removed with version 0040.

idata
Community Manager
148 Views

Marcel_2k18: No problem at all.

 

 

Thank you very much for sharing that information, it is great to hear the problem got fixed and now the NUC is booting properly.

 

 

Any other inquiry, do not hesitate in contact us again.

 

 

Regards,

 

Alberto R.

 

 

Intel Customer Support Technician

 

Under Contract to Intel Corporation
Reply