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