Building coreboot from source (official script)


#287

Just noticed this, I explained it to you in the other thread you created, but for other linux newbies out there, maybe this is going to be useful.
When it says “are you root?” there at the end of the command, it’s not actually asking you the question, it’s a hypothetical/rhetorical question, in the sense of “it failed to the lock the administration directory, probably because you are not root, did you check for that first?”. And then you should see your command prompt again (where it says private@debian:~$) meaning the previous command is done and now you’re back to the shell (the terminal command interpreter) for you to type the next command. So when you reply here with ‘yes’ what you’re doing is actually to execute the ‘yes’ command, which is why the letter ‘y’ is printed ad infinitum like you said.
there is a linux command called ‘yes’ with the sole purpose of printing ‘y’ indefinitely… this is useful if for example you want to move files and say ‘yes’ to overwrite a lot of them, or you want to run a script that asks a lot of questions and you don’t want to bother and answer yes to everything, you can run ‘yes’ and pipe its output to the input of the new command like this : yes | some_command and it will write ‘y’ for every prompt the new command asks… you can also do yes n or yes hello if you want it to repeatedly print ‘n’ or ‘hello’. Also note, you can stop any command from executing by pressing Control-C, you don’t have to close the terminal to stop it… good to know the next time you accidentally run the yes command.
Give it a try, play with it and have fun, it will help you get more familiar with the terminal and how it works.

This is an FYI if you’re curious on what happened here…
Here, you typed ‘y’ at the command prompt, after the previous command finished. So what the shell here does is to try and execute the command or program y but it doesn’t find one, so it tries to see if you made a typo so that if for example you typed aptt-get it would tell you Command not found. Did you mean apt-get? to help you see where you made the typo, or if you typed chrome (no typo), it could tell you Command not found. chrome is available if you install the package google-chrome with apt-get install google-chrome, etc… (this is just an example, I’m not sure on th exact wording of the sentece, or the name of the commands/package used in this example).
Anyways, to do that, it needs a ‘database’ of all the available commands and all the packages that are not installed and what commands those provide, etc… unfortunately, it didn’t find the database, so it asked you to run the command ‘update-command-not-found’ so it can update its database (this feature is provided by the package ‘command-not-found’ by the way). It didn’t print anything because… I don’t actually know why, maybe it just worked and it doesn’t print anything, or maybe there’s a problem with it not finding where to update its database from so it actually didn’t do anything. Figuring that out is beyond the scope of this thread obviously.

Two things here, first, you only need to type su, you don’t need to do su login. That’s because ‘su’ means “switch user”, so you’re basically telling it to "switch to the user named login’ which I don’t think you have a user named ‘login’ in your system. It still asks you for a password then says it’s invalid, instead of saying that the user doesn’t exist, potentially because it doesn’t want to expose to a user whether or not such an account exists on the system. When you type su without any arguments (without specifying the username to switch to), then it defaults to switching to root.
Second, when you do su, it asks you for the root password (since you’re switching to the root account), not your user’s password, so you need to enter the root password (which I assume you set up as a different one from your user’s password).
On the other hand, when you do sudo, it does ask for the user’s password, because it’s a different thing here, it’s not an actual “switch user” but rather a “switch user and do” to execute a single command. Anyone can ‘su’ to a different user if they know that user’s password, but in order to be able to do ‘sudo’, your account needs to have administrator priviledges already, and it’s meant specifically to give users the ability to run root commands without actually knowing the root password.
Finally, another way to achieve this is to do something as simple as : sudo bash which makes you run the bash command (the Bourne Again Shell). I’ve mentioned the term ‘shell’ to you before, but basically, the “terminal” is just that rectangular black window which interprets your keyboard typing and sends it to the shell and prints to you what the shell tells it to (and it handles word wrapping and resizing of the window and all that), but what you’re thinking of when you think of the terminal is really the SHELL, which is the command interpreter. That program that runs and prints to you the “private@debian:~$” prompt, the one that interprets the up/down arrows to navigate the history of commands typed, etc… that’s the shell. There are many available shells, the most common and popular one being ‘bash’. So when you do sudo bash you’re basically just executing a new shell as root, which is more or less equivalent to opening a new terminal as root.
See for example my list of processes (which I got with the ps faxu command) if I open a terminal and run sudo bash :

kakaroto  2475  0.1  0.6 849836 49400 ?        SNsl Jul10  68:13  \_ /usr/libexec/gnome-terminal-server
kakaroto 28768  0.0  0.1 124868  8292 pts/11   SNs  Aug06   0:00  |   \_ bash
root     19201  0.2  0.1 268304 10000 pts/11   SN   15:24   0:00  |   |   \_ sudo bash
root     19209  2.3  0.0 120696  5872 pts/11   SN   15:24   0:00  |   |       \_ bash
root     19241  0.0  0.0 150960  4096 pts/11   RN+  15:24   0:00  |   |           \_ ps faxu

You see the gnome-terminal-server process which basically handles all of my terminals then executes ‘bash’ within one of its terminals, then when I do ‘sudo bash’ that command gets executed as root, and it creates a new process ‘bash’ as root, from which I ran the ‘ps faxu’ command.

Alright, this might be a little too advanced, but I prefer to explain to people why rather than just say “use sudo bash” with no explanations on why or how that works… that usually just leads to more errors or questions later.


#288

Right now I’m running the script to upgrade to the latest version that includes the NVMe fixes (the 500gb NVMe drive I ordered with the 15v3 has been detected only intermittently since receiving the laptop and I’ve been making do with the second drive for now).

There appears to be a new dependency that it might be helpful to add to the dependency list, if my case isn’t exceptional: pv.

I ran the dependency installation line before launching the script, and they were all present and up to date. Then the script, which stopped with a missing pv message. Resolving it was as easy as apt show pv to see what it is and apt install pv to install it and then relaunching the script.

But if it is a new dependency may as well add it to the list :wink:

UPDATE: Updated successfully to 4.8.1-Purism-3 on a 15v3. Still don’t see the NVMe drive with lsblk, but that’s a different story.


#290

Humm… I think pv is a dependency of megadown (which is used to download from the mega.nz url the ME repository), yep, it needs to be added to the list! thanks for letting me know!
I’m not sure about your NVMe issue though, you have any more information about it ?
As for the gpg error you had (the message which you deleted), I guess it’s good to know that git global config could indeed affect the ‘git am’ that I used. that’s gonna be problematic though, I hope there’s a way to tell it to ignore any global configs…


#291

Yes, if helpful, the gitconfig change that resolved the issue for me was to simply comment out gpgsign = true here, since the user.name and user.email were already present:

# ~/.gitconfig

[commit]
  gpgsign = true

Thanks @kakaroto, I don’t want to hijack this long thread, but in short: The NVMe drive worked fine for about a week, then began no longer being recognized, increasingly often and for longer timeframes. I switched to using the second sda drive. Now I only see the nvme drive roughly every 10 days after an occasional temperature issue when awaking the laptop from sleep, requiring a reboot, and sometimes on those reboots the NVMe is recognized and proposed by default as the first boot volume. Each time, it works for 10-15 minutes, and then suddenly becomes read-only. When I reboot, it’s not recognized anymore until the next appearance. The NVMe had PureOS installed on it when the laptop arrived. About a month ago during a reappearance, I managed to reinstall PureOS on it from a USB flash drive to see if that could help, but nothing changed. Maybe worth mentioning that in both cases the nvme was set up as an encrypted volume; the same for the sda drive. Thanks.

UPDATE: Since installing coreboot 4.8.1-Purism-3 yesterday on my 15v3 (on the second drive, sda), today for the first time lsblk has been detecting the first volume NVMe drive (Samsung SSD 960 PRO 512GB) while running from sda. Coincidence? To be continued…


#292

Thanks, yeah, I figured it was something like that. the thing is that the commit that happens with the ‘git am’ is meant to recreate an exact commit with the same commit hash for everybody (I override the user and email as well as the commit date for both author and committer, which ensures the same commit hash for everybody). This is the only way to ensure that the resulting binary will actually have its SHA256 match in the end, otherwise if ‘git am’ puts a different user/name/timestamp, the commit hash will be different and the script will complain that the coreboot.rom has the wrong checksum and isn’t safe to flash. Now… your gpgsign was at least failing, probably because you had to enter your password and couldn’t within the script, if you had, the hash would have been different… if some other similar config could also affect the resulting commit hash, that would also be a problem. I’m going to investigate using a git bundle instead, or maybe just use SeaBIOS master (which has the fix) instead of trying to apply that single commit on to of the 1.1.0 stable release.

As for your NVMe, I’d say with 99% certainty that the problem is most probably with the drive itself, either it’s not screwed on properly, or it’s defective. I’ve never seen such an issue before, and that model is known to work without problems, so it’s not a software issue as far as I know (even if the problem was from seabios not detecting it like with the specific model that 4.8.1-Purism-3 is fixing, linux itself wouldn’t have had any issues finding it with lsblk). Besides, you say that after 10-15 minutes, it goes into read-only mode, that probably means that it has too many errors trying to access it, which indicates a hardware error. If the drive works flawlessly on another machine of yours, I’d be tempted to say it might be the librem itself (M.2 connector broken or something…)


#293

Thank you, @kakaroto. Friday evening the NVMe 960 Pro showed up again, so I reinstalled a fresh PureOS on it, this time without encryption, and updated/full-upgraded for the first time – before, the drive would go read-only before the upgrade finished. Then, I opened the 15v3, removed the NVMe 960 Pro and put it back in again though it appeared to be properly in place.

It’s been running fine since then for 2 days now. If it continues functioning well I will retry an encrypted installation.

I also ordered an external hard drive case to test it elsewhere, if needed. There appear to be few compatible ones at the moment on the market for NVMe M2; I ordered this one: https://www.amazon.fr/gp/product/B07F2T9196/

UPDATE: The NVMe has been running fine for a week now :+1:


#294

Hi,

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.

  1. 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.

  2. 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?

thanks,

Stefan


#295

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 :

  1. 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
  2. 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,
  3. 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’)
  4. 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.

#296

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

Thanks,

Stefan


#297

In this context, EC stands for embedded controller, but I have no idea what a potential fix would be if it is the EC


#298

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).


#299

Kudos on the script and the work behind it!

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.


Waste of resources to ship your own OS?
What should we have on the pure browser start page?
#300

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.


#301

Thank you!

This does increase the trustworthiness of that commit. https://mikegerwitz.com/papers/git-horror-story explains why the prior commits are still somewhat untrustworthy.

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.)

Thanks again!


#302

Hi everyone,

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

Any thoughts?


#303

Looks to me that that file is part of Coreboot:

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.


#304

Ok, I removed the downloaded coreboot folder and ran the build script again, then it worked!

It seems to be finished now, do I need to restart or something? How do I check what version of Coreboot I have enabled now?


#305

Yes, you will need to reboot. Upon reboot, I believe the command to show the Coreboot info is
sudo dmidecode -t 0


#306

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


#307

Looks like problem with Purism infrastructure:

$ 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.

proxmox1.puri.sm declares code.puri.sm unreachable.