# IOCAGE jails not found after pkg upgrade to 0.9.9.1_1



## scrappywan (Dec 7, 2017)

On FreeBSD 11.1 I have four jails running that were created with py36-iocage about three months ago. Recently I ran `pkg update/upgrade` on my system and it upgraded IOCAGE to version 0.9.9.1_1. Since my last reboot IOCAGE can no longer locate any of the jails it originally created as if it doesn't know where to look. The jails themselves are running just fine because I had set boot=on for each jail. I can use `jexec` command to gain shell access to my jails as well. It's just IOCAGE currently doesn't seem to know these jails exist. 

I've tried to figure this out on my own but I'm getting nowhere. If anybody knows of a command or configuration I can edit to regain IOCAGE access to its jails I would be most grateful.


----------



## SirDice (Dec 8, 2017)

This is relevant:

```
20171130:
  AFFECTS: all ports users
  AUTHOR: adamw@FreeBSD.org

  The ports tree has gained "flavors," which are a way to produce multiple
  variations of a port. Some intended examples of this are language
  modules being produced for multiple language versions, and lite/nox11 packages,
  without needing separate ports for each variation. Python ports have already
  been flavored (see the below entry). Flavor support must be added to
  individual ports.

  Flavors are already supported by make, pkg, poudriere, and synth; see the
  manpages for those tools for usage instructions. Portmaster and portupgrade
  don't support flavors yet, but community work on those tools is in progress.

  Some bumps and breakages are inevitable for a major change such as this.
  Please report breakages and monitor the ports@ list for solutions as they
  become available.

20171130:
  AFFECTS: */py*
  AUTHOR: mat@FreeBSD.org

  Ports using Python via USES=python are now flavored.  All the py3-* ports
  have been removed and folded into their py-* master ports.

  People using Poudriere 3.2+ and binary packages do not have to do anything.

  For other people, to build the Python 3.6 version of, for example,
  databases/py-gdbm, you need to run:

    # make FLAVOR=py36 install
```
See /usr/ports/UPDATING.


----------



## scrappywan (Dec 8, 2017)

I ran pkg update/upgrade on my host this morning and up came this:


```
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (31 candidates): 100%
Processing candidates (31 candidates): 100%
The following 15 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        py36-asn1crypto: 0.22.0

Installed packages to be UPGRADED:
        wget: 1.19.1_1 -> 1.19.2
        tiff: 4.0.8 -> 4.0.9
        sudo: 1.8.21p2 -> 1.8.21p2_1
        curl: 7.56.1 -> 7.57.0
        ca_root_nss: 3.32.1 -> 3.34.1

Installed packages to be REINSTALLED:
        py36-urllib3-1.22 (direct dependency changed: py36-openssl)
        py36-requests-2.18.1_1 (direct dependency changed: py36-chardet)
        py36-pytest-runner-2.11.1 (direct dependency changed: py36-setuptools)
        py36-pygit2-0.25.1 (direct dependency changed: py36-six)
        py36-openssl-17.3.0 (direct dependency changed: py36-cryptography)
        py36-iocage-0.9.9.1_1 (direct dependency changed: py36-requests)
        py36-cryptography-2.0.3 (direct dependency changed: py36-idna)
        py36-coloredlogs-7.3 (direct dependency changed: py36-humanfriendly)
        py36-cffi-1.7.0 (direct dependency changed: py36-pycparser)

Number of packages to be installed: 1
Number of packages to be upgraded: 5
Number of packages to be reinstalled: 9

The process will require 1 MiB more space.
5 MiB to be downloaded.

Proceed with this action? [y/N]:
```
So I ran the upgrades and after restarting iocage, it can now control jails via UUID, but not by jail hostname. It also shows all jail states as being down.


```
# iocage start zimj                   
zimj not found!
```


```
# iocage list
+-----+--------+-------+--------------+------------+
| JID |  NAME  | STATE |   RELEASE    |    IP4     |
+=====+========+=======+==============+============+
| -   | mysqlj | down  | 11.1-RELEASE | 172.16.1.2 |
+-----+--------+-------+--------------+------------+
| -   | phpj   | down  | 11.1-RELEASE | 172.16.1.3 |
+-----+--------+-------+--------------+------------+
| -   | zimj   | down  | 11.1-RELEASE | 172.16.1.1 |
+-----+--------+-------+--------------+------------+
```

So this is where I'm at. Not really sure how to fix it so IOCAGE sees jails running on the host machine again. I have read what I can find in the IOCAGE documents but nothing seems to work.


----------



## Snurg (Dec 8, 2017)

I guess it would be best to no longer care about that broken iocage thing, but to use the jail subsystem directly.
Regarding the problems, I'd suggest you to show the jail related snippets in rc.conf and jail.conf (if that file is present at all).
Then we can say more about the actual state your jail subsystem.
For example, I could imagine well that just using `service jail start zimj` and `jls` instead of the failing iocage retours you showed above could work.


----------

