@kakaroto
I tried again just now to re-run the script (the last try was from 3 days ago) and got this below.
As mentioned I always start from a fresh ubuntu installation from a USB stick.
ubuntu@ubuntu:~/building-coreboot/coreboot/3rdparty/blobs$ git status
HEAD detached at a4b5613
Untracked files:
(use “git add …” to include in what will be committed)
mainboard/purism/
nothing added to commit but untracked files present (use “git add” to track)
I made another attempt, checking out manually that commit and rebuilding again but still it says:
WARNING: Built coreboot image hash does not match the expect reproducible build hash
Really need some insight here guys.
Hi there,
I’m running build_coreboot.sh from a fully-patched Debian liveUSB, according to the details in the February blog post, on an L13v2.
I’m cloning https://code.puri.sm/kakaroto/coreboot-files.git and using the script in a new workspace, allowing it to fetch as needed. I’m selecting option 3 at the first menu (selecting L13v2), and am using the default option for binary blob extraction (option 1, extract from current machine).
I am returned the following error, which appears to reference deprecated libusb debug settings:
ch341a_spi.c: In function 'ch341a_spi_init':
ch341a_spi.c:447:2: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(NULL, 3); // Enable information, warning and error messages (only).
^~~~~~~~~~~~~~~~
In file included from ch341a_spi.c:25:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:1043: recipe for target 'ch341a_spi.o' failed
make: *** [ch341a_spi.o] Error 1"
Searches have revealed little of use, but i could be looking in the wrong places. Any advice would be greatly appreciated. 
EDIT:
I have attempted this with a Pureos live USB with identical error message.
Same error here, same machine, but running PureOS.
Also, a question: should the script be run as root?
/cc @kakaroto
Thanks! =)
I have the same error. Librem13v3 2 weeks old. PureOS up to date.
same issue
ch341a_spi.c: In function 'ch341a_spi_init':
ch341a_spi.c:447:2: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(NULL, 3); // Enable information, warning and error messages (only).
^~~~~~~~~~~~~~~~
In file included from ch341a_spi.c:25:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:1043: recipe for target 'ch341a_spi.o' failed
make: *** [ch341a_spi.o] Error 1
with my Librem 15v3, latest update,
vrata@librem:~/Downloads/coreboot$ uname -a
Linux librem 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux
@kakaroto, any updates in your script that might fix this?
Ok, so digging a little further after reading this coreboot post, I first checked to see how my OS was isntalled and confirmed it ain’t using UEFI to boot.
Since the coreboot script downloaded the git files, I was able build the coreboot/util/cbmem tool as instructed in the post link above, and run the checks to see if my machine already has coreboot installed… and it did,
vrata@librem:~/Downloads/coreboot/coreboot/util/cbmem$ sudo ./cbmem -c | egrep -i "coreboot-|purism|librem"
[sudo] password for vrata:
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 bootblock starting...
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 romstage starting...
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 ramstage starting...
Root Device (Purism Librem 15 v3)
Found mainboard Purism Librem 15 v3
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 bootblock starting...
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 romstage starting...
coreboot-4.6-498-ga841e79-dirty-4.6-a86d1b-Purism-4 Thu Jun 29 22:17:14 UTC 2017 ramstage starting...
Root Device (Purism Librem 15 v3)
Found mainboard Purism Librem 15 v3
although its version 4.6 only, while coreboot is now at v4.7. So I need to figure how to upgrade it.
I also checked if the ME was neutralized,
vrata@librem:~/Downloads/coreboot/coreboot/util/cbmem$ sudo ./cbmem -c | grep ^ME
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code : <NULL>
ME: Progress Phase : BUP Phase
ME: Power Management Event : Moff->Mx wake after an error
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code : <NULL>
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
Looks good, except that my current status show up as,
Current Working State : Unknown (4)
while the post list it as,
Current Working State : Recovery
so not sure what that means. Anyone can shed some light here?
So upgrading to CoreBoot 4.7 (see the forum post as well) is raising this issue, further search reveals that the issue is with the latest libusb-1.0-0 package v1.0.22 which is part of the recent update of PureOS. A patch has been added to the kernel on 27th April, so I guess it will eventually find its way into the PureOS core udpate…hopefully sometimes soon.
[EDIT] I raised an issue in the pureOS tracker.
So, a few updates :
@flopsy: There was indeed a bug in the script, if it wasn’t finding ‘unrar’ and was recompiling it, then it would re-download the me_11_repository file as well, regardless of whether it had the right SHA, and I think that’s why it wasn’t recognizing yours… so that’s fixed, yeay! Jut update the build script and run it to see if it works now for you.
@Celtikill , @josealberto4444 @Russ and @vrata : I’ve updated flashrom to the latest git master which fixes this compilation problem, so update your script, make sure you rm -rf coreboot/flashrom so it can get re-downloaded and rebuilt and you should be fine now. More details in the issue that @vrata raised in our tracker.
And finally @binduck I’m still baffled by your issue and I don’t know why it’s happening. One possibility is that the git version is weird ? One thing I noticed is that you’re building from a USB stick. I would say that that’s not a tested configuration (at least, not by me and I’m glad that we check for reproducibility hashes so you don’t flash a badly built image). I suggest you instead try to build from a PureOS live USB image, at least, you can be sure that it’s a tested environment and it should work as expected, like for everyone else. I hope that helps, let me know how it turned out.
Thanks for all the work. Hopefully I am just being lame but this warning is a little off-putting.
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See the manpage and https://flashrom.org/Laptops for details.
Proceeding anyway because user forced us to.
Found chipset “Intel Skylake U Premium”.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom and were (not) able to successfully update your firmware with it,
then please email a report to flashrom@flashrom.org including a verbose (-V) log.
Thank you!
Should I ignore this?
librem13 v3
Linux purity 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux
@Russ: Weird, I thought the build script was hiding all that flashrom output and giving you a nice progress bar instead…
But yes, you can safely ignore it. The warning says “If flash is shared with the EC” which is not the case for librems (EC has its own dedicated 64KB flash). That’s why we use the “laptop=force_I_want_a_brick” option to the flashrom arguments, and I’ve had this issue for a while now (hopefully to be handled soon) to avoid having that warning appear and scare users.
FYI: Being careful not to brick your laptop is not being lame
You rock! Compiled and flashed clean and updated.
Thanks for the help.
I am not sure if this is the place but while I have your attention. Is there any user docs for coreboot? I am wondering if there is a way to put a password in the bios or any other info? If not no worries, you have been super helpful.
thank you for the fix on the libusb dependecy. However, I am still having issues.
After,
select my target device,
default setup to grab binary blobs from current machine,
the build process requests the sudo pw,
downloads unrar.tar.gz from rarlab.com
and seems to come to an abrupt end with the following lines,
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
http://: Invalid host name.
any idea what is happening?
[EDIT] I tried again, deleting the script and coreboot folder, this time the script ended with the following lines,
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
Couldn't automatically determine the direct link URL to download the ME from.
Please manually download the file from the URL 'https://mega.nz/#!fA03xADA!5uqZiKwNZIP1J27xHzIKVQPQaNfqxdtzKjPRxxwZMc8'
And place the file in '/home/vrata/Downloads/coreboot/coreboot/me_11_repository.rar'
Once done. Please run this script again.
If I try to manually download the me_11_repository.rar I get the following message on the screen,
somehow the key has changed? I used the build script from @kakaroto’s code repo .
I downloaded the file
https://mega.nz/#!fA03xADA!5uqZiKwNZIP1J27xHzIKVQPQaNfqxdtzKjPRxxwZMc8
then saved it locally, then moved it to where it says
/home/vrata/Downloads/coreboot/coreboot/me_11_repository.rar
then re-ran the script and happy happy. You do not need or want to unrar the file.
Hope this helps.
@Russ: We are working on “user docs” (just created this wiki page) but yeah, having a FAQ would be good, and your question is a very frequently asked question No, there is no way to put a password in the bios, because coreboot doesn’t have any user configurable options, no menu or anything like that (it boots in about 360 milliseconds there is no time to show a menu or give time to user to press a key, it actually doesn’t even initialize the GPU, SeaBIOS does that, and if you use Heads (to be released in the future), the linux kernel i915 driver is the one that initializes the GPU… so how could coreboot show a menu/password to the user if the screen is still off by the time coreboot boots the machine?).
@vrata: Your first error was because you hadn’t updated the script before running it, and the second error is because you entered the wrong URL to download the ME repository. I just copy/pasted the URL from your post and it works, if I change it, I get that “enter decryption key” window as you’ve shown.
Thanks for getting back to me. Hopefully I am not overly annoying with questions but if you will entertain me a few more.
What is the menu you get to when you hit ESC before decrypting your hd? A layer between seabios and the OS?
Are there any docs for the TPM stuff?
Thanks again,
@Russ: No worries, that’s what forums are for : asking questions It also helps figure out what kind of user docs to write in the wiki.
So, coreboot is what does the initialization of the hardware, it does it in under 400 ms, then it boots a payload. That payload can be anything… it can either be TianoCore (UEFI bootloader) or it can be SeaBIOS (that’s the menu you see where you get to press ESC) or it can be GRUB (grub installed on the BIOS flash, not the one from your HDD), or it can be a Linux system (Heads in our case, also installed on the BIOS flash, not the one from the HDD).
If you use TianoCore, you’ll get a “BIOS Setup” menu as you might expect, if you use Heads, you’ll get a linux console (our custom menu actually that @Kyle_Rankin worked so hard on so that non-expert users can use Heads without knowing how to use the recovery console).
Here’s what Heads used to look like : https://puri.sm/posts/making-heads-more-usable-with-menus/ and how it looks like now : https://puri.sm/posts/demonstrating-tamper-detection-with-heads/
One thing that was suggested in Heads and which I think someone is working on, is to have Heads ask you to insert your Nitrokey and it wouldn’t boot the machine if the Nitrokey isn’t inserted (or was it only no recovery shell access without the key, or the key only if you want to boot the non-default boot option?). That would be a good alternative to entering a password to boot the system. In either case, you don’t need to have a password set because there are no options to change, so nothing the password to protect you from. As for booting the system, your HDD password should be more than enough, no ?
For TPM, I don’t know if there are any docs, but if you have questions, just ask, and if I can’t reply, I think @Kyle_Rankin should be able to. Note that the wiki was setup only last week so it’s still pretty much empty of content and it’s being worked on, but if you have questions, it will help figure out what kind of information people might want to see in the wiki.
Thanks so much for your helpful responses kakaroto…lots of us Librem users learn a ton reading threads like this! Quick question on the TPM. I have a Librem 13v3 running PureOS fully updated and I’m trying to verify the presence of a TPM on my Librem. I installed tpm_tools and ran the sudo tpm_version command and received the following error: Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17), Communication failure
Any thoughts on a workaround or how to fix?
@thegoat: No idea. You should be able to verify that the TPM is there by pressing ESC during SeaBIOS. If it finds the TPM, it will show a “t. TPM Configuration” menu item. You can also do “cbmem -c | grep -i tpm” to see if the TPM is detected during coreboot. Considering it’s a L13v3, the TPM should be in there since it’s part of the motherboard, not an optional add-on for the v3 models.