** Package changed: linux (Ubuntu) => lxd (Ubuntu)
** Changed in: lxd (Ubuntu)
Assignee: (unassigned) => Stéphane Graber (stgraber)
** Changed in: lxd (Ubuntu)
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages,
Ok, so investigation shows that:
- LXD bind-mounts all that stuff, it doesn't have a choice as it's not
privileged enough to mount things itself
- mountall fails to run if its "optional" filesystems fail to mount (because
that makes a lot of sense...)
- systemd sets up the host filesystems,
Haven't seen it in a few days. I'll reboot and see if I can reproduce
it. It usually happens after rebooting the host, when launching new
containers or existing ones would autostart.
Info you requested. I think the /usr/share/lxc/... might have been a red
herring. I'm exclusively using LXD on
Please can everyone affected by this issue post the output of: dpkg -l
lxc liblxc1 lxd lxd-client lxcfs
It's very difficult to figure out what's wrong when we don't even know
the version being used.
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug
Oh and "lxc info" too for good measure (just in case lxd wasn't
restarted post-upgrade).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on xenial
I'd like to note that LXD works differently from LXC here.
In LXC we mount debugfs through ubuntu.common.conf whereas with lxd, we
simply bind-mount /sys/kernel/debug from the host if it exists.
LXD doesn't use any of the /usr/share/lxc/* files. If it does on your
system, then you most
Casey: Any luck reproducing? I'd still like to see what 'mount | grep
debugfs' in the host shows when this is happening.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
On Fri, Mar 04, 2016 at 09:17:01PM -, Casey Marshall wrote:
> @stforshee I'll uncomment the debugfs mount in my
> /usr/share/lxc/config/ubuntu.common.conf (putting it back the way it
> was), reboot, and see if I can reproduce it again.
Oh there it is, I was grepping for debugfs and not debug,
@stforshee I'll uncomment the debugfs mount in my
/usr/share/lxc/config/ubuntu.common.conf (putting it back the way it
was), reboot, and see if I can reproduce it again.
My juju-lxd profile shows:
name: juju-lxd
config:
boot.autostart: "true"
security.nesting: "true"
description: ""
devices:
@Casey: I must have been typing my comment when you posted yours. So
you've answered one of my questions, but I have no idea what's leading
to the EACCES error. Can you provide the output of 'mount | grep
debugfs' in the host when you're seeing the failure?
--
You received this bug notification
I'm getting something kind of similar without juju. If I remount debugfs
ro in the host then start the container I get this in
/var/log/upstart/mountall.log:
mount: cannot remount block device debugfs read-write, is write-protected
mountall: mount /sys/kernel/debug [143] terminated with status 32
Interesting. I removed the /sys/kernel/debug mount and containers seem
to start up just fine:
c@mawhrin-skel:~$ grep kernel/debug /usr/share/lxc/config/ubuntu.common.conf
# lxc.mount.entry = /sys/kernel/debug sys/kernel/debug none bind,optional 0 0
c@mawhrin-skel:~$ lxc launch ubuntu-trusty t2
On Fri, Mar 04, 2016 at 05:36:28PM -, Serge Hallyn wrote:
> @sforshee - are you saying that removing the debugfs line from
> /usr/share/lxc/config/ubuntu-common.conf fixes this for you?
I haven't reproduced it. Just wondering as it should be impossible to
actually use debugfs from within the
Note - I am not actively looking at this bug as I've not managed to
reproduce it. Hopefully the kernel team has it under control, please
shout if I'm needed.
If using juju first is a prerequisite to reproducing this, I can try
that, but my impression from previous reports has been that this is
@sforshee,
Because in the past mountall would fail if we didn't.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on xenial
Status in linux package
@sforshee - are you saying that removing the debugfs line from
/usr/share/lxc/config/ubuntu-common.conf fixes this for you?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
Serge: Why do we need to mount debugfs in containers? Even in the host
we restrict access to root.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on
** Changed in: linux (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on xenial
Status in linux package in
Also wrt to Juju, if I do the following:
umount /sys/kernel/debug
mount -t debugfs none /sys/kernel/debug
And then reissue a juju bootstrap it will complete successfully :\ where
as before I was running into this error:
http://paste.ubuntu.com/15267564/
--
You received this bug notification
Here is my config:
name: juju-078fe32d-4080-4f11-83e2-e579ead11df8-machine-0
profiles:
- default
- juju-myish
config:
user.juju-model-uuid: "true"
user.user-data: |
#cloud-config
output:
all: '| tee -a /var/log/cloud-init-output.log'
runcmd:
- set -xe
- install -D -m
This is the config from the container that had the issue this morning:
c@mawhrin-skel:~/omnibus-layers$ lxc config show
juju-145a3177-d1c0-4974-89f6-feaebb3ca87d-machine-0
name: juju-145a3177-d1c0-4974-89f6-feaebb3ca87d-machine-0
profiles:
- default
- juju-lxd
config:
user.juju-model-uuid:
FWIW I've observed the bug outside of Juju. Launching a trusty
container, sshd did not start until I remounted debug on the host. The
main reason it's been observed with juju is, Juju tries to SSH into the
instance right after cloud-init, but upstart in the container isn't
starting sshd so
Also cannot reproduce in a clean VM, so I have to assume juju is
tweaking something.
Can you show output of 'lxc config show ' where
is the container which fails?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
marking confirmed because two people have reported it, but I cannot
reproduce it yet.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on xenial
I'm on the same kernel
Linux sl 4.4.0-8-generic #23-Ubuntu SMP Wed Feb 24 20:45:30 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
and also have the tracefs mounted
0 ✓ serge@sl ~ $ grep debug /proc/self/mountinfo
74 19 0:7 / /sys/kernel/debug rw,relatime shared:26 - debugfs debugfs rw
44 74 0:9 /
I also confirmed that the mountall error message was duplicated every
time I restarted the machine-0 container -- until remounting on the
host.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
26 matches
Mail list logo
