Thanks for the reply, I will leave my post up for anyone else having issues. Purism support got back to me and told me to use the live distro and it all worked fine and my NVMe is showing up now.
Hello Purism team,
Today the script is halting after the terminal output of
Flash Region 8 (EC): 07fff000 - 00000fff (unused)
with a message on the next line of
http://: Invalid host name.
Perhaps the link to the Intel firmware repository needs to be updated in the script at line 31?
The latest update was on May 5: https://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html.
I tried updating the script but didn’t get it to work.
Any help would be great
Yes, I have the same issue today…
Thanks for reporting. Yeah, the link changed and it now uses mega.nz which we can’t just use ‘wget’ on. There’s some ‘megatools’ package somewhere which can be used, but I’d have to look into it and fix.
Greetings all, my first post here. I am currently hung up on the same “Invalid host name” issue reported by @jonatack
megatools has an unstable Debian release that can be installed with
apt-get install megatools.
Of course, that alone doesn’t resolve the issue because (I assume) it needs to be referenced in the script - and I won’t dare edit it because I don’t know what the hell I’m doing.
Really excited to get this up and running… thanks all.
It’s not going to be trivial (so it might take a few days) to change the script so it auto downloads the new URL.
In the meantime, I suggest you manually download the file from here and save it as “me_11_repository.rar” inside the coreboot folder that the script creates (run the script once, get the error, download the file, put it in the coreboot directory with the ‘me_11_repository.rar’ filename, then re-run the script), it should then work.
@kakaroto, thank you for the help but I can’t seem to get it working. Still the same error. I downloaded the Intel management file from megadownload, renamed it "me_11_repository.rar and moved it to the coreboot directory after running the script and getting the error. Then I ran the script again and… same error. Of course, that doesn’t mean it doesn’t work, just that I can’t get it working… which isn’t saying much…
I’m using a 13v2 if that is relevant. Thanks again.
I wonder if Purism shouldn’t simply start hosting these files in a consistent location that they control. Maybe place them in a github repo? It seems silly to rely upon an unaffiliated third party for this service especially given how “less than official” it all seems to be.
My assumption here is that this hasn’t happened because there is some inherent risk associated with Purism hosting these files directly. If that’s the case, I’d love for somebody to provide some additional details. Any takers?
@flopsy: I tested and it works fine for me here (and for @jonatack, thanks for confirming), so maybe your download was incomplete (you can check the rar file’s sha256sum is
11a9c199065c513a93c19269ffbb4bb094f8642a97686082e8cd2974673c599d) or you made a typo in the filename.
@jaylittle: you’re right, it’s “less than official” on purpose. Those files are simply not distributed by us. Legally speaking we can’t host the files ourselves, and we can’t distribute the files ourselves, without first signing some pretty strict OEM manufacturer/distributor license agreement with Intel (which prevents reverse engineering for example). Those unaffiliated third parties hosting those files are technically doing it illegally and Intel probably won’t care about them, but if a US-based business does that, then it’s a whole other story.
That’s the reason it’s done this way unfortunately, it’s less than perfect, but it works, until it doesn’t, then that gives us a little more work than usual, but that’s not such a bad trade-off.
@kakaroto, shasum is correct… but the script is still not finishing.
I think the error actually may be with my attempts to repair the previous RAR issue. Perhaps you or someone else can clarify specifically which RAR version I need to download and move to /usr/bin and/or if I need to do anything else as well?
When I execute the script, the process never reaches “UNRAR 5.50 freeware Copyright © 1993-2017 Alexander Roshal”, as posted earlier.
It stops at
strip unrar followed by
http://: Invalid host name.
I get the feeling that the answer to the RAR problem was already clearly posted and I just don’t have the linux chops to recognize it. Thanks.
Hi @flopsy, I could be wrong but it looks like the script is not finding your local copy of
me_11_repository.rar in the
coreboot directory. Download it from the link @kakaroto posted above, rename it, then move it into the
coreboot directory that is created by the script when you run it for the first time and it halts on the error… and not just anywhere in /usr/bin or wherever… for example, I put the script in
~/Downloads/building-coreboot and so the
coreboot directory created by the script was in
building-coreboot. Apologies if this doesn’t help.
Great answer from @jonatack for @flopsy, I’ll just add that unrar is irrelevant because the script itself will build unrar locally (that’s why you see the ‘strip unrar’) and if it does find the rar file, then you won’t see the “http://: Invalid host name” at all… you’ll only see that if it tried to download it.
Using the last version of the script I get an hash different from the expected one. I’m starting from a brand new Ubuntu 16.04 on a USB stick.
(I download the me_11_repository.rar from mega.nz as described).
Any idea @kakaroto ?
Thanks a lot
running “build_coreboot.sh” I get
Submodule path ‘util/nvidia/cbootimage’: checked out ‘64045f993c2cd8989838aeaad3d22107d96d5596’
Unable to checkout ‘b45abbd4d64ae65fa3c927dbba4eff354e29d152’ in submodule path ‘3rdparty/blobs’
Probably that’s why I get a different hash…
@binduck you might need to rm (delete) the checked-out blob (check the command line log output when the script halted) and restart the script so it verifies the hash of a fresh version.
That’s weird. Are you using the latest version of the script ?
I don’t see a hash “b45abbd4d64ae65fa3c927dbba4eff354e29d152” in 3rdparty/blobs, which explains why it can’t check it out, but it’s not supposed to anyway, I get :
Submodule path '3rdparty/blobs': checked out '8eb92ba947e171df11b3c62f5f257ce69b9e2d55'
I’m not sure why it’s doing this to you… can you make sure you have the latest version of the script, and try to run it in an empty directory so it re-downloads coreboot from scratch again.
@kakaroto I follow the guide step by step from here
https://puri.sm/posts/february-2018-coreboot-update/ (“How to build?” section)
Not sure how I can mess this up.
I always start from an empty directory.