I’m going to assume you installed PureOS when you got your hardware. If so, during that process the installer would have asked you to set a root password. If you run su - and then enter that password, it will switch to the root user. You can then follow the instructions Shane posted that had the apt install command you were having trouble with before.
Well, I’ve done exactly that, and saw sub-second 20C temperature differences (hence my mention of Neofetch, which simply reads the temperature data directly). 20C of dissipation in a fraction of a second is an awful lot. When connected to its charger, the fetched temperature would be off by more than 10C from the “traced” temperature 2/3rds of the time.
All this behaviour seems to have been significantly reduced since updating to the latest Coreboot, and the temperature has stabilised somewhat (both with and without Turboboost enabled).
I have to note that I’ve never come close to 90C, no matter how hard I stressed it, so my case may differ from others.
If not by averaging several measured voltage drops across the sensor, does the system just use a single voltage measurement to control the fan?
1 Like
Hi @kakaroto
I ran your build script today (fresh clone) and it fails with the sha checksum error.
My laptop is a 13v2.
I’ve chosen the defaults during the script traversal.
I’m building from KDE neon (ubuntu xenial), which has:
git version 2.7.4
git describe gives:
4.7-15-gbdaef1d
The hash value I (repeatedly) get, is:
5b4d2bb6e60d0c9831ca8554d7b2f6b59eca9de9e282c29b98bc0e78bffe75a0
Would you like access to the constructed coreboot-l13v2.rom?
If so, I could mail you a wetransfer link?
If you look at these posts here : Building coreboot from source (official script)
and Building coreboot from source (official script)
You’ll see that your git version is too old unfortunately. The build should be safe, but I say better be safe than sorry and just upgrade your git version to make sure the resulting hash matches.
I suggest adding
sudo apt-get update
before step 2 since otherwise the command of step 2 may not find all required installation packages…
Thanks.
Just confirming that it worked with the ‘latest’ version of Ubuntu bionic beaver; 2.15.1.
I’m having issues when running this script on my Librem 13 V2 with TPM.
Which coreboot image do you want to build:
1 - Librem 13 v1 (Version : 4.7-Purism-2)
2 - Librem 15 v2 (port not finished)
3 - Librem 13 v2 (Version : 4.7-Purism-3)
4 - Librem 15 v3 (Version : 4.7-Purism-3)Enter your choice (default: 1): 3
How do you want to extract binary blob files:
1 - Extract from the current machine (must be same as target machine and run coreboot)
2 - Extract from a pre-built coreboot image (filename must be coreboot-orig.rom)
3 - Files are copied manually (copy to coreboot/3rdparty/blobs/mainboard/purism/librem_skl/)The following files are needed :
descriptor.bin - The Intel Descriptor - SHA256: d5110807c9d67cea6d546ac62125d87042a868177241be4ae17a2dbedef10017
me.bin - The Intel Management Engine image - SHA256: 3042150c7f655293a69bcf886836732fc451439ae551a2babf3173f4f0d9a8d3
vbt.bin - The Video BIOS Table - SHA256: 51fa214ca44a61b171662d4c2ca6adc1aa3dc6c3d7a24bf9ae5f249f012d61c0
fspm.bin - The Intel Firmware Support Package - SHA256: 7a1acc72073969e6753bbfe145f06c3f4d35e2516cb241641eae968705e2cc46
fsps.bin - The Intel Firmware Support Package - SHA256: 0dac94d249473e9d366597fd1f96a0232fb7bf045a3d08f16784961273351822
vgabios.bin - The VGA BIOS - SHA256: 18d861485b86f93dad2b294cebd40b99eb03493d32b514e731ddb8dcf3a1ce83
cpu_microcode_blob.bin - The CPU Microcode Update - SHA256: 9c84936df700d74612a99e6ab581640ecf423d25a0b74a1ea23a6d9872349213The vbt.bin, fspm.bin and fsps.bin can automatically be downloaded, the me.bin can also be
downloaded, configured and patched so it will match the expected SHA256.
Enter your choice (default: 1): 2
Already up to date.
Using ‘sudo dmidecode’ to grab the local machine’s serial number
Could not open file: No such file or directory
Which is odd as sudo dmidecode --version shows it is installed and working. Any ideas?
$ sudo dmidecode --version
3.1
$ uname -a
Linux librem 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux
The error “Could not open file: No such file or directory” is from a section of the script that is run after getting the machine’s serial number. See the snippet below:
./util/ifdtool/ifdtool -x …/coreboot-orig.rom
If dmiedcode was not installed, the error would be like so:
sudo: dmidecode: command not found
It looks like you chose 2 for this prompt:
How do you want to extract binary blob files:
1 - Extract from the current machine (must be same as target machine and run coreboot)
2 - Extract from a pre-built coreboot image (filename must be coreboot-orig.rom)
3 - Files are copied manually (copy to coreboot/3rdparty/blobs/mainboard/purism/librem_skl/)
[…]
Enter your choice (default: 1): 2
Instead since you do not have coreboot-orig.rom, you should choose 1, assuming your Librem 13v2 does run coreboot.
My laptop came with SeaBIOS installed so option 2 is correct.
No, option 2 is not. Coreboot is essentially a framework for the BIOS and needs a payload, which in this case is SeaBIOS. If you have SeaBIOS, you have Coreboot. Option one is correct.
1 Like
Checking back in to see if there is a solution to the power off overheating issue yet. Again today, I had 3 power offs, on battery, turbo disabled, simply streaming amazon video while typing a document.
I’m getting concerned about file corruption with how many hard power offs I keep having. The not on boot says CPU package temperature has exceeded limits.
If it is not fixable, how can I go back to before this coreboot update? I didnt have any problems and only upgraded it to unlock my TPM and since Purism recommended it on their webpage.
Just update it again, the fix was released 2 weeks ago : Building coreboot from source (official script)
EDIT: and while I’m here, here’s an update: still working on figuring out the temperature increase issue, some progress made, but no definite solution yet.
I updated the version that came out 2 weeks ago, 4.7-Purism-3. Is there another update from that as that is the version that I keep having the power / temp problems with. Thank you.
EDIT: I may have wrote that confusingly. What I meant to say was that two weeks ago, when that update was released, I performed the update to 4.7-Purism-3. I have had over a dozen heat related shutdowns since then with and without turbo enabled.
I’m surprised! Did you check with ‘dmidecode’ and made sure you are indeed on 4.7-Purism-3 ? Maybe it only built it but didn’t actually flash it and you thought it did ? I’m surprised to see that you have this issue still, considering you’re the only one with the problem (as far as I know). Can you ssh into your machine from somewhere else and have “watch -n 1 sensors” running (apt-get install lm-sensors) to see the temperatures it reached when the shutdown happens ?
My only guess right now is that you don’t have the fixed version.
I did confirm with dmidecode 4.7-Purisim-3.
I dont currently have any other systems to work with as I’m on the road for work for the next couple months.
I reran the build this morning, did seem to take much longer than I remember last time.
I’m running watch -n 1 sensors | tee temps.log for now. That should capture the last temp on shutdown unless I’m missing something right?
weird then! But if you managed to build it on the machine without having it shutdown, that’s already pretty good…
Yeah, it should save the last temps to file but that’s assuming the ‘tee’ will write/flush to disc and that the write to disc doesn’t corrupt the file if it happens during the shutdown. I’d personally avoid writing to disc if you know the machine is about to shutdown.
I don’t have any hard data for you, but anecdotally even with 4.7-Purism-3 my 15v3 battery doesn’t last as long, I have to be careful about random power-offs, and I can’t rely on it to sleep for very long without depleting the battery.
If there are particular logs that’d be helpful lmk, will try to provide.
Thanks for all the hard work, this is a great project to be a part of!
@daehawc is not the only one with this problem. I mentioned this earlier in the thread but perhaps did not make it clear that I am also running 4.7-Purisim-3, confirmed with dmidecode, and have experienced several hard shutdowns since the update, usually when on battery.
1 Like
@hazybluedot: Your only other comment in this thread was from before the Purism-3 update was released.
Ok, so that’s problematic, do you have any way to reproduce this crash? I’ve been testing with the command ‘stress -c 4’ so far, but is there something in particular that could increase the temperature higher than what the stress test would do ? Could it be related to when the CPU and the GPU are stressed together ?
Woops, looks like I was thinking of a different thread. The crash has not be 100% reproducible but I also haven’t spent a ton of time looking into it. I do not think it is limited to times both the CPU and GPU are stressed together though because it has happened when I’m doing non-GPU intensive tasks, for example running two instances of a deduplication backup utility at the same time while doing some analysis in Rstudio (though it is possible R is offloading computation to the GPU?). It also seems to only occur when running on battery power with Intel turbo boost enabled though I have not done a systematic turbo boost on/off comparison yet.