Reframing the problem :-)

[pgeorgi]

The coreboot-sdk docker image is something we use for the qa.coreboot.org builders but it's not the canonical way of building coreboot.

coreboot strives for reproducible builds as soon as you have a certain coreboot commit checked out and the coreboot-sdk as of this commit available. Everything else, incl. the host compiler, operating system, CPU architecture shouldn't matter: If the build succeeds, the result should be a bit identical coreboot.rom. If that doesn't work out, that's a bug!

In today's coreboot leadership meeting (notes) we discussed that (quickly), and one remaining concern was that this means that for every build, the toolchain needs to be rebuilt as well (there are ways to optimize that a bit).

I outlined a few ideas in the agenda for the next meeting (June 30, open for all) and I hope we can make the toolchain less of a problem, and through that, provide a simple while comprehensive reproducibility story.

With all that said, you're not the only one seeing this kind of issue, so we might have a communication problem regarding the build environment.

[Thrilleratplay]

@pgeorgi The described issue is an over simplification of the initial goal of a extendable and reproducible build environment for coreboot and related forks. Relating to the coreboot-sdk image seemed to provide the most tangle way to quickly explain the project to anyone who is linked to it or stumbles upon it. The original request came from Heads ROM to be able to control the build environment for fully reproducible complete ROMs. 3mdeb also has had issues consistently compiling coreboot.

My take on this is: whenever I see someone new trying coreboot, after they understand what is supported and the potential need for an external flashrom compatible programmer, the almost always have issues compiling coreboot. They do not know what apps/libraries are needed, versions needed or what they would be called under their particular OS. A short cut usually is to suggest docker with the coreboot-sdk, which I used in Thrilleratplay/coreboot-builder-scripts, but this is not a perfect solution. I recently found out it is missing sharutils, parted and unzip which are dependencies of /util/chromeos, a command needed if following the instructions on extracting mrc.bin. Additionally, recreating the environment at anytime in the future will produce different images because apt-get update is run initially. This requires the user to trust the generated image and ensure there is nothing funny going on with it (think Volkswagon Disel emission test inspired continuous integration systems). Paranoid people are going to be paranoid, so I would want them to go down the rabbit hole as far as they want.

While this may not actually replace coreboot-sdk for the image used in reproducable builds, I hope it will compliment it to allow anyone to quickly and easily have a ready made build environment that can be trusted and extended to fit everyone's needs without many of the headaches of setting one up.

SIDENOTE: To keep from needing to build the toolchain each time, move the building of the toolchain to its own versioned image coreboot-toolchain and start coreboot-sdk with FROM coreboot-toolchain:x.y.z then add additional packages/updates that do not require changes to the precompiled toolchain.