Signature check failed for latest build

[johnptoohey]

Just downloaded the latest build. When the VM starts I get the following,

booting rktmachine (1/1)
---> downloading and verifying stable/1800.7.0
[ERROR] Signature check for DIGESTS failed.

[daithiocrualaoich]

Thanks for the report, John. We appreciate you helping us out.

The problem is similar to #43. CoreOS regenerate their signing keys annually and we’re still on the old key. (https://groups.google.com/d/msg/coreos-user/4rjt4ElkJS0/hCyL2DCRAwAJ)

The corresponding upstream commit in corectl we want is TheNewNormal/corectl#126. And we also have to get moby/hyperkit#200 to handle some new compiler warnings.

I’ll put out a 1.0.3 release to include this. Delete ~/.coreos and ~/.rktmachine if you still have problems with the new version.

Thanks again.

[daithiocrualaoich]

https://github.com/woofwoofinc/rktmachine/releases/tag/1.0.3 is uploaded now.

[johnptoohey]

Thank you. I'm past the issues now, but the coreos image that runs when I start rktmachine 1.3 does not have buildah installed rather acbuild.This is the build info;
core@rktmachine ~ $ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1465.6.0
VERSION_ID=1465.6.0
BUILD_ID=2017-08-16-0012
PRETTY_NAME="Container Linux by CoreOS 1465.6.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

[daithiocrualaoich]

Hi John. The CoreOS 1456.6.0 build number makes me think you had the RktMachine 1.0.1 release at some point. This was a temporary release created the last time we had this key roll problem and it pinned the CoreOS version to exactly 1456.6.0 since that was the last CoreOS release signed with the key.

RktMachine 1.0.2 resolved the key problem and the CoreOS version was allowed to float latest again.

The acbuild tool was removed in the 1.0.2 release and replaced with buildah so I think you have a disk image from RktMachine 1.0.1 also.

The reason you might have these older images even when using RktMachine 1.0.3 is that CoreOS images are cached in ~/.coreos on your Mac and not checked for version freshness. Similarly, the RktMachine disk image is stored in ~/.rktmachine and may not have been reset either.

Try deleting these two directories and starting RktMachine 1.0.3 again. The console startup should then show it downloading the latest CoreOS stable version 1800.7.0.

After SSHing to this VM, I get a buildah with the following version numbers.

Hope this helps. Let us know if it is still being trouble after this.

[johnptoohey]

Thanks, this fixed these issues. Working through the tutorial, the section where you fetch the ubuntu base image refers to a build that is no longer available. Its asks for version 17.10. I just changed to the latest 18.x build and is worked fine.

Do you know when rkt will support the OCI format for containers, so we can bypass the docker2aci steps?

[daithiocrualaoich]

I don’t follow rkt development closely. Last I heard was that the Red Hat acquisition of CoreOS would mean rkt becoming an independent community open source project, i.e. not supported directly by Red Hat. On the face of it, this would not seem promising for rkt development but tbh I really don’t know. I do not expect native OCI support in rkt any time soon. (Sorry if this is completely wrong, I am not an expert.)

https://www.zdnet.com/article/heres-what-happens-to-coreos-now-that-red-hat-owns-it/

Thanks for the note about the Ubuntu versions. I’ve updated the docs now.