Building coreboot from source (official script)


Hello Kakaroto,
I was not able find in the entire thread answer to my issue, but there is mentioned similar one.
On my Librem 15v3 with Ubuntu 16.04 Lts the result of the build is the warning. I have put echo lines in the script in order to check the SHA1 hashes comparisons and there is difference.
There is the output:

The ME region can be reduced up to:
00001000:00111fff me
Setting the HAP bit in PCHSTRP0 to disable Intel ME…
Checking the FTPR RSA signature… VALID
Done! Good luck!

Finished building coreboot for Librem 15 v3

SHA calulated 4bd15cf62c91d224cf73d3eec6f9ca1eef707c2cfb5b005ce681133fcd4ec306
SHA referal 5a9b8e7f5e327e3b3fcb5513c091b6d476817fcf5a9c981c6d2727a220f4a30e
WARNING: Built coreboot image hash does not match the expect reproducible build hash

Can you suggest next steps?


Hey @kakaroto!

I tried running your script but unfortunately it seems it didn’t exit gracefully.

The exact steps I took were:

sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff

chmod 744 ~/Downloads/

sudo ./

I then input “3” since I’m using a 13v2 and “1” since that was the default.

Below are the last few lines of output before the error:

(...) c++ -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DRAR_SMP -DUNRAR -c qopen.cpp c++ -o unrar -pthread rar.o strlist.o strfn.o pathfn.o smallfn.o global.o file.o filefn.o filcreat.o archive.o arcread.o unicode.o system.o isnt.o crypt.o crc.o rawread.o encname.o resource.o match.o timefn.o rdwrfn.o consio.o options.o errhnd.o rarvm.o secpassword.o rijndael.o getbits.o sha1.o sha256.o blake2s.o hash.o extinfo.o extract.o volume.o list.o find.o unpack.o headers.o threadpool.o rs16.o cmddata.o ui.o filestr.o recvol.o rs.o scantree.o qopen.o strip unrar Cloning into 'megadown'... remote: Enumerating objects: 540, done. remote: Total 540 (delta 0), reused 0 (delta 0), pack-reused 540 Receiving objects: 100% (540/540), 124.01 KiB | 1.39 MiB/s, done. Resolving deltas: 100% (261/261), done. Note: checking out '83c53ddad1c32bf6d35c61fcd12a2fa94271ff77'.

You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b

HEAD is now at 83c53dd Create LICENSE

Downloading ME 11 Repository from!DNdDVQ7I!hronBMVN8m82JciiT6UQwtwh-LVlHXIo-NzTB0324rk
Please be patient while the download finishes…
[pv] is required and it’s not installed

Was it successful? What’s [pv] supposed to be?


I just read a bit more into the script, and I noticed it didn’t include the “pv” dependency in OP’s dependency disclaimer.

The dependencies command should be

sudo apt install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7 pv

and while python2.7 was included in PureOS by default, pv wasn’t, hence my error.


Hey @kakaroto

This is a separate question… But how vulnerable is your script to MitM attacks and malicious firmware?

  • Regarding MitM attacks:

On a cursory glance, your script does check SHA256sums of the downloaded files, which is great, but there is no checksum available for the script itself, meaning there is the possibility of the script (and therefore the included checksums) being modified by an attacker (the same thing happened to the linux mint website not too long ago… The ISOs and checksums were modified by attackers at the same time)

If you included checksums for the script and had them hosted on a different server, that would give an additional layer of security and confidence to whoever used your script.

I made a 0bin of the checksums, with no expiration here:

If they’re correct, I’m sure others would appreciate having them.

  • Regarding malicious firmware:

I also noticed your script says it extracts the binary blobs from the machine being run on. Are the hashes of the blobs on the local machine checked as well? Or are they assumed to be good because they’re not downloaded?

Thank you for your patience with all my questions! :grin:


Did you check the git version? I believe it happens only when the git version you use is too old (which gives a different output on ‘git describe’)… look in this thread for more info about that.

The script is taken from the git repo and the last git commit is signed by me with my GPG fingerprint available in the purism’s About/Team page.

Yes, every single one. The only exception is the ME firmware on the Broadwell (l13v1 and l15v2) machines because the hash changes from one machine to the next, although I think that if we clean out the ME after dumping it, we can get a unique hash for all machines.


Thanks for you reply, I will do the checks.


Just received my Librem 13. The script successfully built and updated Coreboot from 4.7-Purism-4 to 4.8.1-Purism-2.
I had to sudo apt install pv since it was not installed, as @jonatack did.


I finally got the courage to update my firmware, and it looks like I was successful.

I suggest updating the instructions on the Purism coreboot page, because the output from cbmem enumerated there is different from what is expected now for Intel ME. This is judging from others’ posts, e.g. @tez, and my experience. I too see ‘FW Partition Table : BAD’.

Updating firmware is scary enough without seeing different expected results.

UPDATE (11/6): I created a new tracking task to update the output on this page.


Just built the latest imagine for my L13 v3, and had no problems. Thanks!

Coreboot 4.7 for qube os

Hello! I’m still coming with my L15 v2 questions… :slight_smile: I’ve edited your script to accept the L15 v2 (with the proper checks for it), but now it returns an error when checking the files it downloads from the ChromeOS repository:

Intel Firmware Descriptor file hash does not match the expected one

Is there anything I can do there? Is it that the hash should be different (so I should just regenerate one) or is it that something is going wrong?


Verifying hash of file :
File hash is valid: d17650df79235dca0b13c86748e63c227e03c401
Decompressing the image…
Verifying hash of file : chromeos_8743.85.0_tidus_recovery_stable-channel_mp-v2.bin
File hash is valid: 72240974b72d5328608a48c0badc97cf8653a5f4
Extracting ROOT-A partition
Verifying hash of file : chromeos_tidus_root_a.ext2
File hash is valid: 038dd8cfae69565457e45c1e1a7515a411a32fb3
Extracting chromeos-firmwareupdate
Verifying hash of file : chromeos-firmwareupdate
File hash is valid: fff693b74088f79d292c17c9ef5efacdba8915f8
Extracting coreboot image
Verifying hash of file : chromeos_tidus_bios.bin
File hash is valid: 3775dd99a1e4e56932585ce311e937db12605e2f
Extracting Memory Reference Code: mrc.bin
Verifying hash of file : mrc.bin
File hash is valid: eb2536a4e94c6d1cc6fe5dbd8952ae9b5acc535b
Extracting Intel Broadwell Reference Code: refcode.elf
Verifying hash of file : refcode.elf
File hash is valid: e3f985d23199a4bd8ec317beae3dd90ce5dfa3cc
Extracting VGA BIOS image: vgabios.bin
Verifying hash of file : vgabios.bin
File hash is valid: 17db61b82e833a8df83c5dc4a0a68e35210a6334
The VGA BIOS binary has been extracted from your current BIOS.
Extracting Intel Firmware Descriptor and Intel Management Engine images
Verifying hash of file : flashregion_0_flashdescriptor.bin
File hash is invalid. Found c762f1f7e6c9c8663778d07c6198ec245e77e6f4, expected 359101061f789e1cfc13742d5980ac441787e96c
Intel Firmware Descriptor file hash does not match the expected one