SOLVED 11.1 "Container Provider" Rancher VM vs 11.0 iohyve Rancher VM

[gravely]

Prior to upgrading to 11.1, I have been happily running Rancher in an iohyve managed VM that I installed manually using steps similar to those described on this forums resource on the topic for 11.0, How-to: RancherOS on FreeNAS 11.0 – Guide to using RancherOS for Docker functionality on FreeNAS 11.0.

Migrating from one Rancher install to another is pretty easy, because Stacks in Rancher can be exported to docker-compose files. So after upgrading to 11.1, I created a new VM for Rancher as described in the Docker/RancherVM section of the FreeNAS 11.1-RELEASE User Guide and tried to import each of the Stacks I've been using in my 11.0 Rancher installation. I hit a few issues with Rancher version compatibilities re: load balancers, but for the most part, each stack imported cleanly. Bonus: thanks to NFS updates in FreeNAS 11.1, jlesage/crashplan-pro works for me in my 11.1 Rancher installation.

But, all of the linuxserver docker containers I use fail to start.

linuxserver/transmission:latest, for example, simply logs the same error over and over again: exec format error.

plexinc/pms-docker:plexpass also fails to install, with different but similarly alarming errors:


12/27/2017 9:12:15 AM[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
12/27/2017 9:12:16 AM[s6-init] ensuring user provided files have correct perms...exited 0.
12/27/2017 9:12:16 AM[fix-attrs.d] applying ownership & permissions fixes...
12/27/2017 9:12:16 AM[fix-attrs.d] done.
12/27/2017 9:12:16 AM[cont-init.d] executing container initialization scripts...
12/27/2017 9:12:16 AM[cont-init.d] 40-plex-first-run: executing...
12/27/2017 9:12:16 AMbash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
12/27/2017 9:12:17 AM[cont-init.d] 40-plex-first-run: exited 0.
12/27/2017 9:12:17 AM[cont-init.d] 50-plex-update: executing...
12/27/2017 9:12:17 AMbash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
12/27/2017 9:12:17 AMxmlstarlet: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: file too short
12/27/2017 9:12:17 AMNo version specified in install. Broken image
12/27/2017 9:12:17 AM[cont-init.d] 50-plex-update: exited 1.
12/27/2017 9:12:17 AM[cont-init.d] done.
12/27/2017 9:12:17 AM[services.d] starting services
12/27/2017 9:12:17 AM[services.d] done.
12/27/2017 9:12:17 AMbash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
12/27/2017 9:12:17 AMStarting Plex Media Server.
12/27/2017 9:12:17 AM/bin/sh: 1: /usr/lib/plexmediaserver/Plex Media Server: not found
12/27/2017 9:12:18 AMbash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
12/27/2017 9:12:18 AMStarting Plex Media Server.


My iohyve managed Rancher installation, even when I start it in parallel booted into FreeNAS 11.1, is able to run both of those containers without issue.

My host is:
FreeBSD redacted-hostname 11.1-STABLE FreeBSD 11.1-STABLE #0 r321665+d4625dcee3e(freenas/11.1-stable): Wed Dec 13 16:33:42 UTC 2017 root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64 amd64.

My Rancher install is the standard FreeNAS 11.1-STABLE install:
Linux rancher 4.9.45-rancher #1 SMP Sun Aug 27 23:25:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I can revert to 11.0 and continue using iohyve but, but shouldn't this just work? These errors look like x86_64 on i386 errors, which is confusing because this host is x86_64. What have I missed?

Thanks in advance!

Edit: Before I send a report, I thought to try one last thing: use the tag of the versions prior to the current :latest and :plexpass for each docker container. Sure enough, they both worked as expected. Something might be wonky with their build system?

 

[KrisBee]

Did you resolve this issue?

 

[gravely]

I had not, but your question prompted me to consider reporting this issue upstream to the linuxserver folks. Before I send a report, I thought to try one last thing: use the tag of the versions prior to the current :latest and :plexpass for each docker container. Sure enough, they both worked as expected. Something might be wonky with their build system?

With both running, I feel a bit more confident about blowing away my old iohyve managed VM. I'm also going to keep following the VM Suggestions (for 11.1) thread re: middleware, command line access, and rancher os upgrades.

 

[KrisBee]

I'm not making much use of docker myself, but did run these at the rancheros CLI with success :

Code:

docker run -d --name=couchpotato \
--restart=always \
-v /home/rancher/couchpotato/config:/config \
-v /home/rancher/couchpotato/downloads:/downloads \
-v /home/rancher/couchpotato/movies:/movies \
-e PGID=1100 -e PUID=1100 \
-e TZ=Europe/London \
-p 5050:5050 \
linuxserver/couchpotato

and

Code:

docker run -d --name=couchpotato2 \
--restart=always \
-v /mnt/couchpotato/config:/config \
-v /mnt/couchpotato/downloads:/downloads \
-v /mnt/couchpotato/movies:/movies \
-e PGID=1100 -e PUID=1100 \
-e TZ=Europe/London \
-p 5050:5050 \
linuxserver/couchpotato

So not a problem using local storage within rancheros.

Created a nfs share on FreeNAS with this export:

Code:

root@freenasT:/ # cat /etc/exports
V4: / -sec=sys
/mnt/TestPool/VM/docker/couchpotato  -alldirs -maproot="root":"wheel" -sec=sys -network 192.168.0.0/24

added a nfs mount to rancheros cloud-config, and re-created couchpotato2, it started OK and appeared to created correct dir/files on the FreeNAS side, and the couchpotato WebUI was reachable.

Code:

root@freenasT:/mnt/TestPool/VM/docker/couchpotato # ls -l
total 2
drwxr-xr-x  3 rancher  rancher  4 Dec 29 12:28 config
drwxr-xr-x  2 root	 wheel	2 Dec 29 12:27 downloads
drwxr-xr-x  2 root	 wheel	2 Dec 29 12:27 movies

Not tested beyond this.

Upgrading rancher version is not possible while using grub-bhyve as far as I can work out. RancherOS does not use grub, mount the iso or img and you will only find syslinux. Another quirk I also found was setting a static ip in the cloud-config does not prevent the rancher VM from using dhcp first during its init sequence. Check the netconf.log. So dhcp leases are still consumed on your router. Depending on your network setup, this can be a nuisance when doing multiple tests

 

[gravely]

It was specifically linuxserver/transmission:latest and plexinc/pms-docker:plexpass that were giving me trouble. I first tried linuxserver/transmission:100 (the same as latest at the time of this post) and the error persisted so I backed it down to linuxserver/transmission:99 and that worked. I believe that plexinc/pms-docker is replica of linuxserver/pms-docker, so I tried the same thing there: plexinc/pms-docker:1.10.0.4523-648bc61d4 worked when :plexpass and :latest hadn't.

NFS mounts in cloud-config.yml have worked great for me.

 

[KrisBee]

If you are using NFS with numerous containers, then you must be satisfied with performance.

Using mounts in cloud-config.yml works, but is rigid, while rancher-server etc. seems like a sledge-hammer to crack a nut.

I had previously tested docker on a debian net install with portainer and docker-volume-netshares. Using docker-volume-netshares allows the creation of docker volumes that are essentially nfs mounts via portainer's UI, and gives extra flexibility. It can be used with CIFS shares too,

https://github.com/ContainX/docker-volume-netshare

The rancheros volume-nfs service is a system container which basically just runs the docker-volume-netshares program. But the version is out of date - v. 0.19 when the latest is v0.34 - and the config seems screwed and it doesn't function as I expected.

If you're not going to use rancher-server (who needs all that?), I'm not convinced rancheros offers much over a standard linux vm if you're only using a small number of containers other than its quick and simple to create & run a DockerVM.