It should be “cbmem” not “./cbmem”, and if you’re on PureOS, make sure you first apt-get install coreboot-utils. Otherwise, you need to grab cbmem from the coreboot/utils/cbmem source directory and compile it.
I have no idea what you mean about BusyBox…
That just worked perfectly. Kudos for good work.
Now waiting for enabled IOMMU.
I am talking about this :
sorry I dont know the proper terminology
Is this has anything to do with coreboot?
Nope, I don’t think it has anything to do with coreboot. I think your OS is not installed properly.
I did a quick review and you don’t do any error handling and your interpreter is wrong. It should be /usr/bin/env bash as /bin/bash is not guaranteed to exist.
Many of the variable references are not double quoted when they should be.
Don’t feel discouraged, however. Apparently people are happy with it, so doing something is better than doing nothing. It’s just that it could be written in a more portable way.
1 Like
You could just check for the dependencies before the script runs and output appropriate error messages. That way you won’t have users complaining to you about your script not working.
Writing the error checking code is just as much work as writing the comments.
1 Like
Would I be able to build this with a different payload?
Say for example I wanted the GRUB2 payload, so I went into config.librem15v3 and set “CONFIG_PAYLOAD_GRUB2=y”, then commented out anything relating to SeaBIOS. Would it build?
I don’t yet have the Librem 15 to test it out. Being able to get Coreboot with a disabled Intel ME and GRUB at the BIOS level, allowing for full-disk encryption including the /boot partition (like this), is a big factor in my decision to buy it in the next week or so.
I’m not a bash developer, but I ran it through shellcheck.net and fixed all the warnings, errors and suggestions it gave me. If you have other suggestions to give, then feel free to send a pull request.
No, the variable references are double quoted wherever they should be, shellcheck makes sure of that.
I’m not discouraged, why would I be ?
I haven’t really seen people complaining about the script not working. I could check for the dependencies but I didn’t because the script was meant to be released as a .deb. The comment was meant for the deb developer who is going to build the package with the script.
Since you’re the only one that seems to be bothered by it, I’ll repeat my advice from above, feel free to send a pull request with your fixes.
3 Likes
Yes, you could, but it’s not as simple as modifying the config.librem15v3 because of the following reasons :
- The script would checkout a clean clone of that git repo and copy the config file from there, so your changes would be ignored anyway
- Modifying the config file manually is not supported by coreboot, when you type ‘make’, it will regenerate the config file somehow, and may or may not override your settings
- Enabling one option could create new config options that need to be set which aren’t even listed in the config file
- The script verifies that the build has the expected hash, if you change a single thing in the config, the hash won’t match and the script will think that some error happened which caused a corrupted build and it won’t ask you to flash it and will show you an error.
What you could do however is that you would first build it normally, then after it’s done, go into the coreboot directory and do ‘make menuconfig’. In the menu, go to payload and change the payload, then save config and exit the menuconfig. Then when you do ‘make’, it will compile coreboot with your new options (grub). After that, you need to create a serial_number.txt file and put your machine’s serial number in it and use cbfstool to insert the serial_number.txt file into the resulting coreboot.rom image (otherwise, when you boot, dmidecode will report ‘unknown serial number’)… the method and arguments to do that are in the script file, then you’d need to run the me_cleaner script on the resulting build/coreboot.rom file (required arguments are in the build script). then you need to flash it manually (arguments to flashrom are in the build script). Once it’s flashed, and that’s the big issue, you would need to cross your fingers, reboot and HOPE that it will boot into your machine. Because if the grub config file (which also needs to be provided and embeded in the coreboot.rom file) is somehow wrong and grub doesn’t detect your drive (because you made a typo in the partition name, or something… anything…), then you can’t boot your machine. If you can’t boot your machine, you won’t be able to fix the grub config file and re-flash it. so you would need to buy a hardware flasher, open the laptop and flash a known-working coreboot image back into your flash so you could boot it again.
so in short, yes, you can do it, but it’s not as simple as changing the config file. I don’t even know if you could have grub boot from your usb, or maybe you can enter a ‘grub shell’ and manually type the commands to make it boot from a usb stick so you could boot into a live USB and restore your system… but that also assumes that the graphics are initialized, which is something that SeaBIOS does, and I don’t think that grub does that, so you might also need to edit the coreboot configuration to tell it to run the VGA Option ROM and to initialize the GPU, otherwise grub might appear but the screen is off and you can’t see anything…
All these complications are why the script checks the hash and makes sure the image it builds and flashes is a known working image. If you have, or are willing to buy an external flasher and play with it until it works for you, then feel free to do so. I am however too busy with other tasks to try and test/confirm that every payload would work (I know that MrChromeBox has unofficial builds that use TianoCore as the payload, I’m not sure if he released those anywhere though).
1 Like
To quote Lloyd Christmas, “So you’re telling me there’s a chance.”
Really though, I’ll probably give it a shot. The alternative if I wanted this setup is to either buy a Librebooted decade-old ThinkPad or buy similarly spec’d hardware to the Librem and definitely need a Rasperry Pi and a Pomona clip. At least this way there’s a CHANCE I won’t need to do any hardware flashing, provided I don’t screw anything up.
3 Likes
Go man go! Let us know if u brick or win
2 Likes
Two questions about coreboot, Intel ME disablement and the Librem 15v2.
- I recall having the impression that coreboot was not going to work but the Intel ME could possibly be disabled in the 15v2. If this is correct, can you point me towards info that would let me start learning how to do this?
- I keep wondering when the coreboot development for 15v2 will begin. It’s felt like it might be just around the corner for some months now, which tells me I had the wrong expectations. Is there much more to go before that can usefully start? Or is there a particular milestone in porting coreboot to the other systems I should look for to know user testing on the 15v2 can usefully start?
Sorry about the 2nd question, just feeling a bit lost on where we’re at with it and that doesn’t pair well with having a lot of interest in the end goal.
Thanks for the script.
Could you please provide some way of checking the authenticity of it (I know I could read it to see whether it is malicious, but then I still need to trust the hashes contained in it).
I would like to upgrade coreboot to get the disabled ME, but I am reluctant to run an untrusted script downloaded from the internet with root privileges.
yeah, there is a chance. I’d suggest you read carefully all of my previous technical blog post on coreboot just to get familiar with the whole thing. You can find my posts on the right sidebar here : https://puri.sm/coreboot/timeline/
Well, both coreboot and ME disablement would work on the l15v2, but the ME disablement would be much easier to achieve than the coreboot port, since all you’d need to do is run me_cleaner on it. So ‘steps’ would be : flashrom to dump your ME, run me_cleaner on the rom (use -s to tell it to set the disable bit), then flashrom to flash it back. Then reboot and cross your fingers and start praying that it doesn’t brick it.
Yeah, I don’t know ‘when’. And no, you didn’t have the wrong expectations, because yes, it also felt like it’s right around the corner for me too. I did do one attempt at it. Did the port, thought it would work, flashed it, it bricked the l15v2 that I had. I restored it with the hardware flasher, and was trying to understand why it failed to boot from the log files I had, but didn’t finish that and got sidetracked by something else. For now, I think that the priority is on other tasks and I haven’t had time to go back to that work. It’s really all about man power and how much stuff I can achieve every week. So… “when” will it start… I have no idea, for now my priority is on the FSP reverse engineering, so maybe if enough l15v2 users start bugging us about the coreboot port, the priorities will change.
It’s not that we don’t want to do it, it’s still planned, but since l15v2 isn’t being sold anymore, I think the priority will most often go to the current products in favor of retrofitting older products.
The script builds coreboot from source. You can either trust the script and trust the coreboot source code, or you can read the source to know what it does. The hashes contained in it are just the hashes for the binary blobs themselves, there is nothing that can be checked on those (we don’t know if they are malicious or not) and those files are taken directly from your own machine. The only other hash is the resulting binary of the coreboot rom file after it gets built from source. You don’t need to trust that hash, you only need to trust the source code of coreboot, since the hash verifies the result of the compilation from source.
As for the root privileges, you don’t need to run it as root, but it will call ‘sudo’ for a few commands. You can look up ‘sudo’ in the script, there are 3 instances of it, first is the call to ‘flashrom’ to dump the rom (to extract the binary blobs from it), then a call to ‘sudo dmidecode’ which is used to get the serial number from your current machine, then a final call to ‘flashrom’ to write the built coreboot rom into the flash. The rest is executed without root priviledges, and I usually run it as a normal user.
1 Like
Could you incorporate more recent updates from https://review.coreboot.org/#/q/purism ?
I fear bricking the device when compiling from mainline but need the librem13v2 fixes.
2 Likes
I was waiting for the coreboot 4.7 release (which was supposed to be last month but got delayed due to lack of time) before I update the script/build and make a new release of coreboot for the librems. I don’t want to make an update to a ‘random’ commit from git then another one a few days/weeks later when coreboot 4.7 is released.
1 Like
Release early, release often 
Is it possible to flash with external programming device (such as beaglebone black as documented in other coreboot support pages.) Programming this way can set write protection and prevent certain maleware from overwriting bootloader.
An example using external programmer:
https://www.coreboot.org/Board:lenovo/x200
Is it possible to do this in Windows 10? My coreboot is corrupted and I can’t install or boot into linux it just hangs. I was only able to install and boot into Windows 10 I’m using a Librem 15 v3.
Hi @kakaroto! Now that coreboot 4.7 is out, can we possibly get a build for Librem 13v2 that includes IOMMU/VT-d support?
It would be great if my brand new librem+qubes laptop could actually… be a laptop: on v3.2 it won’t resume from suspend, and on v4 it resumes, but no VMs work without IOMMU/VT-d support. (So I’m stuck on 3.2 at the moment, fully shutting down and starting up the system any time I go anywhere.)
Thanks!
2 Likes
Hi @quban. We are definitely aware of the IOMMU issue (as a Qubes user myself I feel your pain) and it’s a super high priority for us to add it to the Purism coreboot image. We are actively working on it and hope to have an update soon.
3 Likes