Looks ok, but seems it does not fix the issue, right?

@krnowak It worked for me on Debian (tested in Vagrant). And make clean also worked for me. But it was not working for @onlyjob (see #1809 (comment)). And it breaks something on Arch, @iaguis is looking at this.

It works for both @alban and me now. LGTM.

Updated to ec44009 with fixes for Arch.

• works for me in Debian (tested in Vagrant with systemd-228).
• works for Iago in Arch

@onlyjob: how did you test the patch? Do you cherry pick the commits on top of the 0.12.0 release, or do you take the branch as is? In the first case, you might need to delete the old stage1 with rkt image rm sha512-xxxxxx. I just filed #1813 for that.

I applied patch on top of 0.12.0 and indeed the problem was due to already imported stage1 image that rkt did not update automatically. As advised in #1813 I've built with

--with-stage1-default-flavor=host
--with-stage1-default-name=host
--with-stage1-default-version=$(VER)

which fixed the problem. Thank you.

@onlyjob: And that worked? That should not be possible. --with-stage1-default-flavor is conflicting with --with-stage1-default-name and --with-stage1-default-version, so the configure should bail out in this case.

Yes, as far as I can tell it did work. Why would flavour (i.e. type of image) conflict with its name?

@onlyjob: --with-stage1-default-flavor=host is basically a convenience shorthand of --with-stage1-default-name=coreos.com/rkt/stage1-host --with-stage1-default-version=<version from AC_INIT>. And these flags only tell rkt to search for this name and version of the stage1 image in the store. They do not affect how/which stage1 is actually built.

I see... Thanks.