i’ve got a librem 14 here and am having trouble resetting its accompanying librem key to work properly. i have read the docs and attempted to reset the librem key, but i am unable to get the machine to boot properly. i am forced to bypass the librem key checks in order to get the machine to boot.
here is a more detailed series of steps that i have taken to attempt to reset the librem key:
performed a factory reset of the librem key via heads menu
generated fresh gpg keys via heads menu
set new gpg card pin and admin pin via heads menu
exported pubkey using librem drive and reflashed bios with new pubkey
reset tpm and set new tpm pin
reset totp
attempted to sign files in /boot with this reset librem key, fails to sign files in /boot, error messages flash too quickly to easily capture them
on reboot, get 2 short red flashes followed by 10 green flashes on librem key, and drops to recovery console
boot without librem key inserted and gets to heads menu, can bypass librem key checks to boot
i have either missed something from the docs or there is something missing from the docs. i did notice that the default gpg card keygen process uses 2048 bit rsa keys, whereas the librem key i received from purism uses 3072 bit rsa keys, but i doubt this is causing the problem i’m seeing.
There is a lot missing from the documentation, but we are going to ignore discussing it for now and simply deal with your issue first.
Follow these instructions to reflash PureBoot. The order of operation I suggest is to flash Coreboot first, then flash PureBoot over it in a separate sequential session.
After rebooting, you will be prompted to do a factory reset in PureBoot. Accept it and you will be able to properly use the Librem Key for boot firmware tamper protection purposes.
i probably should have mentioned it in the first post, but i run qubes, not pureos. i’m not sure if this is relevant for the current problem i’m experiencing.
That depends on your workflow and threat model. I also use Qubes OS, but have a separate trusted PureOS image on a USB drive for administrative purposes. Some users prefer to update firmware within Qubes OS, whereas I prefer the side channel method.
the page you linked to assumes the user is running pureos and pulls data from onilne, so i would have to prepare a pureos image and an additional usb drive with the latest coreboot on it, right?
is there a reason i should not just update pureboot (coreboot + heads) using the latest pureboot .rom and updating from within heads? purism provides the .rom with the other firmware, e.g. ec, here for librem 14
and i expect the installation process is very similar to that for ec, which i have done previously.
i am surprised to hear that it is possible to update the firmware from within qubes. can you provide info on how that is done?
given that your suggestion for fixing this problem is to update pureboot, am i correct to guess that this is a known problem with pureboot?
the docs indicate it is possible to reset a librem key without needing to reset pureboot to factory defaults and/or upgrade it. while updating to the latest pureboot is surely a good thing, it being a requirement for resetting a librem key is pretty damn annoying. what should be a process that takes 5-10 minutes now requires digging on a forum for tribal knowledge.
Librem Key never flashes green unless you have a correct, signed coreboot. I have this situation after every Qubes update, because /boot files have changed and have to be resigned. coreboot however stays the same, which is AFAIK shown by the green flashing. In such cases, I just confirm that the new /boot is correct and resign it. AFAIK everything is working as intended in your setup. (Although I’m not an expert.)
@radiant Sorry about the trouble with PureBoot. It looks like you’ve gone through a lot of troubleshooting already, and that the remaining step is signing /boot, which is resulting in errors.
It looks like you’ve already done an OEM reset. That resets everything except the TOTP/HOTP secret (it generates the GPG key, flashes it in the ROM, resets the TPM, and signs /boot). It’s possible that some part of that didn’t work, or one of the later steps caused a problem that now has it stuck.
Try doing the following to capture the errors:
Attempt to sign /boot from the GUI menu
After it fails and you’re back to the main menu, select Options → Exit to Recovery Shell
The errors should still be present on the console, take a photo of the screen
There is an internal config for debug output but we probably don’t need to go that direction yet if there are meaningful errors there already, that involves more manual steps.
The process requires another separate USB drive for containing the PureBoot update. The method I am suggesting circumvents that requirement, while also addressing any potential misconfigurations.
I do not actually know how it is done, so either wait until someone else provides more information for you, or manually search on either the Purism or Qubes OS forums.
No, my suggestion is solely based on what I use as a reliable solution to unexpected issues. Feel free to troubleshoot it further at your expense.
Yes, the steps are easy if you already have a PureOS image on a USB drive.
i did this and when i dropped to recovery shell, it had eaten the error messages. however, i did resort to making a video of the errors and they are as follows:
verifying presence of gpg card…
base 10 number: hex number
gpg: no default secret key: No public key
gpg: signing failed: No public key
gpg: no default secret key: No public key
gpg: signing failed: No public key
gpg: no default secret key: No public key
gpg: signing failed: No public key
/boot: Unable to sign kexec hashes
my guess is that this is related to part where i export pubkeys via a usb drive and reflash the bios, but i await your reading of these chicken bones.
what i did should have been the multi-step equivalent of the oem factory reset. after re-reading this part of your post, i figured it was worthwhile to perform the oem factory reset, instead of doing it piecemeal one step at a time. this worked and the librem key now works as expected, where i’m able to update the /boot file sigs.
there may very well be a bug hiding somewhere in here because i would expect the series of steps i performed (factory reset of librem key, generate fresh gpg keys, set gpg user and admin pins, export pubkey using usb drive and reflash bios, reset tpm and set new pin, reset totp/hotp, sign files in /boot) to be equivalent to a corresponding set of custom choices in the oem factory reset process.
after confirming the oem factory reset worked, i attempted to update pureboot using the .rom from pureboot. this was a bridge too far and i have managed to brick the machine, requiring an external bios flash. i will start another thread about this.