Librem coreboot Utility Script: usage, discussion, and help

Withe the release of our new Librem coreboot Utility/Update Script, the old coreboot build script is now deprecated.

The Librem coreboot Utility/Update Script currently provides the following functions:

  • Download/Flash a precompiled coreboot update (either standard/legacy BIOS or PureBoot)
  • Compile a coreboot update (standard/legacy BIOS only, currently) from source and flash
  • Adjust the default boot order (standard/legacy BIOS only)
  • Set the device serial number (in case a previous update erased it)

This topic is for discussion related to the script itself (issues, features, improvements, etc) only. Please create a new post for any issues related to running the firmware itself, for easier tracking

To run the coreboot Utility/Update Script, simply open a terminal and run the following commands:

mkdir ~/updates
cd ~/updates
wget -O
sudo bash

The script has been most heavily tested under PureOS/Debian, so if running another distro, there may be dependency-related issues. Hopefully the script handles that gracefully. If not, let me know and I’ll do my best to fix it :slight_smile:



I am a bit confused reading the blog post announcing the script today. Should people with a TPM chip (I have a librem 13v3) switch to Heads/Pureboot when updating or simply update coreboot?


If you have a Librem Key and would like to use it to validate your firmware and /boot files, then you can switch to PureBoot even if you don’t have a TPM; previously that option was only available for devices with a TPM.

If you’re happy with your current setup and don’t see any benefit from switching to PureBoot (or don’t have a Librem Key), then stick with the standard coreboot/SeaBIOS firmware.


This is great. I tested the coreboot_utils script and it worked flawlessly. Nice.

But I unfortunately made a dumb mistake. I flashed the pureboot+heads bios, but I don’t have the LibremKey.
So I’m stuck in the heads rescue shell. I guess there is no easy thing I can do to get out of this situation.
I’ll try to download a coreboot image on usb and reflash it from the shell…

1 Like

you can use the script to download/configure the standard firmware, copy to a USB stick, then flash via the Heads menu. And you can boot your device now even without a Librem Key, you’ll just have to navigate thru the warnings since you don’t have a Librem Key. If you pop into the community/heads Matrix chat room, someone there can help you through it

1 Like

Yes, that’s exactly how I proceeded. Worked like a charm.
I’m typing this reply on the recovered L13v3. :wink:

This didn’t work as I have a modified /boot in xfs_v5, which needs the latest grub2. And Heads doesn’t know about xfs.
But maybe I’m misunderstanding your statement. :thinking:

1 Like

during testing, I flashed all of my test devices with the PureBoot firmware, but none were configured to use a Librem Key (since others had validated that part already). I was still able to boot both my internal drive and a USB drive just by navigating the Heads menus, at which point I switched back to the standard/SeaBIOS firmware.

1 Like

OK, thanks for the “HEADS” up, I will have to try that again. :wink:
I definitely loved what I’ve seen with the HEADS boot, even though I didn’t manage to even boot from USB.
I’ll dig deeper…


1 Like

Does this mean that anyone using Librem 13 needs to install this script?

1 Like

I ran this last night and have been unable to get the keys from the Liibrem Key because the SDA1-5 fail to mount. If I do not have the Librem Key plugged in then I can only get to the emergency shell. If I have the key plugged in then I can do other things, but every change ultimately fails because the SDA won’t mount. Is the machine bricked now?

1 Like

this script is for updating, changing, or modifying the system firmware. It’s for users wanting to ensure their device has the latest firmware, or who have a Librem Key and want to test our beta PureBoot firmware

no, but the best way to get help with the PureBoot firmware is via the Matrix chat room:!

1 Like

Ok, so i can install the script even though i do not have the Librem Key - and in principla there should be no problems. It will only update the firmware of my Librem 13 V3


1 Like

correct – if you don’t have a Librem key, then you would want to choose the standard firmware option, rather than PureBoot, when using the pre-built firmware update. If building from source, there’s no option currently, only the standard coreboot/SeaBIOS firmware.


Thanks for providing new script. I was able to build CoreBoot on latest Debian unstable/testing (state from 2019-04-19) from source on Librem 13v3. I changed script a bit, for example used newest microcode (0xCA instead of 0xC2 as in default script). This required updating SHA sums in script, but build was still reproducible. Everything (including flashing) worked fine and now I’m running CoreBoot 4.8.1 instead of 4.7.1.

1 Like

good deal. I plan on bumping the microcode with the coreboot 4.9 update, didn’t want to put out another 4.8.1-based release just for that.


Just tried the new script which worked like a charm – thank you!!

A somewhat off-topic question: I don’t have a Librem key, but would like to give HEADS eventually a try. Ordering from the US is a bit of a hassle, but as far as I understand the Librem key is a rebranded(?) Nitrokey. Could I order just the corresponding Nitrokey (if so, which model) instead ?

It’s not that I don’t want to do business with Purism, but ordering within Europe is considerably easier than having something shipped from the US…



PS: Speaking of Nitrokeys – hope this is not relevant:

1 Like

The Librem Key is custom built for us by Nitrokey currently, it is not a rebranded Nitrokey product, and a Nitrokey cannot be used as a substitute for Heads.

I don’t believe our LK is vulnerable to that attack but I’ll double check


I used the new script today and it worked – but now my Librem 13 v3 thinks it’s a Librem 13 v2 (and yes, I picked the right option, I tried it again to verify).

I’m affected by T486 and I’m using this workaround. After flashing the workaround didn’t work anymore and the only reason for that is that the product name changed (so the udev rule I created is ignored). I changed the product name in my udev rule and now the workaround works again.

However, everyone with that workaround will be affected by this…

1 Like

the 13v2 and 13v3 are the same device, just the latter always has a TPM, and the former doesn’t most of the time. They now use a unified PureBoot firmware, which likely identifies the device as a 13v2 in some cases.