Yes, you will need to reboot. Upon reboot, I believe the command to show the Coreboot info is
sudo dmidecode -t 0
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
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.
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.
1 Like
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.
Are there any plans for making updating the BIOS and managing the boot manager easier or more straight forward than using this forum?
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.
Thanks for reply!
@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.
1 Like
I tried running the script on openSUSE Tumbleweed and it looks like building old gcc (6.3.0) with new (8.2.1) is not working. Compilation fails with error:
sem_attr.adb:50:16: warning: use clause for package "Sdefault" has no effect
make[1]: *** [../../gcc-6.3.0/gcc/ada/gcc-interface/Make-lang.in:119: ada/sem_attr.o] Error 1
Here’s an example of fix for similar issue: https://github.com/ghdl/ghdl/commit/252a9169efef06b03061b58743be41e233a80ddb
On a Librem 15v2, it exists with the following message: “Selected image region is not a valid CBFS.” (after trying to extract the binary modules from my own machine). Is it because my laptop does not already run Coreboot or is it something else? (if this is because there is really no way around getting the binary modules out of an already running Coreboot, then I am stuck with a bootstrapping problem…)
@etam: Yeah, that’s the issue with people running gcc 8. There’s some patches to fix it, I’ll try to get that integrated soon. In the meantime, you’d have to downgrade your gcc for it to compile the coreboot toolchain unfortunately.
@bavay: Yes, that’s exactly the problem. It’s a sort of chicken and egg situation right now with those early adopters who have the first generation of machines that came with AMI BIOS. You need to have coreboot in order to update build coreboot. There’s a script here to update AMI BIOS to coreboot (an old outdated version of coreboot, but good enough for the build script to do its thing) for L13v1 machines, but it was never ported to L15v2.
I think that @vivia made a new script that would work on L15v2, but I’m not sure where it is. Will let you know when I find it.
2 Likes
I tried with gcc-7, but it also failed:
gcc-7 -c -O2 -fomit-frame-pointer -m64 -gnatp -gnatws -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc-6.3.0/gcc/ada -I../../gcc-6.3.0/gcc/ada/gcc-interface \
ada/b_gnat1.adb -o ada/b_gnat1.o
b_gnat1.adb:174:79: "SS_Stack" not declared in "Secondary_Stack"
b_gnat1.adb:174:89: incorrect constraint for this kind of type
b_gnat1.adb:268:56: "Runtime_Default_Sec_Stack_Size" not declared in "Parameters"
make[1]: *** [../../gcc-6.3.0/gcc/ada/gcc-interface/Make-lang.in:948: ada/b_gnat1.o] Error 1
I got exactly the same error with gcc-6.
Hi,
Please, tell me if I’m wrong (hopefully).
If there’s no way to restrict (via a password or something else) booting from a usb flash drive in the default coreboot + seabios setup…
and it’s possible to flash coreboot from a pureos live usb…
doesn’t that make it pretty easy to flash a malicious bios into someone else’s librem?
@etam I think that the issue is coming from the gcc 8 ADA compiler, and I think you downgraded gcc, but you’re still left with gcc 8 ada (I Think it’s called gnat), so you should look into that.
@pandark: yes, you are right. There’s really no good or easy solution against that unfortunately.
We are however working on preventing that with Heads. Since Heads allows you to verify if your firmware was tampered with, and once an OS is booted, it won’t be able to flash the BIOS, and you’d only be able to write to the flash via Heads itself, we can prevent that from happening by only allowing you to flash the firmware if yo insert your Librem Key for example.
I think that the issue is coming from the gcc 8 ADA compiler, and I think you downgraded gcc, but you’re still left with gcc 8 ada (I Think it’s called gnat), so you should look into that.
Right. I was searching for how to configure this. For gcc and g++ it’s obvious, just export CC and CXX variables. I was looking for something similar for gnat and in coreboot/util/crossgcc/buildgcc I’ve found it was using ${CC} -print-prog-name=gnat1 to check if it has gnat installed. I thought it was using this to actually get the proper command for gnat. Now I’ve took a look at it again and found that it’s just checking if the executable returned by command above exists and then just uses gnatbind without any configuration possible.
Or maybe I’m missing something? I have commands gnat-8, gnat-6 and gnat being a symlink to gnat-8. Is there any way to force usage of gnat-6?
I have no idea unfortunately. Would changing the gnat symlink from gnat-8 to gnat-6 fix it ? If both are still found by the configure and gnat-8 is still used, I’d probably just rename the file until I finish building.
I do believe that has been fixed in coreboot master (they switched to building gcc 8 for the toolchain), but we won’t be updating coreboot until the next release is out (which would be 4.9 and I think it’s meant to be released in a couple of months).
Good luck.
I’ve made a directory with all gnat commands being symlinks to their *-6 versions and prepended it to $PATH. This seems to work:
$ which gnat
/home/etam/code/purism-coreboot/bin/gnat
$ gnat --version
GNAT 6.4.1 20180626 [gcc-6-branch revision 262132]
[...]
But now the compilation fails with lots of errors like
error: "s-stalib.adb" and "xtreeprs.adb" compiled with different GNAT versions
or
error: "s-parame.adb" must be compiled
error: ("/usr/lib64/gcc/x86_64-suse-linux/6/adalib/s-parame.ali" is obsolete and read-only)@etam: Did you try to delete the coreboot directory before rebuilding? If half the files were already built with gnat-8 and you switched to gnat-6 that would cause problems.
If you already did try a clean build, then I’m not sure what the issue could be…