good deal. I plan on bumping the microcode with the coreboot 4.9 update, didn’t want to put out another 4.8.1-based release just for that.
2 Likes
Just tried the new script which worked like a charm – thank you!!
A somewhat off-topic question: I don’t have a Librem key, but would like to give HEADS eventually a try. Ordering from the US is a bit of a hassle, but as far as I understand the Librem key is a rebranded(?) Nitrokey. Could I order just the corresponding Nitrokey (if so, which model) instead ?
It’s not that I don’t want to do business with Purism, but ordering within Europe is considerably easier than having something shipped from the US…
Thanks,
Stefan
PS: Speaking of Nitrokeys – hope this is not relevant:
1 Like
The Librem Key is custom built for us by Nitrokey currently, it is not a rebranded Nitrokey product, and a Nitrokey cannot be used as a substitute for Heads.
I don’t believe our LK is vulnerable to that attack but I’ll double check
2 Likes
I used the new script today and it worked – but now my Librem 13 v3 thinks it’s a Librem 13 v2 (and yes, I picked the right option, I tried it again to verify).
I’m affected by T486 and I’m using this workaround. After flashing the workaround didn’t work anymore and the only reason for that is that the product name changed (so the udev rule I created is ignored). I changed the product name in my udev rule and now the workaround works again.
However, everyone with that workaround will be affected by this…
1 Like
the 13v2 and 13v3 are the same device, just the latter always has a TPM, and the former doesn’t most of the time. They now use a unified PureBoot firmware, which likely identifies the device as a 13v2 in some cases.
2 Likes
Sounds like a quite strange versioning scheme to me… 
According to the script it’s spidey sense told it that my Librem was a 13v3 - I confirmed that by picking the default option. When I used the script the second time it’s spidey sense told it that my Librem was a 13v2, this time I didn’t confirm that, I picked option 4 (Librem 13 v3).
I don’t know the background of that versioning decision but since the product name is used for example in udev rules it may be a good idea to be consistent with that, even if there’s no real difference.
3 Likes
Just finished flashing the bios using the script on Fedora 28, without a problem.
Thanks.
3 Likes
Worked beautifully on Ubuntu 18.04.3 LTS. Thanks!
1 Like
I notice that links is hardcoded in official script. It means that i need to redownload script to get new updates. How to check coreboot updates more easily that redownloading script?
I don’t have a good solution for that currently, it’s on the to-do list
I looked for some explanation why this is important, what it is good for, general background information for this operation, but didn’t find it.
Can someone point me in the right direction?
Maybe it would help you to generate an account on https://source.puri.sm/ . When you’re succefully logged in to your account you can go to the repository of coreboot and select the little bell at the top of the projects detail page to watch the project.
Maybe you also need to change Global notification level in your settings settings to Watch. (I’m not that much of a Gitlab geek to know for sure…)
You’ll get notfiied to the email address you registered with if anything on this project changes.
1 Like
it simply provides a digital record of the device serial, in case it’s needed for support purposes, and in case the sticker on the bottom of the unit is removed/worn. There are additional stickers inside the unit, but this allows for retrieval (via dmidecode) without having to open the unit.
1 Like
Successfully ran the script and flashed coreboot on my Librem 13 v4 running NixOS 19.03, by applying some minor expected tweaks. I used the command below:
sudo nix-shell -p dmidecode wget gzip coreutils flashrom --run 'bash coreboot_util.sh'
The first call will fail since the script pulls a binary build of cbfstool from Purism, however, we can patch it in the standard NixOS way 1 (I am pretty sure we could use the cbfstool Nix package, but I am not taking any chances when flashing hardware).
sudo nix-shell -p patchelf --run 'patchelf --set-interpreter "$(cat ${NIX_CC}/nix-support/dynamic-linker)" tools/cbfstool'
This of course will change the hash of the binary, so then remove the cbfstool hash check from coreboot_util.sh. Now run the first command again and it will succeed. Note that this will only work if you are flashing with the binaries provided by Purism, some more hacking is needed to build from source. It would be tempting to package this properly at some point, but for now I am content not to have to boot a more standard Linux distribution from USB to update the BIOS.
I could add a check in the script to use the host cbfstool, like I do with flashrom – it just didn’t occur to me at the time.
hash check is for the compressed download, not the binary therein, so this isn’t needed
1 Like
I could add a check in the script to use the host cbfstool, like I do with flashrom – it just didn’t occur to me at the time.
A fair suggestion, but given how clean the code was, I really should not complain. I actually assumed that the reason you did not use the same strategy for cbfstool as for flashrom was that the former did not give a clear version when called with -h.
hash check is for the compressed download, not the binary therein, so this isn’t needed
Admittedly, it is the middle of the night, but I think this line 1 does check the hash of the tool/cbfstool binary itself. Mind you, the archive is checked as well 2, just like you said.
well thanks, I’m glad it was reasonably clear. And that’s probably why 
you’re correct, I should have looked at the code rather than going off my obviously faulty memory =P
1 Like
Any help on the dependencies necessary for the script? I’m on Ubuntu 18.04. I’ve read that the script runs great on it. I have a Librem 13 v3.
Edit: Disregard. Figured it out.
While we wait for “Submit firmware to “Linux Vendor Firmware Service” (LVFS) for easy updating”, I have tried the manual update process. It’s kind of scary: it’s basically curl https://puri.sm/something | sudo bash seemingly without any cryptographic verification beyond HTTPS. I would have expected some validation like OpenPGP signatures or something more at least. But let’s leave that aside for the moment.
I’m writing here to report a regression that was introduced in this upgrade. I’m having a bit of trouble figuring out which version I updated from (I seem to remember I was running SeaBIOS 1.11) but since the upgrade (to SeaBIOS 1.12), the resolution of the splash screen is a little out of whack. While the first Purism logo that pops up after the SeaBIOS bit used to be all nice and shiny, now it’s bigger and blurry. It looks like the resolution of the display doesn’t get initialized properly. This also affects my grub display, which is “bigger” than it was before, and also leaves a blank aread on the right of the screen.
I’d be happy to provide screenshots or videos – although I’m not sure how to do that at boot time short of using an external camera – if you tell me where to put those (here?)…
It’s not a deal breaker: the machine still boots and the display is readable. It’s just too bad because it was looking much better before and it doesn’t feel like much of an upgrade at all.
(It would be great if the updater script would also show which versions we’re upgrading from and to, along with release notes, by the way…)
Thanks in advance,
PS: I’m writing here because that’s what i was told to do in the coreboot post, let me know if I should send this somewhere else.
so, a few things:
change log is available here:
With the 4.11 release, we switched from using the VGA BIOS to coreboot native display init. One of the side effects of this is that a single fixed resolution is used from firmware display init until the OS driver takes over. Under the VGA BIOS init, the display would change modes/resolutions several times throughout the boot process (640x400 for SeaBIOS banner, to 1280x1024 for boot logo, back to 640x400 for boot menu/boot text, then to whatever grub specified); now, there’s a single mode change from firmware init (480p) to native panel res (1080p or 2160p).
Since we’re locked into a single resolution for boot, I decided to try and keep the SeaBIOS menu text close to the same size as before, and scaled the boot logo down to match. If enough people disagree with that approach, it’s something we can look into changing
2 Likes