Skip to content
This repository has been archived by the owner. It is now read-only.

Problems running rkt fly on CoreOS #2160

Closed
tomdee opened this issue Feb 9, 2016 · 3 comments
Closed

Problems running rkt fly on CoreOS #2160

tomdee opened this issue Feb 9, 2016 · 3 comments

Comments

@tomdee
Copy link
Contributor

@tomdee tomdee commented Feb 9, 2016

Using the latest CoreOS from today (949 that includes rkt 1.0), I thought I'd give rkt fly a tryout.

1st issue - it seems rkt and CoreOS have different ideas about where stage-1 images should live.

/usr/bin/rkt run --stage1-from-dir=stage1-fly.aci --insecure-options=image --volume=
image: using image from file /usr/lib64/rkt/stage1-images/stage1-fly.aci
run: open /usr/lib64/rkt/stage1-images/stage1-fly.aci: no such file or directory

On CoreOS the file is actually here /usr/share/rkt/stage1-fly.aci

I tried --stage1-name but that didn't work (since the stage1 isn't preloaded into the store). The docs hinted that I might be able to do --stage1-name=coreos.com/rkt/stage1-fly, but it can't

image: searching for app image coreos.com/rkt/stage1-fly
run: no endpoints discovered
@krnowak
Copy link
Collaborator

@krnowak krnowak commented Feb 9, 2016

As a workaround you could use --stage1-path=/usr/share/rkt/stage1-fly.aci on the first run, so it gets fetched to the store (or just rkt --insecure-options=image fetch /usr/share/rkt/stage1-fly.aci) and then --stage1-name=coreos.com/rkt/stage1-fly.

@marineam, @steveeJ: Not sure who is doing rkt packaging for CoreOS, but if you are installing stage1 images to /usr/share/rkt/, then you need to tell rkt about it by either passing --with-stage1-default-images-directory=/usr/share/rkt or by dropping a vendor config in /usr/lib/rkt/paths.d with contents like:

{
    "rktKind": "paths",
    "rktVersion": "v1",
    "stage1-images": "/usr/share/rkt"
}

Please see https://github.com/coreos/rkt/blob/master/Documentation/configuration.md#rktkind-paths for details.

@marineam
Copy link
Contributor

@marineam marineam commented Feb 9, 2016

@krnowak ok, I suspect this came about simply because the ebuild larely dates to when there was only one stage1 image and the change to shipping multiple stage1s didn't really catch anyones attention :(

We'll get it fixed this week

@marineam
Copy link
Contributor

@marineam marineam commented Feb 11, 2016

This fix will be rolling out in alpha 955.0.0

@marineam marineam closed this Feb 11, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.