[lxc-users] Ubuntu (maverick) container hangs at init

[Fajar A. Nugraha]

On Fri, May 16, 2014 at 12:47 AM, Stephen Zhang <zsrkmyn at gmail.com> wrote:

>
>
>
> 2014-05-15 20:13 GMT+08:00 Fajar A. Nugraha <list at fajar.net>:
>
>  On Thu, May 15, 2014 at 3:51 PM, Stephen Zhang <zsrkmyn at gmail.com> wrote:
>>>
>>>  I corrected the line in fstab "none /lxc/rootfs.ubuntu/dev/pts devpts
>>> defaults 0 0" to right path, failed.
>>> I comment the line above, failed.
>>> I change the whole fstab using
>>> http://wiki.1tux.org/wiki/Lxc/Installation/Guest/Centos/6 provides,
>>> failed. TAT
>>> All the things happened as the same.
>>> I also changed the lxcguest.conf (the original one is provided by the
>>> package lxcguest) to this (which is found in a previous mail list):
>>>
>>> start on startup
>>>
>>> env container
>>> env LIBVIRT_LXC_UUID
>>>
>>> script
>>>         rm -rf /var/run/*.pid
>>>         rm -rf /var/run/network/*
>>>         /sbin/initctl emit stopped JOB=udevtrigger --no-wait
>>>         /sbin/initctl emit started JOB=udev --no-wait
>>> end script
>>>
>>
>> I'm actually surprised that you were able to create it using template at
>> all. The template should fail due to the fact that lxcguest package is not
>> available for maverick.
>>
>> Anyway, maverick seems to be a tough one. Here's what I did:
>> - Start with whatever lxc-create ended up with. In my case I copied
>> /var/cache/lxc/maverick/rootfs-amd4 to /var/lib/lxc/maverick/rootfs. Revert
>> whatever mannual changes you might have made.
>>
>> - use a config file like this (the container name is "maverick" in this
>> example)
>> ###
>> lxc.utsname = maverick
>> lxc.arch = x86_64
>> lxc.rootfs = /var/lib/lxc/maverick/rootfs
>>
>> lxc.network.type=veth
>> lxc.network.link=lxcbr0
>> lxc.network.flags=up
>> lxc.network.hwaddr= 00:16:3E:82:28:D8
>> lxc.network.veth.pair=veth-maverick-0
>>
>> lxc.include = /usr/share/lxc/config/ubuntu.common.conf
>> #override from common config
>>  lxc.aa_profile = unconfined
>> ###
>>
>> - edit the container's etc/network/interfaces:
>> ###
>> auto lo
>> iface lo inet loopback
>>
>> auto eth0
>> iface eth0 inet dhcp
>> ###
>>
>> - create this file on the container (you can fine-tune this later)
>> # cat etc/init/lxcguest.conf
>> start on started ssh
>>
>> script
>> umount /dev/pts || true
>> mount -t devpts devpts /dev/pts
>> end script
>>
>> - lxc-start -n maverick
>>
>> - (on a different window) lxc-attach -n maverick
>>
>> - on the lxc-attach window, run
>> -- ps -efa
>> -- ifconfig eth0
>> -- (change the root password if you have to)
>>
>> - (from the host): ssh to the container
>>
>> In my test, the container pretty much runs well, all services (e.g. cron,
>> syslog, ssh) started. The only problem is that the console doesn't work
>> (hence, in the future, start the container using "-d"), but lxc-attach can
>> be a workaround for most needs.
>>
>> --
>> Fajar
>>
>>
> It does work!! Thx! But there still are 2 problems:
> 1. It seems that the .conf files in /etc/init/ don't work if they are set
> "startup on runlevel [*]" (* means any possible number) such as rc.conf,
> dmesg.conf and cron.conf. So, the tty*.conf, which are set "startup on
> stopped rc RUNLEVEL=[2345]", are never to be run, for rc.conf does not
> start at all.
>

Works for me. Did you do it like I did?

root at trusty:~# status tty1
tty1 start/running, process 443
root at trusty:~# status cron
cron start/running, process 407
root at trusty:~# status cron
root at trusty:~# runlevel
N 2

Of course, consoles and tty* doesn't work, so it shouldn't matter if tty*
job runs or not.


> 2. I don't know why, but once I start the container, I sometimes may not
> make my terminal work (both urxvt and xfce4-terminal), it says "Fail to
> execute child     grantpt failed: Operation not permitted."
>
>

*shrug*

again, works for me. I'm using ubuntu with gnome-terminal.

There are cases when containers messed up hosts configuration (e.g. it
binds to the hosts's tty). This line

lxc.include = /usr/share/lxc/config/ubuntu.common.conf

includes a common config that (among others) limits what device nodes can
be accessed by the container, so the host and container's pty should not
interfere with each other.


Anyway, I managed to do some improvements:
- REMOVE the lxcguest.conf that you created earlier (or at least, make SURE
it does not contain the /dev/pts mount/umount part)
- (in the container) edit /lib/init/fstab, comment-out these lines

#none            /dev                      devtmpfs,tmpfs  mode=0755
                  0 0
#none            /dev/pts                  devpts
 noexec,nosuid,gid=tty,mode=0620   0 0

- (in the container) ln -s var/run /run
- (in the container) echo lxc/console >> /etc/securetty
- (in the container) create /etc/init/lxc-console.conf

###
start on stopped rc RUNLEVEL=[2345] and container CONTAINER=lxc
stop on runlevel [!2345]

respawn
exec /sbin/getty -8 38400 lxc/console
###


Turn's out container's /lib/init/fstab mounted /dev and /dev/pts over
what's already setup by lxc, making the necessary device nodes (e.g.
/dev/lxc/console) created by lxc unaccessible.

-- 
Fajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140516/44513d5f/attachment.html>