It might be something that lxc-start needs to check based upon some
config parameter. I dont know if there is a way of getting info from the
ABI or if its just a matter of checking the kernel version and/or
/proc/cmdline.
Such a config parameter could then be placed in the centos6 template
Hey,
On Tue, Dec 06, 2016 at 05:46:58PM +1100, Dean Hamstead wrote:
> Yes, Solution was to use "vsyscall=emulate" on the host kernel command line
> (ie on my laptop).
>
> Exactly the same issue as:
> https://github.com/CentOS/sig-cloud-instance-images/issues/62
>
> So I am guessing the issue
Yes, Solution was to use "vsyscall=emulate" on the host kernel command
line (ie on my laptop).
Exactly the same issue as:
https://github.com/CentOS/sig-cloud-instance-images/issues/62
So I am guessing the issue was actually the kernel upgrading.
See also:
Seems to be the same issue:
https://github.com/CentOS/sig-cloud-instance-images/issues/62
On 05/12/16 21:42, Evgeni Golov wrote:
On Mon, Dec 05, 2016 at 08:59:07PM +1100, Dean Hamstead wrote:
it seems if i drop back to 2.0.5 the problem still occurs. so i am guessing
some other thing
This seems relevant from syslog:
Dec 6 16:36:43 cliffjumper kernel: [22402.625004] lxcbr0: port
1(veth4KDYR9) entered blocking state
Dec 6 16:36:43 cliffjumper kernel: [22402.625005] lxcbr0: port
1(veth4KDYR9) entered disabled state
Dec 6 16:36:43 cliffjumper kernel: [22402.625103] device
it seems if i drop back to 2.0.5 the problem still occurs. so i am
guessing some other thing upgraded and its not lxc-start's fault
On 05/12/16 19:25, Evgeni Golov wrote:
Hi Dean,
thanks for the report,
On Mon, Dec 05, 2016 at 05:58:40PM +1100, Dean Hamstead wrote:
Since upgrading, centos6
Hi Dean,
thanks for the report,
On Mon, Dec 05, 2016 at 05:58:40PM +1100, Dean Hamstead wrote:
> Since upgrading, centos6 containers fail to start.
Is that a regression from 2.0.5? Or anything older?
> I am guessing that upstart is doing something crappy and lxc is now carefull
> enough to
On Mon, Dec 05, 2016 at 08:59:07PM +1100, Dean Hamstead wrote:
> it seems if i drop back to 2.0.5 the problem still occurs. so i am guessing
> some other thing upgraded and its not lxc-start's fault
can you try an older lxcfs, it was updated at (almost) the same time.
mind you, just downgrading
FYI i do not have lxcfs installed
after down'ng to 2.0.5 and restarting lxc, still the same issue.
Dean
On 05/12/16 21:42, Evgeni Golov wrote:
On Mon, Dec 05, 2016 at 08:59:07PM +1100, Dean Hamstead wrote:
it seems if i drop back to 2.0.5 the problem still occurs. so i am guessing
some
This seems to be the same issue: https://github.com/lxc/lxc/issues/602
Sadly, there isnt any meaningful conclusion.
On 05/12/16 21:42, Evgeni Golov wrote:
On Mon, Dec 05, 2016 at 08:59:07PM +1100, Dean Hamstead wrote:
it seems if i drop back to 2.0.5 the problem still occurs. so i am
yes, I was previously running 2.0.5
fwiw im using this with vagrant-lxc, although as i begun having problems
i peeled a layer back and used the lxc tools directly.
lxc containers of centos6 created via lxc-create also have the exact
same problem. whilst debian containers are fine.
On
Package: lxc
Version: 1:2.0.6-1
Severity: normal
Dear Maintainer,
Since upgrading, centos6 containers fail to start.
They dont even get far enough along to get a console.
I run them with the following:
lxc-start -l DEBUG -F -n blah -o /tmp/lxc.log
lxc-start 20161205015048.219 NOTICE
12 matches
Mail list logo
