Unable to boot from USB in Dell XPS 13 (9370) - secure boot problem?

[altera]

I am unable to boot from the USB (3.9.5 version), created from Basic Multilanguage ISO (Desktop 64 bit) on Dell XPS 13 9370 with Secure Boot enabled (and with latest Bios which is 1.16 - just released on 24th of September, which I guess might be relevant). The same USB successfully boots on other computers (e.g. Thinkpads) where Secure Boot is not enabled.

This Dell XPS when trying to boot from USB resets the boot process after a short while (without any information written on the screen) and launches internal Bios diagnostics. However, during this process a log is created on installation USB EFI partition (in Dell directory) that contains the following line:

[Operating System Loader signature found in SecureBoot exclusion database (‘dbx’). All bootable devices failed Secure Boot verification]

Other Linux distributions (I tried Ubuntu 20.04 and Linux Mint 18) boot without any problems.
Unfortunately I cannot disable Secure Boot on this machine.

[Daniel]

Thanks for reporting this. The soon-to-be-released Endless OS 4 has an updated bootloader which will solve this.

Does your BIOS setup menu offer any way of enrolling a binary as trusted or something like that? Maybe you can ask it to explicitly trust Endless’s bootloader.

[altera]

Thanks! Is it possible to download iso image of Endless OS 4 beta for testing (I noticed that it’s possible to test it by upgrading from existing install - but obviously I cannot do this :-)?

[Daniel]

We haven’t built an ISO yet for this branch. But if you don’t mind waiting a day or two we may have a solution or workaround. Either an ISO as you suggest, or potentially just an updated bootloader file that you can drop onto the VFAT EFI System Partition of the USB disk (& again to the installed system)

On my own (older) XPS 13 it’s not possible to enroll a binary as trusted in the BIOS menu as noted above. It does have the option of appending a db entry, which is equivalent, but is a process even more fiddly to undergo.

[altera]

Waiting for a day or two sounds good I guess both solutions (i.e. ISO and modified bootloader) would be OK. Thanks in advance!

There seems to be BIOS section devoted to key management - but it also does not allow to enroll a single binary.

[Daniel]

Sorry for the delay - still working on getting a new image ready. Just working on one last detail, should hopefully be ready in a day or so.

[altera]

No problem!!! Thanks again!!!

[jprvita]

Hello @altera, sorry for the extra delay here. Some of the earlier images we built of the eos4.0 had a problem with its ostree references that would prevent you from updating it properly in the future, so we wanted to get it fixed before sharing an image here.

We don’t produce actual beta images (i.e., images that would be pre-configured to follow the beta channel), but you can use this eos4.0 nightly image from the date of the latest beta release, which will have the same content as 4.0.0-beta4: image (3.5 GB), checksum.

The main difference is that it is set to follow the nightly updates from the unreleased eos4.0 branch. I recommend you switch it to the beta channel right away, so it updates to the next beta releases instead of the nightly builds, where things have a slightly higher probability of breaking. After 4.0.0 is released you can switch it to the production channel or continue on the beta, as usual.

And thanks in advance for your help testing this! Please let us know if this version boots correctly with Secure Boot enabled in your computer, and if you encounter any other problems.