Red Hat Bugzilla – Bug 896212
Bad vendor ships bad key databases
Last modified: 2014-02-05 09:57:44 EST
Description of problem: Using either a live usb or simply writing the 64 bit disk image to a CD, my satellite s855 claims that the device does not have a valid secure boot signature.
Version-Release number of selected component (if applicable): This is for the new Fedora 18 (XFCE), not beta.
How reproducible: It happens every time I attempt to boot to either method of installation.
Steps to Reproduce:
1.Write image to CD.
2.Change setting to boot first to CD.
3.Boot and observe blue box with text indicating that the device did not have a valid signature and therefore secure boot stopped it.
Failure to boot device.
Begin installing awesome new Fedora.
Additional info: This is one of those Windows 8 preloaded machines. My school offered a bloatware-free Windows 8 Pro, and that installed just fine. I have updated the bios.
This is using the 64-bit image? Are you able to test the normal install image rather than the XFCE one?
I'm certain it was the 64-bit image, but I am willing to admit that the error could definitely be on my side of the fence, as I am a novice at low-level stuff.
I only have cds, not dvds, so (just in case I was messing up USB stuff) I am trying the LXDE image next (as it will fit on a cd). Tomorrow I'll buy some DVDs and try the mainstream image. Just burning a DVD (how old-fashioned) way for the most mainstream edition should probably help.
If I disable secure boot, the live cd loads right up, so that should help clarify that it isn't like I completely fudged burning a cd.
I have also tested LXDE 64 bit. While either CD will boot up with secure boot disabled, neither will with it enabled. The computer explicitly states in either case: “Boot Failure: a proper digital signature was not found. One of the files on the select boot device was rejected by the Secure Boot feature.”.
Ok, the XFCE image appears to have a signed copy of shim. Can you verify that the md5sum of the iso you have is 31786b7077f1bc5c657988f6d46a18d0 ?
The md5sum of my image is the same.
Ok, just to rule out one further possibility, could you possibly try the 64-bit version of Ubuntu 12.10 as well?
Ubuntu 12.10 64 bit failed in the same fashion.
Which version of the system BIOS are you running?
I am running version 6.40.
Ok, the firmware definitely contains a copy of the appropriate key, the question is whether it's attempting to validate against it or not.
Maybe the exact wording of the failure helps: “Boot Failure: a proper digital signature was not found. One of the files on the select boot device was rejected by the Secure Boot feature.”
I don't know what exactly to do to help test things. (I also don't want to waste your time if it is simply my machine.) However, I can say that the machine came with the lowest level windows 8 (and associated crapware), but did allow me to install windows 8 enterprise evaluation edition, then windows 8 pro (from my school). I assume that each of those had to have their key evaluated, and that the process was successful.
Ok, I took some time looking at the ROM dump - it seems that the third party key has been placed in the KEK database, not the db.
Did this system ship with Windows 8? If so, did it have the Windows 8 logo on it?
It shipped with windows 8 and it has the sticker on the bottom.
One of these stickers? http://cdn.arstechnica.net/wp-content/uploads/2012/12/windows-8-stickers.jpg
It has the one on the left. yes.
Toshiba tech support, who sounded about as knowledgeable as me, unfortunately, found it plausible that the key might not be in the most recent bios update. What do you mean when you say "not the db", but "in the KEK database"?
There's several key databases in UEFI. Db contains the keys that are trusted for booting software, kek contains keys that are trusted for installing updates to db. Kek keys aren't trusted for booting software, so if the key is installed in the wrong database then verification will fail. I took a look at the firmware image from this device and it looks like the key is present, except in kek rather than db. This is almost certainly an error on the part of the vendor that manufactured this machine for Toshiba.
This is supposedly fixed in firmware version 6.60, but you may need to contact technical support to get hold of it.
They recently released the new version. I double-checked after installing it, and indeed have that version now (6.60).
However, neither my fedora nor sabayon disks work. They both fail just as the did previously.
I've looked at the firmware image and it seems to have the right key in the right place. Just to make completely sure of this - if you put in a 64-bit Fedora 18 CD, it still gives an "Invalid signature" error?
"Boot Failure: a proper digital signature was not found. One of the files on the select boot device was rejected by the Secure Boot feature."
You apparently have to update the BIOS under DOS, not using the Windows updater.
Sorry for the delay. Life got busy. I never updated to 6.60 under dos, but I did burn 6.70 to disk and booted the computer to the disk, and flashed by typing flash from the command line and hitting enter. It was not done from windows like 6.60 was.
I get the same boot failure.
Is the update incremental such that I needed to do 6.60 properly first?
I have a Toshiba S875D-350 and have the same exact problem.
Ubuntu, Fedora(cd and dvd, regular and kde of each tested) and Opensuse all do the same thing. I have tried 18 and 19 of Fedora, and 1 version of Ubuntu/Opensuse.
I get the same exact blue blox on my system, even if I install with Secure Boot turned off, and repair-boot, and then enable it I still get the same error.
If anyone has any tips/help I would love you.
Right now I'm flashing my BIOS to the newest version to see if that helps.
Looks like it has exactly the same bug - the third party signing key is in the KEK database, not in db.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.