Problem seems to be related to older systemd version. Fixed with beta
channel release of coreos.
Am Dienstag, 16. August 2016 15:43:13 UTC+2 schrieb Stefan Vetter:
>
> Hi all,
>
> I have problems getting a pod manifest started while everything seems to
> work otherwise.
>
>
Hi all,
using rkt v1.12.0 I am experiencing the problem that rkt fetch can download
all layers, but doesn't do anything afterwards (image is not in image list
at this state).
Any idea what might be the problem and how this can be fixed?
Thanks
Hi all,
the error I am getting is:
/var/lib/rkt/rkt prepare --pod-manifest /tmp/manifest.bak
image: using image from file /usr/lib/rkt/stage1-images/stage1-coreos.aci
prepare: error setting up stage0: missing os label in the image manifest
Manifest can be found here: http://pastebin.com/ZELBgB
Just to link old probably relevant github issues/pulls:
https://github.com/appc/docker2aci/pull/188
https://github.com/appc/docker2aci/issues/189
https://github.com/appc/docker2aci/pull/190
https://github.com/appc/docker2aci/issues/192
Am Dienstag, 16. August 2016 21:49:34 UTC+2 schrieb Stefan
Hi all,
As talking about monitoring, we are using CoScale which integrates pretty
out of the box, is running in a container itself and is also monitoring
Kubernetes and in addition can monitor the full stack (from browser (user)
down to the hardware.
It's available as cloud and on premise solution
Hi all,
I have a problem now after booting coreos with pxe into ram.
I wanted to mount local storage to /var/lib/rkt to download,run and store
images on local storage instead onto ram.
After doing that I now receive those errors:
image: using image from local store for image name
coreos.com/rk
Great, that's the reason. xfs seams not to be supported and raising the
d_type not supported message.
Thanks a lot for your help!
2016-08-08 21:43 GMT+02:00 Florian Koch :
> Hi,
>
> So You trief ext4 instead xfs?
>
> Von meinem iPhone gesendet
>
> > Am 08.08.2016 u
Hi all,
first of all, I still have error messages when using a downloaded kubelet,
but pods get deployed.
Using kubernetes 1.3.2 and rkt 1.10.1, coreos 1068.8.0
Here are my findings (kubelet-wrapper):
Aug 09 14:35:09 node3.cluster1.kubernetes.cluster.int sudo[4487]: E0809
14:35:09.942522
> On 08/08/2016 02:34 PM, Stefan Vetter wrote:
> > Great, that's the reason. xfs seams not to be supported and raising the
> > d_type not supported message.
> >
> >
> > Thanks a lot for your help!
> >
> > 2016-08-08 21:43 GMT+02:00
To add this:
Also with kubernetes (hyperkube) 1.3.4 and rkt 1.9.1 I am experiencing this
issue...
Am Dienstag, 9. August 2016 18:09:00 UTC+2 schrieb Stefan Vetter:
>
> Hi all,
>
> first of all, I still have error messages when using a downloaded kubelet,
> but pods get deploy
Maybe I should just switch back to docker as it seams rkt does not work
with kubelet properly... :-(
Am Dienstag, 9. August 2016 18:09:00 UTC+2 schrieb Stefan Vetter:
>
> Hi all,
>
> first of all, I still have error messages when using a downloaded kubelet,
> but pods get deploy
call getting a similar error with older versions of rkt due to a bug
> in the api-service leading to a panic. Updating to a newer rkt version
> (which can be done by updating to a newer CoreOS release) might help, but
> if not the api-service logs would help us figure out what's goin
stration failed
Aug 11 20:27:09 node3.cluster1.kubernetes.cluster.int sudo[32844]:
└─pod not found
Am Donnerstag, 11. August 2016 22:14:09 UTC+2 schrieb Stefan Vetter:
>
> Current status:
>
> Problems still existing:
> 1. Time until a container is created is very long (at
Hi all,
I have problems getting a pod manifest started while everything seems to
work otherwise.
Attached you can see some log extracts. Please help me here asap as I lost
my apiserver due to this... Sorry to bother you :-(
sudo /var/lib/rkt/rkt image list
ID NAME SIZE IMPORT TIME LAST USED
sh
14 matches
Mail list logo
