@kakaroto it’s entirely possible it’s something else, but based on my priors here I’m leaning toward it being 4.7-Purism-4. In the interim I’ve noticed I wake up and the machine has powered off and the battery is dead (presumably either not sleeping properly or using too much power in sleep)
Are there particular logs I can capture that would help you?
Hey! I’ve got a few questions regarding the coreboot port:
Now my question is, how big is the security risk when I do this? And can I somehow generate a ‘correct’ checksum for my version, that compensates for the different bootsplash picture?
Also since the newest version of your script I am not able to flash my bootsplash anymore, the image flashes correctly, but on bootup I just get a “text version” of a bootsplash and no actual bootsplash. Any guesses on why it doesn’t work on the new version? I’d be happy to have my bootsplash back xD
Is there a possibility to set a BIOS password for coreboot? And how would I do it?
Are there any settings I can change in coreboot or is all fixed? Haven’t seen any settings yet``
But anyways, you are doing great work @kakaroto!!
You ahave effectively turned off any image verification. The script can’t differentiate wheather the checksums differ due to replaced bootsplash or corrupted some other part. It happily will flash whatever you feed it, be it working image with diffrenet bootsplash or some broken build. You might brick your laptop and it would come without any warning.
There, first symptom of imminent bricking. Damaged image - since bootsplash does not work - but flashed without any warning. You will also get no warning if the part that does the boot gets damaged.
That’s the way to go, but details are beyond me. Untill you figure this out, I’d recommend to live with the standard bootsplash.
Another unscheduled power off. Some data:
–When I restarted, battery was showing 59%. Last time this happened it was showing 58%. I think coincidence.
–I was a few minutes into playing a video file (computationally demanding, sort-of?). Last time this happened I was also playing a video file.
–The computer did not feel particularly warm immediately after the random power off
–dmesg did not show anything I thought noteworthy, but I’m not an expert. Happy to set up whatever logging might be helpful
I didn’t experience this with older versions of coreboot, and I don’t think I’ve made any significant changes, so I’m inclined to think it’s something with chip power management.
I’ve recognized that there are issues with Qubes RC5 and Evo 960. Firmware Version 3 was kind of awful. Version 4 has reduced the whining noise, but I am unsure about the performance. The main problem is the fan noise. It’s horrible between 80 or 90°C. There is a (beep-beep-like chirp) noise, when booting, but not when charging. If I set CPU governors to powersave the noise will be reduced, but also the performance.
With Qubes 4 my OS keep freezing as soon I do to much. Can this be the result of the coreboot firmware?
Are you talking about latest coreboot?
In my post above I described how yum install curl in a qube reproducibly caused overheat in some previous (factory) coreboot version:
All is working fine for me after updating coreboot using the script provided in this forum.
Yes sorry, I’m talking about the latest coreboot version 4.7-Purism-4. Running on a Librem 13v3
freezing or shutting down? If it’s freezing then expect it’s more likely to be an OS issue than a coreboot issue.
Freezing I can’t do anything and after a while the screen just goes to black. Then I’ve to do a hard reboot.
Then it’s probably an OS issue and I suggest you look for Qubes support instead.
For the record, the package names on Fedora appear to be:
dnf install git m4 dmidecode bison flex bsdiff libusb-devel pciutils-devel unrar gcc-c++ gcc-gnat libgnat-devel
For unrar, you’ll need to have rpmfusion set up already.
There are still issues with the fan and battery drain. If you are using some different kernel options for the i915 GPU firmware, the fan isn’t such noisy and you will get more performance at all.
Something like that could help:
i915.enable_rc6=1 i915.enable_fbc=1 drm.vblankoffdelay=1 i915.enable_guc_loading=1 i915.enable_guc_submission=1"
As describe here : https://wiki.archlinux.org/index.php/Intel_graphics
So, is there concensus that 4.7-Purism-4 works well? I’m on 4.6 still and would like to see if 4.7 improves Qubes issues any, but I’m not looking forward to power or restart problems…
I’m not sure if there is a concensus. But for me Version 4.7 with Qubes works nearly well. I suggest to try the actual version, you could switch back, if you have a backup of the coreboot rom. Normally the script does that for you. I guess it will reduce the issues. But yes, there are issues with Qubes. I’ ve never recognized any real power or restart problems.
The only thing I’ve seen, was that all the USB ports are still have power even if you switch off the system or cut the power supply. That’s a bit odd, especially if you have an USB SATA disk connected. It would make sense, if you use e.g. Wake-on-LAN.
Running 4.7 with Qubes on a Librem 13v2 and it works fairly well, though I must say that I haven’t been heavy on CPU/GPU so far. Also my USB ports are fully powered off when I have shut down my machine. I never use sleep mode so I can’t say anything about power drain there.
There is still a battery drain, if some of the VMs is under heavy load.
Maybe we should try this with Linux 4.16 in Dom0 again?
I need help, I need to update coreboot to get my NVMe working and I am a complete beginner with linux and I can’t get it to work.
I am following these steps:
Download the build script
mkdir building-coreboot && cd building-coreboot && wget https://code.puri.sm/kakaroto/coreboot-files/raw/master/build_coreboot.sh
Install the required dependencies:
sudo apt-get update
sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7
Run the script on your Librem machine:
chmod +x build_coreboot.sh && ./build_coreboot.sh
Follow the instructions on the screen, and BE SURE to select your
correct Librem laptop revision (Librem 13v2 or Librem 15v3, select Librem
13v2 if you have a Librem 13v3), and give it time to build the image.
Beyond selecting your specific laptop revision you can select the default
choices for the rest of the script.
I am up to step 2 and I get “tim is not in the sudoers file. This incident will be reported.” after I type in my password
Can anyone help?
EDIT: I found the SU command and used it and ran the dependencies but I am not sure if it worked correctly:
root@debian:/home/tim/building-coreboot/building-coreboot# sudo apt-get update
Ign:1 cdrom://[Debian GNU/Linux none Green - Official Snapshot amd64 LIVE/INSTALL Binary 20180120-02:05] green InRelease
Err:2 cdrom://[Debian GNU/Linux none Green - Official Snapshot amd64 LIVE/INSTALL Binary 20180120-02:05] green Release
Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs
Reading package lists… Done
E: The repository ‘cdrom://[Debian GNU/Linux none Green - Official Snapshot amd64 LIVE/INSTALL Binary 20180120-02:05] green Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@debian:/home/tim/building-coreboot/building-coreboot# sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package flex is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package bison is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package libusb-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
libusb-0.1-4
E: Unable to locate package git
E: Unable to locate package build-essential
E: Package ‘bison’ has no installation candidate
E: Package ‘flex’ has no installation candidate
E: Unable to locate package m4
E: Unable to locate package zlib1g-dev
E: Unable to locate package gnat
E: Unable to locate package libpci-dev
E: Package ‘libusb-dev’ has no installation candidate
E: Unable to locate package libusb-1.0-0-dev
E: Couldn’t find any package by glob ‘libusb-1.0-0-dev’
E: Couldn’t find any package by regex ‘libusb-1.0-0-dev’
E: Unable to locate package bsdiff
I then ran the script as mentioned in instruction number 3 and it says: line 325: git command not found.
I am completely lost and unsure if I am doing this correctly
Hi @pcguy,
Before running
sudo apt-get install git build-essential bison flex m4 zlib1g-dev gnat libpci-dev libusb-dev libusb-1.0-0-dev dmidecode bsdiff python2.7,
I would first run
sudo apt update && sudo apt upgrade && sudo apt dist-upgrade
This should update your repository information and will probably resolve the issue of not finding packages.