Header RSS Feed
 
If you only want to see the articles of a certain category, please click on the desired category below:
ALL Android Backup BSD Database Hacks Hardware Internet Linux Mail MySQL Monitoring Network Personal PHP Proxy Shell Solaris Unix Virtualization VMware Windows Wyse

Does an Ubuntu 16.04 (xenial) container run on a 14.04 (trusty) host?
Monday - Apr 18th 2016 - by - (2 comments)

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 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.


Go to Homepage home
Linux Howtos how to's
Monitoring Plugins monitoring plugins
Links links

Valid HTML 4.01 Transitional
Valid CSS!
[Valid RSS]

7422 Days
until Death of Computers
Why?