[Bug 925513] Re: plymouth should not run in container

[Serge Hallyn]

Quoting Michael Adam (obnox at samba.org):
> @Serge,
> 
> Could you explain why use of --path can lead to X crashing where lxc-create
> without --path is not?

After creating such a container, look at /var/lib/lxc/<container>/config
and <provided-path>/config.

> My motivation was: I don't want lxc-create to create the rootfs under /var/lib/lxc.
> I need the stuff to be stored elsewhere.

The recommended way (which will be in the server guide once written, before
release) is to either symlink or bind mount the desired location under
/var/lib/lxc.

> I thought that the --path option in the template was made exactly for
this purpose.

You're not the only one.  This just came up on the lxc-users mailing list,
which is why it stood out to me.

> Also notice that --path is specified as parameter for the ubuntu template
> and not for the lxc-create command:
> it is specified after "--" in the command line.
> 
> So I think it is really the plymouthd doing something with my framebuffer
> (which I assume my X server is also using), somehow eventually killing my
> X session. Does that make sense?

I believe it's involved, but that it wouldn't happen if you didn't use
--path.

> I just noticed that I should probably have called lxc-ubuntu with the --trim option.
> The description of the option is somewhat misleading:

That'll accomplish the same thing in that plymouth won't run :)

> Looking at the trim() function in the script itself, it in particular disables a couple 
> of upstart services: quoting from the script:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls u*.conf); do mv $f $f.orig; done'
>     chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls tty[2-9].conf); do mv $f $f.orig; done'
>     chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls plymouth*.conf); do mv $f $f.orig; done'
>     chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls hwclock*.conf); do mv $f $f.orig; done'
>     chroot $rootfs /bin/bash -c 'cd /etc/init; for f in $(ls module*.conf); do mv $f $f.orig; done'
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> This also explains why another container (lucid) that was created with the --trim
> option works without problems. I will re-test the oneiric container with --trim...

Still, the moral of the story which we both agree on is: plymouth can be
dangerous in containers :)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to plymouth in Ubuntu.
https://bugs.launchpad.net/bugs/925513

Title:
  plymouth should not run in container

Status in “lxc” package in Ubuntu:
  Confirmed
Status in “plymouth” package in Ubuntu:
  Incomplete

Bug description:
  Once upstart knows whether it is running in a container, plymouth
  should not run in a container.  As stgraber said, "it writes some
  error messages to /var/log/upstart (when you have logging) and
  sometimes to the console".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/925513/+subscriptions