Quoting Michael Adam (ob...@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 Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/925513 Title: plymouth should not run in container To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/925513/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
