TeraByte Unlimited

This appears to be invalidation of the prior MS 3rd party signing.
We've been waiting since July 30th for MS to sign the updated version of
our software loader. Now it's becoming an urgent matter.

For now, don't install the secureboot-db/shim/shim-signed update.

On 10/9/2020 10:02 PM, Brian K wrote:
> Derek,
>
> I've done this half a dozen times and it's consistent. It is due to these 3 updates...
>
> secureboot-db
> shim
> shim-signed
>
> I use Mint20 but the updates should be the same for Ubuntu. To fix it...
>
> Disable Secure Boot in the UEFI BIOS.
> Boot IFL and restore your Ubuntu image from a few weeks ago.
> Get into the BIOS again and enable Secure Boot. In addition I had to "Restore Factory Keys". Enabling Secure Boot wasn't enough.
>
> If you don't restore the old Linux image the Secure Boot Violation error will be seen again after you next boot Linux.
>
> I've run the Linux update without the above 3 entries and all is OK.
>
>

I had my current Ubuntu OS installed. Will continue testing with no Ubuntu and with some older versions. Will let you know how that goes.
Thanks for the link regarding Secure Boot support.

Further testing...
I removed all traces of Ubuntu from my system - nothing in the EFI, /root, or /home partitions. Booted the system up a couple of times, and BIU and IFU on a usb stick all boot up without any issue. So that confirms Ubuntu is the problem.

Restored a ubuntu image I had from September 22, 2020. Booted up BIU and IFU, and again all started without any issue. Did a software update within Ubuntu and boom, BIU threw up the red screen of Security Boot Violation. So sometime between Sept 22 and Oct 8 a Ubuntu update is interfering in the proper bootup of BIU and IFU. Which is exactly what you advised me.

Thanks for your assistance.

Derek

Derek, thanks for the confirmation.

I checked the Mint20 updates today. secureboot-db is no longer in the list. The two shim updates are still present.
All updates were installed and there is no longer a Secure Boot issue.

yes, they pull that, the list wasn't supposed to be installed, it was a
provisional list put out by ms.


On 10/27/2020 5:52 PM, Brian K wrote:
> I checked the Mint20 updates today. secureboot-db is no longer in the list. The two shim updates are still present.
> All updates were installed and there is no longer a Secure Boot issue.
>
>

I have a secureboot-db folder, a secureboot-db.list file, some secureboot-db.xxx programs in var/lib/dpkg/info and a service secureboot-db.service . If I stop and disable that service will that fix the boot issue with BIU, but still allow me to securely boot into Ubuntu?

Derek,

I don't have that folder. Why don't you try your test? You can restore an image if the test fails.

I tested stopping,then disabling secureboot-db service. Rebooted into Ubuntu...okay. Then rebooted into an Image for Linux usb stick and got secure boot error. So, it made no difference. I think it likely that my operating system has updated keys that do not work with the older microsoft keys supplied to TeraByte.

If you applied the erroneous update Ubuntu put out and had to pull it
won't boot with secure boot enabled. You could revert the BIOS back to
the default keys for now. MS is still working with UEFI to figure out
what they are going to do before signing the new items.

On 11/6/2020 2:01 PM, bDerek wrote:
> I tested stopping,then disabling secureboot-db service. Rebooted into Ubuntu...okay. Then rebooted into an Image for Linux usb stick and got secure boot error. So, it made no difference. I think it likely that my operating system has updated keys that do not work with the older microsoft keys supplied to TeraByte.
>
>