Comment 83 for bug 1040557

This topic is probably not Ubuntu related, but any UEFI linux distro. What I found out so far:
Notebook: Samsung series 3 NP300E5C-A05DE (German), BIOS-ID: RAC, current version: P05RAC

Installed Linux Mint 13, MBR mode. Later converted to GPT/UEFI - all seemed ok. Device booted ok, but then I recognized, that I was unable to enter the BIOS Setup with F2 anymore.

What still works: F3 to boot from CD, FAT32-Stick with EFI-Shell v1.0 saved as \EFI\BOOT\BOOTx64.efi
(2.0 does not work even if BIOS version is UEFI 2.31)

My fix: CD with WinPE, then flash BIOS (if using Samsung Flasher need to remove version check is BIOS is current, or directly use WinFlash)

What's causing this?

After I fixed my BIOS I tried to re-enable UEFI booting my linux using "efibootmgr", which instantly messed up my BIOS again (but I need stuff like that twice...)

So I messed around with HexEdit and efishell and found 10 - in words TEN - efi boot entries within the Samsung BIOS, that are not even shown in "efibootmgr" - the first Entry is "Setup", second is "Recovery", third is "CD-ROM" and so on, so it seems like Samsung is misusing those hidden bootentries for their own stuff, putting the Setup into the first boot entry, which will be overwritten by efibootmgr - explains why it was still booting, but unable to enter Setup.

Since I found the key assignments to these entries within Samsung related BIOS modules, they are responsible for this non-standard stuff. Thank you, Samsung.

My stuff still does not explain complete bricks like others have encountered. But maybe the hint with the version 1.0 efishell might help, or even pressing F3 still helps, if the BIOS is not bricked completely.

For all the Linux EFI programmers: Those bootentries are there, but only shown by efishell. Why does the nvram-module in linux not show them? Maybe there is an unusual way to get them from the nvram - if you could check them you should be able to avoid these bricks..