That command would have worked if you were on PureOS I assume, it probably didn’t because you’re not using PureOS and your distribution didn’t update the git version yet ?
Technically, you didn’t need to update to git version 2.16.1, the coreboot image that was built is still valid, the only problem is that you couldn’t be 100% sure that the image is safe (there is no reason for it not to be) and it would have shown as version “4.7.12-g83ed1b0” instead of “4.7.12-g83ed1b0f01” in the coreboot debug log, and you would have had to run the flashing command manually instead of the build script flashing it for you.
Updating git was better though because you can have a guarantee that the image has the same hash as everyone else’s and you can flash it safely.
@Freeforall @hazybluedot @mpc @darwin: This shutdown issue is indeed problematic, and I hadn’t experienced it before (I don’t compile or use much my librems other than for actual coreboot development/testing) but I left @Kyle_Rankin to look into it today and he says disabling Turbo Boost fixes the problem. The reason we enabled SpeedStep was because during IOMMU testing, the Qubes installer was complaining about “kernel modules not loading” and it was the xen-acpi-processor module that failed to load and after debugging it, I found that it was because it couldn’t find the P-state and C-state information in ACPI. The speed step option is what makes coreboot write that information in ACPI, however, there’s a possibility that the information coreboot writes in ACPI is not accurate or that the fact that it’s there (turboboost) is what’s causing this. we’re both (Kyle and I) looking into this so hopefully we’ll have a fix soon, for now, disable turboboost like Kyle suggested.
Thanks for reporting these issues!