Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Kublet-wrapper won't start after upgrade to 1353.2.0 with /var/logs already mounted #1892
Container Linux Version
A upgrade of kublet-wrapper shouldn't prevent it to start.
We use RKT_OPTIONS to mount
The latest kubelet-wrapper seems to have added the
changed the title from
Kublet-wrapper won't start after upgrade to 1353.2.0
Kublet-wrapper won't start after upgrade to 1353.2.0 with /var/logs already mounted
Mar 30, 2017
It turns out this is far more complicated than I initially thought. I shouldn't have put off looking into this for so long!
If two mounts have the same target, stage1-fly actually "dedupes" them.
Basically, the bug is:
$ sudo rkt run --stage1-name=coreos.com/rkt/stage1-fly --insecure-options=image,ondisk --volume=name1,kind=host,source=/tmp --mount volume=name1,target=/tmp --volume=name2,kind=host,source=/tmp --mount volume=name2,target=/tmp docker://busybox -- -c 'ls /tmp' run: can't evaluate mounts: missing mount for volume "name2"
However, if the target differs they don't get merged and things work, or if the names are identical then they merge identically and work.
It seems like the actual fix is going to be a patch to rkt fly to make it's mount logic closer to the other stage1's mount logic.
This was referenced
Apr 24, 2017
Ok, I just wanted to be sure that in my case upgrade will not break my kubernetes clusters. This is the value that I use for RKT_RUN_ARGS:
Of these, only /var/log seems to be duplicated. And since it has the same name as in here, this will not be a problem, right?