Bug report: DE3815TYKHE: 0054: Linux UEFI boot fails with 2 USB flash drives inserted, boot=ok with only 1 USB flash drive

[PBack]

Environment:

- DE3815TYKHE, 8GB RAM

- BIOS version 0054

- no SATA drive attached

- only USB Flash drives attached

- only UEFI boot enabled (not legacy boot)

- OS Selection: Linux

- Fast boot: disabled

- Boot USB devices first: enabled

- Boot Network devices last: enabled

- Unlimited boot to network attempts: disabled

- Bios setup auto entry: disabled

- Boot devices: USB enabled, all others: disabled

- Secure boot: disabled

Boot order:

1. UEFI : USB : Linux Boot Manager : PART 0 : OS Bootloader

2. UEFI : USB : SanDisk Cruzer Force 1.27 : PSTY 0 : OS Bootloader

USB media:

1. Samsung MUF-32BB (bootable)

2. Sandisk SDCZ71-016G-B35 (Cruzer Force 16GB)

When Samsung (# 1) is inserted in front USB slot, the DE3815TYKHE computers boots the Arch Linux system on it via \efi\boot\bootx64.efi.

When Samsung (# 1) is inserted in front USB slot and the Sandisk is in a back slot, the DE3815TYKHE computer boots into:

1. EFI default loader menu, ...10 seconds countdown

2. Reboot Into Firmware Interface, ...10 seconds countdown

3. Intel Visual BIOS

Regression:

- it doesn't matter whether the Sandisk is plugged in the upper or lower back side USB slot

- it doesn't matter whether in which slot the drives or plugged, even when Sandisk is in front slot and Samsung is in back slot, the system will not boot the Linux system, but Visual Bios instead.

Workaround:

1. unplug Sandisk USB flash drive (not desired)

2. press F10 boot menu, and select "UEFI : USB : Linux Boot Manager : PART 0 : OS Bootloader"

Flash drive partitioning:

1.

Model: Samsung Flash Drive FIT (scsi)

Disk /dev/sda: 32.1GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 4194kB 1078MB 1074MB fat32 EFIboot boot, esp

2 1078MB 22.0GB 21.0GB btrfs root

3 22.0GB 32.0GB 9966MB btrfs home

2.

Model: SanDisk Cruzer Force (scsi)

Disk /dev/sdb: 15.6GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 4194kB 214MB 210MB fat16 boot, esp

2 214MB 15.6GB 15.4GB ext2

[idata]

Hello ProBackup.nl,

Thank you for this extensive report.Can you please confirm whether this same behavior occurs with a bootable USB device with Windows 10 64 Bit or not?Regards,Juan Carlos

[Ronny_G_Intel]

Hi ProBackup.nl,

I did a couple of similar tests here but they were not very conclusive I would have to admit.

Would mind providing me with more details?

First thing that comes to my mind after reading your post several times: is there any difference to which USB media you use to boot from: Samsung* and Sandisk*?

I see that the Samsung USB media is booting Arch Linux, is the Sandisk also bootable or booting up any other operating system? In order to understand the issue and the need here, would you mind telling me the reason for this?

Thanks,

Ronny G

[PBack]

Hi rguevara,

The Sandisk is going to be used as a bootable backup of the main OS (Arch Linux on the Samsung FIT USB drive).

At the point of the issue there was not any *.efi file in /EFI/BOOT of the Sandisk. It was recently partitioned and formatted.

The reason is having a primary OS to do work with (yes, it runs from a USB stick), and a (bootable) backup for disaster recovery (to restore primary OS).

With a bootable efi file on the Sandisk, that Sandisk is always booted first. Why is it impossible to set priorities. Or have apply common logic: boot the fastest device first. To my knowledge the front USB connect is USB 3.0 (Samsung stick inserted). Intel NUC E3815 chooses to boot from the slowest USB 2.0 device first. And yes, it does that even just after re-ordering the USB boot device order in the DE3815TYKH "Visual Bios". It just doesn't follow the configured "UEFI Boot Priority" (Legacy boot is disabled).

There are some more flaws in the VisualBIOS UEFI part. Linux command efibootmgr to add new entries to the UEFI boot menu do not survive a reboot.

Thanks for the broken firmware,

PS Juan Carlos, have you though this through? Running Windows 10 on such a slow device?

[idata]

Hello ProBackup.nl,

I was checking the case and I was wondering if you tried a BIOS recovery to see if the problem goes away, I would recommend a BIOS recovery and install the same version, and if the issue persists, rolling back to a previous version (0052).On the other hand, did you use to have the same issue with a previous BIOS version?I hope to hear from you soon.Regards,Juan Carlos

[PBack]

Hello intel_corp,

I have no interest of recovering a BIOS as long as there is simple way to retain my firmware configuration settings. As well as rolling back to earlier versions.

When I see an ordered list of USB devices, I do expect the first (top of the list) device to boot from.

Every other behaviour is a bug, that needs fixing.

[idata]

Hello ProBackup.nl,

I will do some further research and will update this thread once I have further information.Regards,Juan Carlos

[PBack]

Hi Juan Carlos,

I can add systemd-analyze output, that shows that quite some time is spent in Intel's 0054 DE3815TYKE firmware:

systemd-analyze

Startup finished in 9.235s (firmware) + 13.205s (loader) + 3.860s (kernel) + 9.803s (userspace) = 36.105s

Kernel: 4.10.3-1-ARCH # 1 SMP PREEMPT Wed Mar 15 09:17:17 CET 2017 x86_64 GNU/Linux

[idata]

Hello ProBackup.nl,

For troubleshooting purposes please do a http://www.intel.com/content/www/us/en/support/boards-and-kits/000005850.html BIOS recovery and load the BIOS defaults (F9) and save (F10).Please let me know about the outcomes.Regards,Juan Carlos

[idata]

Hello ProBackup.nl,

I was reviewing this thread and I wanted to know if you were able to follow the steps suggested in the previous post or if you were able to resolve the issue?Please don't hesitate in replying to this post if you need further assistance.Regards,Juan Carlos