Unable to add more than one custom entry to bios boot menu

[vince_fr]

Hello!

Same issue on two NUCs:
NUC6i7KYB (bios version KYSKLi70.86A.0067.2020.0325.1553)
NUC7i7BNB (bios version BNKBL357.86A.0082.2020.0505.1614)

I would like to have at least two custom entries in the boot menu (the one accessed by pressing F10 at startup), to choose manually at startup between two (or more) efi files, without going through the hassle of finding my way through the built-in EFI shell at each bootup to manually select the efi file to launch.

I use linux (custom self-built distribution, close to Archlinux), I will take any working solution for Linux (I can compile anything...), or even from an efi shell.

-Description of the current behavior:
When I edit the EFI boot menu entries using efibootmgr (version 17) or bcfg (https://github.com/acidanthera/OpenCorePkg/releases/OpenCore-0.5.9-RELEASE.zip -> EFI/OC/Tools/OpenShell.efi), I get the same behavior: the entries appear just after I add them as shown by the user tool (either efibootmgr of bcfg), but only the last one added appears in the NUC boot menu (F10 at startup) on next boot. The other options appear in the next OS session, but their entries look "disabled":
instead of:
Boot0001* bootx64 HD(1,GPT,38300386-faff-41cb-8553a28ca828f87,0x800,0xfa000)/File(\EFI\Boot\bootx64.efi)
I get:
Boot0001* bootx64 VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)

... it's like the NUC disables every custom boot option but the last one added.

Below is more details about what I get with efibootmgr (easier to copy+paste than bcfg which lives in an EFI shell, but I get the same result with both tools):

Let's say I start with these 3 boot entries as seen in the output of efibootmgr:

# efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,000A,0009
Boot0001* bootx64 HD(1,GPT,38300386-faff-41cb-8553-fa28ca828f87,0x800,0xfa000)/File(\EFI\Boot\bootx64.efi)
Boot0009* UEFI : Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)0000424f
Boot000A* KINGSTON SA1000M8960G : PART 0 : Boot Drive BBS(HD,,0x0)0000424f

Now I want to add another entry: I go:

# efibootmgr -c -d /dev/nvme0n1 -p 1 -L bootx64_bkp -l /EFI/Boot/bootx64_bkp.efi

The new entry appears in the output of efibootmgr:

Boot0002* bootx64_bkp HD(1,GPT,38300386-faff-41cb-8553-fa28ca828f87,0x800,0xfa000)/File(\EFI\Boot\bootx64_bkp.efi)

after reboot and going into boot menu (F10), only this last entry ("bootx64_bkp") appears

when the OS has booted, when I look at the output of efibootmgr I see:

BootCurrent: 0002
...
Boot0002* bootx64_bkp HD(1,GPT,38300386-faff-41cb-8553-fa28ca828f87,0x800,0xfa000)/File(\EFI\Boot\bootx64.efi)
Boot0001* bootx64 VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0009* UEFI : Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)0000424f
Boot000A* KINGSTON SA1000M8960G : PART 0 : Boot Drive BBS(HD,,0x0)0000424f

It looks like the motherboard disables any entry that is not the last one I added, and this VenHw(...) string gets attached to it, which I guess has something to do with it not
being usable?

I tried adding two entries during the same session, one after the other, but the problem remains.

By the way, fastboot and secure boot are disabled int the BIOS (I saw a lot of posts mentioning they should be).

I will take just any advice that will help me not go in the efi shell at startup all day long to select manually an option at startup! Even if it involves black magic!

Thanking you in advance.

Vince.

PS: planning on buying a brand new NUC10 in the summer. So if this problem has been solved in the NUC10 series, no problem, I will send my NUC6 and NUC7 to schools in Zimbabwe...

[AndrewG_Intel]

Hello vince_fr

Thank you for posting on the Intel® communities.

It is worth mentioning that for these Intel® NUCs at this point only Windows® has been validated as supported. Linux Operating systems have not been validated yet. NUCs reported as compatible by Linux users and additional details for Linux support can be found in the below link:

Linux* Support for Intel® NUC

However, we will do our best to check this inquiry. In order to understand better your environment, could you please provide the following information?

1- How many Intel® NUCs do you have that are affected by this issue?

2- Is the Linux Kernel up to date?

3- Log file /var/log/dmesg

4- Intel® System Support Utility for the Linux* Operating System

https://downloadcenter.intel.com/download/26735/

Please refer to the Release Notes for details on how to run the tool:

https://downloadmirror.intel.com/26735/eng/ReleaseNotes.txt

Best regards,

Andrew G.

Intel Customer Support Technician

[vince_fr]

Dear Andrew,

Thank you very much for your answer.

In reply to your questions:

1) I own 2 NUCs that show the same behavior (described in my post): a NUC6i7KYB (bios version KYSKLi70.86A.0067.2020.0325.1553) and a NUC7i7BNB (bios version BNKBL357.86A.0082.2020.0505.1614). 

2) The kernel I actually use on both is a 5.6.18. It might be of interest to note that the directory /sys/firmware/efi/ is populated (config_table fw_platform_size runtime-map/ efivars/ fw_vendor systab esrt/ runtime vars/). It might also be of interest to tell you that I recently (2 weeks ago) upgraded my kernels, and with the previous kernel version I used (4.6.13) I had the same issue.

3 and 4) Please find attached dmesg output and the output of the SSU tool.

I will be happy to provide any other information, and/or do any trial.

Kindly yours

Vincent

[KenF_Intel]

Hi Vince_fr,

We've been looking into the behavior you describe.  

It's quite impressive that you figured out how to add even one custom entry.  That is not something that we expect customers to do.

At this time, there does not appear to be a way to add more than one custom entry.  Moreover, adding any custom entries to the F10 menu is not a supported option.

We are not making any plans to change the current behavior.

Regards,

Ken
Intel Customer Support

[Hans_Bausewein]

This is bad news!

I also have quite some options for operating systems. (No Windows plans, btw).

Currently I have installed:

• Debian (10, testing)
• Linux Mint 20.1
• Qubes 4.0.4-rc2

As soon as I add a third it is removed on the next boot.

If Intel does not plan to fix it, is there a way to install custom firmware?
At my own risk, of course.

Or reverse engineering the Intel firmware and increasing a number may be easier

Note that GPT allows to create 128 partitions on a disk, so I could boot 250+ different systems.

Well, in practice a single OS will use at least few partitions, but 2 is a very low limit!

Hans

[AndrewG_Intel]

Hello vince_fr

Thank you for your response and the details provided.

Please allow us to look into this and we will be updating the thread as soon as more information is available.

Best regards,

Andrew G.

Intel Customer Support Technician