slight change of topic. I have been using the script repeatedly and mostly without hitches under PureOS (librem 13v3) and am on 4.8.1-Purism-3.
Since I am one of the people affected by the CPU freq stuck at 400Mhz / fan full blast after
waking up from sleep (which seems much better (less frequent) with 4.8.1-Purism-3!! – thanks), I would very much like to update as soon as possible. Is there a way to get a notification that a new coreboot version is available – or what is the easiest way to check.
Eventually, I want to run Qubes 4 on the laptop; given the CPU freq / fan issue, I have
not made the switch as I want to know that the hardware is under my control before moving to an unsupported configuration. The question coming up here is: how do I run the build script for coreboot under Qubes ? Should I run this under dom0, where I do not have internet (by default), or can I run this from an AppVM?
Awesome! Not sure your reinstall/update made a difference, I think the removing/re-installing the drive is what fixed it!
I’m really baffled by this issue. I think it’s unrelated to coreboot, that it’s an EC issue, but it doesn’t seem to be it according to reports (and you saying it happens less with latest update)!
AFAIK though, if you suspend/resume the machine, the fan/cpu go back to normal so it’s a relatively easy/quick fix to the problem.
Not at the moment, no, but we are currently working on integrating with fwupd, which would then give you the notification. We are also getting deb packages ready (which should be very soon) so if you use that (not sure yet which repository the debs will be in) then you’d probably see a new coreboot package update.
It would be a 4 step process I guess :
First run the script in a regular VM, and tell the script to dump your flash from local machine, which would probably fail but it will compile flashrom for you
so copy the coreboot/flashrom/flashrom file to dom0 and dump your flash from dom0 then copy the rom back to your regular VM and name it coreboot-orig.bin,
re-run the script and this time select the second option “Extract from a pre-built coreboot image (filename must be coreboot-orig.rom)” (never realized it says ‘pre-built image’, I thought it always said ‘previously dumped image’)
When it’s done, say no when it asks you if you want to flash it, instead copy the generated rom back to dom0 and flash it from there.
Thank you for commenting on this here. What do you mean by ‘EC issue’? I also have the sinking feeling that this is not firmware/coreboot related, but ‘something’ else (flaky hardware??).
At the moment, things are ‘better’ (i.e., the occurence is rare), although in the relevant thread someone posted yesterday that despite the latest coreboot the issue remains frequent.
As to easy/quick fix, your mileage varies: I would like to use the laptop in lectures/conferences, i.e. in very quiet environments – the fan going full blast is quite audible and potentially embarassing. so, for me it is a sincere usability issue.
Further, thanks for the qubes outline – it’s about what I figured. I’ll take a closer look at your scipt so that I can separate the various steps. But at the moment I am still waiting before putting ‘unsupported’ software on the Librem
Yeah, the EC is the embeded controller and the EC is the only one (as far as I know) that controls the fans. We are still working on freeing the EC, so hopefully once there is free software for it, we’ll be able to eliminate that bug (or at least confirm if it comes from the EC or not).
I wish that were true! Unfortunately, the script does not currently seem to be cryptographically signed, let alone signed with a key in the strong set. In particular, the Git repository containing the script seems to be this one. All of the recent commits to that repo are unsigned. Nor have I been able to find a detached signature anywhere, applying to the script. (If it is signed, and I have failed to notice this, please could you point me to the signature?)
That being so, we cannot be very confident that nobody has tampered with the script. This has obvious implications for the amount of trust we should place in the resulting Coreboot build.
Please could you sign the latest commit (and future commits) in the repo - or at least publish a detached signature for current and future versions of build_coreboot.sh - with a key that clearly belongs to a Purism employee and that is in the strong set? Thanks.
Thanks @sampablokuper for the suggestion, it is indeed a good point and it’s important to sign the commits to make sure it’s valid.
I’ve just made a new commit to the script today and I had it signed. you can see on gitlab that the commit is verified as it matches my user’s configured GPG key, which should prove its authenticity : https://source.puri.sm/coreboot/coreboot-files/commit/075bfa7ce16ac33f11c747646b84d5f8d12af20f
I’m also asking to have my GPG fingerprint added to the About page on the Purism website for extra validation, though I don’t think that to be needed.
Speaking of prior commits, I would be especially grateful if you could check that in your latest (signed) commit, the URLs and hashes of the binaries that the script downloads (e.g. the ME blobs from Mega) still match the values in your records (e.g. in your browser history, or your Bash history). Thank you.
I see nothing wrong in principle with having your fingerprint on the About page, but it would be much more meaningful if you were to have your key signed with a key, such as Todd Weaver’s key, that is in the strong set and that belongs to someone trustworthy in relation to Purism; and if you were to then publish that signature to a key server.
(Also, your key is only 2048-bit, and - at a glance - I think you might not have created a sub-key. Using a master key for day-to-day work puts the master key at risk. If I am right about what you are doing, then when you have an opportunity, please could you follow, e.g. https://blog.josefsson.org/2014/06/23/offline-gnupg-master-key-and-subkeys-on-yubikey-neo-smartcard/ and migrate to a more secure set of master and subkey key-pairs? If I was mistaken, then please ignore this parenthesis.)
I am using Solus which does not use apt. So I do not have all dependencies available (although i tried it anyway). When I run the build script I get the following error:
HOSTCC cbfstool/cbfstool.o
In file included from /home/christiankaindl/coreboot/util/cbfstool/cbfstool.c:27:
/home/christiankaindl/coreboot/util/cbfstool/cbfs.h:23:10: fatal error: vb2_api.h: No such file or directory
#include <vb2_api.h>
^~~~~~~~~~~
compilation terminated.
make: *** [Makefile.inc:110: /home/christiankaindl/coreboot/util/cbfstool/cbfstool.o] Error 1
So if the file isn’t found, it either didn’t get downloaded, or it’s not where the compiler needs it to be. So I would try digging around to see if you have vp2_api.h, and if you do, check where it is.
Why I’m getting this with the actual build script? Is that a temporary error? Can’t find that URL inside the script? The server seems to be unreachable?
fatal: unable to access 'https://code.puri.sm/kakaroto/coreboot-files.git/': Failed to connect to code.puri.sm port 443: No route to host
$ traceroute -n code.puri.sm
traceroute to code.puri.sm (138.201.183.166), 30 hops max, 60 byte packets
1 192.168.43.1 1.360 ms 7.027 ms 6.889 ms
[... snip intermediate nodes, they are all responding quickly ...]
10 213.239.229.142 41.469 ms 40.918 ms 37.109 ms
11 138.201.224.153 39.540 ms 38.983 ms 38.945 ms
12 138.201.224.153 582.296 ms !H 578.202 ms !H 578.337 ms !H
$ host 138.201.224.153
153.224.201.138.in-addr.arpa domain name pointer proxmox1.puri.sm.
I want to say I saw something about code.puri.sm getting moved to source.puri.sm. I could be wrong, but source.puri.sm does at least exist and is Purism’s GitLab. And it looks like this is the repo in question
I’d look there to see if the build script there is more up-to-date.
Can I change the default boot order when building coreboot?
I have a Nitrokey Storage with my /boot partition on it & sometimes forget to hit the esc key when starting my Librem 13 to select where to boot from. To avoid having to do this it would be helpful to be able to change the default boot order.
You’re probably using a quite old version of the script… make sure you download the latest version (see the first post here) and try again.
Not with the build script, but you could use this other script to do that : Change boot order
It only gives you the choice between M.2 SSD or 2.5" HDD to choose as boot options, but you can just tweak the script as you see fit. You can get the nitrokey’s actual boot name from ‘cbmem -c’ output I suppose. Then just add it to the bootorder.txt file that the script creates.
Note: you might need to add ich_spi_mode=hwseq to the flashrom options for it to work.
You’re probably using a quite old version of the script…
It is the newest version of the script, but it was in the build directory with an old coreboot root (April 2018). I’ve created a new one and now it seems to work.
@Sascha yes, we’re working on fwupd integration, and the work to get the coreboot binaries built and an actual updater script (rather than a build script) integrated into deb packages is done (and just waiting review I believe).
@amanita ah, that’s possible, I hadn’t thought of that, but yes, if it found an old directory, it would just try to ‘git fetch’ instead of doing a ‘git clone’ with the new URL.