Does an Ubuntu 16.04 (xenial) container run on a 14.04 (trusty) host?

Written by - 2 comments

Published on - Listed in LXC Linux


The official release of Ubuntu 16.04 xenial is just 3 days away now and after having run apt-get upgrade, the current state seems to be final:

# cat  /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"

Until recently the DISTRIB_DESCRIPTION was: "Ubuntu Xenial Xerus (development branch)".

Time to test some xenial containers but on a host running 14.04. Will it work?
Short answer: yes. Long answer: no. Detailed answer: yes.

The Ubuntu lxc template in 14.04 contains a parameter --release. By using this, I selected the xenial release:

# lxcname=redis01
# lxc-create -n ${lxcname} -B lvm --vgname=vglxc --fstype=ext4 --fssize=10G -t ubuntu -- --release xenial

This worked surprisingly well and the container was shown and could be started afterwards:

# lxc-ls -f | grep redis
redis01        RUNNING  192.168.253.65             -     YES

However within the container, no services was started (not even ssh server):

root@redis01:~# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       279  0.0  0.0  21224  3828 ?        S    11:21   0:00 /bin/bash
root       340  0.0  0.0  37364  3348 ?        R+   11:21   0:00  \_ ps auxf
root         1  0.0  0.0  36536  1940 ?        S    09:28   0:00 /sbin/init

root@redis01:~# netstat -lntup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

The reason why SSH didn't start up automatically, seems to be a missing /etc/resolv.conf. The created xenial container seems to use resolvconf (as the host does too) but the symlinks points to nowhere:

root@redis01:/etc# ls -la |grep resolv
drwxr-xr-x  5 root root    4096 Apr 18 09:22 resolvconf
lrwxrwxrwx  1 root root      29 Apr 18 09:10 resolv.conf -> ../run/resolvconf/resolv.conf
root@onl-redis01-t:/etc# cat /run/resolvconf/resolv.conf
cat: /run/resolvconf/resolv.conf: No such file or directory

After I manually copied the same resolv.conf file from the LXC host (which is also generated by resolvconf), I was able to start SSH:

root@redis01:~# service ssh start
 * Starting OpenBSD Secure Shell server sshd                                                                  [ OK ]

root@redis01:~# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      587/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      587/sshd       

But the much bigger problem is the fact, that xenial uses systemd as new init system/launcher.
As seen in the process output above, PID 1 is /sbin/init. Yet systemd requires to be run as PID 1. If it's not, nothing will work. From https://www.freedesktop.org/software/systemd/man/systemd.html:

systemd is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services.

Not even a reboot works in such a case:

root@redis01:~# reboot
Failed to connect to bus: No such file or directory
Failed to talk to init daemon.

In general it's not a good idea to mix the different init systems in such a scenario. As a container is nothing else than an isolated process (but a process at the end) it should run under the same init system.

Ubuntu 14.04 runs with the "upstart init system" so I tried to install it within the container, too:

root@redis01:~# apt-get install upstart
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following additional packages will be installed:
  dbus libcap-ng0 libcgmanager0 libdbus-1-3 libdrm2 libnih-dbus1 libplymouth4 mountall plymouth
  plymouth-theme-ubuntu-text
Suggested packages:
  dbus-user-session | dbus-x11 desktop-base plymouth-themes graphviz bash-completion upstart-monitor
The following NEW packages will be installed:
  dbus libcap-ng0 libcgmanager0 libdbus-1-3 libdrm2 libnih-dbus1 libplymouth4 mountall plymouth
  plymouth-theme-ubuntu-text upstart
0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,039 kB of archives.
After this operation, 4,127 kB of additional disk space will be used.
Do you want to continue? [Y/n] y

Then installed the upstart-sysv package (sysvinit compatible) which also removes systemd-sysv:

root@redis01:~# apt-get install upstart-sysv
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following packages will be REMOVED:
  systemd-sysv
The following NEW packages will be installed:
  upstart-sysv
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 39.6 kB of archives.
After this operation, 90.1 kB of additional disk space will be used.
Do you want to continue? [Y/n] y

Finally, I removed and purged systemd out of the OS:

root@redis01:~# apt-get remove --purge --auto-remove systemd
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following packages will be REMOVED:
  systemd*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 19.2 MB disk space will be freed.
Do you want to continue? [Y/n] y

 Not surprisingly, a reboot didn't work, so I had to turn of the container with lxc-stop and relaunch it manually:

root@redis01:~# reboot
shutdown: Unable to shutdown system

root@lxc-host:~# lxc-stop -n redis01

root@lxc-host:~# lxc-ls -f | grep redis
redis01        STOPPED  -                          -     YES    

root@lxc-host:~# lxc-start -n redis01 -d

root@lxc-host:~# lxc-ls -f | grep redis
redis01        RUNNING  192.168.253.65             -     YES       

Now the big question: Will the xenial container run with the upstart init system?
And yes - the services were started correctly this time!

root@lxc-host:~# lxc-attach -n redis01

root@redis01:~# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN      338/nrpe       
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      336/sshd       
tcp6       0      0 :::5666                 :::*                    LISTEN      338/nrpe       
tcp6       0      0 :::22                   :::*                    LISTEN      336/sshd       


root@redis01:~# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       499  0.0  0.0  21232  3852 ?        S    11:43   0:00 /bin/bash
root       568  0.0  0.0  37364  3352 ?        R+   11:45   0:00  \_ ps auxf
root         1  0.0  0.0  43408  4260 ?        Ss   11:42   0:00 /sbin/init
root        72  0.0  0.0  29884   296 ?        S    11:42   0:00 upstart-socket-bridge --daemon
root        93  0.0  0.0  29948   268 ?        S    11:42   0:00 upstart-udev-bridge --daemon
message+   122  0.0  0.0  42768  2668 ?        Ss   11:42   0:00 dbus-daemon --system --fork
root       125  0.0  0.0  29900   296 ?        S    11:42   0:00 upstart-file-bridge --daemon
root       127  0.0  0.0  41588  3012 ?        Ss   11:42   0:00 /lib/systemd/systemd-udevd --daemon
syslog     228  0.0  0.0 256396  2684 ?        Ssl  11:42   0:00 rsyslogd
root       291  0.0  0.0  12844  1960 lxc/tty4 Ss+  11:42   0:00 /sbin/getty -8 38400 tty4
root       294  0.0  0.0  12844  1848 lxc/tty2 Ss+  11:42   0:00 /sbin/getty -8 38400 tty2
root       295  0.0  0.0  12844  1860 lxc/tty3 Ss+  11:42   0:00 /sbin/getty -8 38400 tty3
root       336  0.0  0.1  65612  6216 ?        Ss   11:42   0:00 /usr/sbin/sshd -D
root       337  0.0  0.0  26068  2440 ?        Ss   11:42   0:00 cron
nagios     338  0.0  0.0  24056  2420 ?        Ss   11:42   0:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
root       456  0.0  0.0  65408  4328 ?        Ss   11:42   0:00 /usr/lib/postfix/sbin/master
postfix    460  0.0  0.0  67476  4424 ?        S    11:42   0:00  \_ pickup -l -t unix -u -c
postfix    461  0.0  0.0  67524  4460 ?        S    11:42   0:00  \_ qmgr -l -t unix -u
root       494  0.0  0.0  12844  1844 lxc/console Ss+ 11:42   0:00 /sbin/getty -8 38400 console
root       495  0.0  0.0  12844  1824 lxc/tty1 Ss+  11:42   0:00 /sbin/getty -8 38400 tty1

To sum it all up: If you want to run xenial containers on a trusty host, make sure you use the same init system in the container as the host.


Add a comment

Show form to leave a comment

Comments (newest first)

soletan from wrote on Nov 10th, 2016:

Working perfectly. Thanks for the post!


Dave from UK wrote on Oct 2nd, 2016:

Also applicable to OpenVZ.

Intially "apt-get install upstart" reported that that upstart package was obsolete, but after running apt-get update && apt-get upgrade your instructions worked perfectly.


RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Icingaweb   Icingaweb2   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder   


Update cookies preferences