Bad relative mount path

[sidnei]

Seems like mount.entry with a relative path has been broken recently. Juju creates an lxc config with an entry like:

lxc.mount.entry = /home/user/.juju/env/log var/log/juju

However, using latest lxc from the ppa it tries to mount that into:

/usr/lib/x86_64-linux-gnu/lxc/var/log/juju

... instead of relative to rootfs. As such, the container fails to start.

Incidentally, during lxc-create the logs also seem to use that same path. Seems like some option is not being passed around correctly.

lxc-create 1382535470.641 DEBUG    bdev - trying to mount '/dev/lxc/precise-best'->'/usr/lib/x86_64-linux-gnu/lxc' with fstype 'ext3'
lxc-create 1382535470.760 INFO     bdev - mounted '/dev/lxc/precise-best' on '/usr/lib/x86_64-linux-gnu/lxc', with fstype 'ext3'

[sidnei]

Uhm, apparently that's on purpose given the README at /usr/lib/x86_64-linux-gnu/lxc/README. The mount fails though because the target path does not exist. FTR, the error I get is:

sudo lxc-start -n sidnei-local-machine-2
lxc-start: No such file or directory - failed to mount '/home/sidnei/.juju/local/log' on '/usr/lib/x86_64-linux-gnu/lxc/var/log/juju'
lxc-start: failed to setup the mount entries for 'sidnei-local-machine-2'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'sidnei-local-machine-2'

And the relevant portions from config:

lxc.mount = /var/lib/lxc/sidnei-local-machine-2/fstab
lxc.mount.entry = /home/sidnei/.juju/local/log var/log/juju none defaults,bind 0 0
lxc.rootfs = /dev/lxc/sidnei-local-machine-2

[hallyn]

Which path does not exist - /usr/lib/x86_64-linux-gnu/lxc, or /var/log/juju int he container?

My guess is that /var/lib/juju doesn't yet exist int he container, so lxc can't mount onto it?

[sidnei]

The message is complaining about the full '/usr/lib/x86_64-linux-gnu/lxc/var/log/juju':

lxc-start: No such file or directory - failed to mount '/home/sidnei/.juju/local/log' on '/usr/lib/x86_64-linux-gnu/lxc/var/log/juju'

That might well be that it doesn't exist within the rootfs.

[hallyn]

Quoting Sidnei da Silva (notifications@github.com):

The message is complaining about the full '/usr/lib/x86_64-linux-gnu/lxc/var/log/juju':

lxc-start: No such file or directory - failed to mount '/home/sidnei/.juju/local/log' on '/usr/lib/x86_64-linux-gnu/lxc/var/log/juju'

That might well be that it doesn't exist within the rootfs.

In that case this isn't a bug. We may call it a feature request to
create the directory if it does not exist, but I don't think we want
to support that.

[sidnei]

Agreed, closing.

[msg7086]

I met the same problem.

And find out it's the source directory that does not exist.

In the OP's case /home/user/.juju/env/log does not exist.

[hallyn]

Note that this feature actually now exists. Add 'create=dir' to the mount options. I.e.

lxc.mount.entry = /home/sidnei/.juju/local/log var/log/juju none defaults,bind 0 0

becomes

lxc.mount.entry = /home/sidnei/.juju/local/log var/log/juju none defaults,bind,create=dir 0 0

[drydenp]

What confuses people is just that thing mount error (probably) references the "pivot mount point" that is temporarily used and then exchanged for the real mount point (the thing people have configured). In my case I had just specified a bind mount wrong (in fstab format) and the error was only that 'bind' as a type did not exist ;-). But the error was very cryptic for me until I realized (as per this thread, for me) that it had nothing to do with paths. So the issue is more that the error message is cryptic than anything else.

This was on Debian 8 with LXC 1.0.6 so I cannot say about 2.0.5 at this point but I guess the issue could still be relevant here. Regards.

[baszoetekouw]

Note that this is still an issue (lxc 3.0.2 in Ubuntu 18.10): the error message is quite cryptic and suggests that mounting is happening in the worng dir (an ordinary user like myself is probably not aware how mounting is handled behind the screen, and that "pivot mount points" in /usr/lib are involved at al).

A simple check to see if the dir/file to be mounted exists, before trying to actually mount it, would probably solve this quite effectively.