Solved iocage does not handle releases properly

H

hukadan

Guest
Up to now, I have always used iocage(8) with the release of the host system. Today, I wanted to try to create a jail with the 9.3-RELEASE but I ended up with a 10.2-RELEASE on the jail. To be sure I did things properly, I did the following steps.
Code:
# iocage clean -r

  WARNING: this will destroy all releases
  Please make sure all basejails are stopped before continuing.
  Are you sure ? y[N]: y
  Destroying zroot/iocage/base
  Destroying zroot/iocage/download
  Destroying zroot/iocage/releases

Just to be sure.
Code:
# sudo iocage list -r
  INFO: Creating zroot/iocage/download
  INFO: Creating zroot/iocage/releases
Downloaded releases:

Then I fetched the 9.3-RELEASE.
Code:
# iocage fetch
Supported releases are:
  10.2-RELEASE
  9.3-RELEASE
Please select a release [10.2-RELEASE]: 9.3-RELEASE
base.txz  100% of  67 MB 1957 kBps 00m35s
doc.txz  100% of 1409 kB 1854 kBps 00m01s
lib32.txz  100% of  11 MB 2091 kBps 00m06s
src.txz  100% of  98 MB 2114 kBps 00m48s
Extracting: base.txz
Extracting: doc.txz
Extracting: lib32.txz
Extracting: src.txz
* Updating base jail..
Looking up update.FreeBSD.org mirrors... none found.
Fetching public key from update.FreeBSD.org... done.
Fetching metadata signature for 9.3-RELEASE from update.FreeBSD.org... done
>--- SNIP ---<
Installing updates... done.

Creating basejail ZFS datasets... please wait.

Once again to be sure.
Code:
# iocage list -r
Downloaded releases:
  9.3-RELEASE

To me, everything looked fine. So I created my jail.
# iocage create release=9.3-RELEASE hostname=test-stuff-9.3 ip4_addr='lo1|10.0.0.60' tag=test-stuff-9.3
# iocage start test-stuff-9.3
# iocage console test-stuff-9.3

Then, once in the jail, it tells me that the jail is running the 10.2-RELEASE.
Code:
# uname -r
10.2-RELEASE
To be complete, the host system is running 10.2-RELEASE-p5, I have the latest version of iocage(8) and my system was installed a month ago (so no previous iocage(8) version used before).
Code:
#iocage version
iocage 1.7.3 (2015/08/13)

Does someone have the same problem ? My next step will be to nuke everything with iocage clean -a to see if it helps but I have some jails already configured and it would be great to solve the problem without destroying them.

Thank you.
 
I think this is the normal behaviour, UNAME_r is an environment variable and is inherited when you enter your jail. sysutils/iocage should probably do the same thing as ports-mgmt/poudriere-devel, ie modify /etc/login.conf this way (replace 10.1 with your jail release version):
Code:
--- etc/login.conf.orig 2015-09-22 09:14:34.992065000 +0200
+++ etc/login.conf  2015-09-22 09:17:13.459545000 +0200
@@ -26,7 +26,7 @@
:passwd_format=sha512:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
-  :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
+  :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,UNAME_r=10.1-RELEASE-p20,UNAME_v=FreeBSD 10.1-RELEASE-p20,OSVERSION=1001000:\
:path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\
:nologin=/var/run/nologin:\
:cputime=unlimited:\

Edit: it is done here in poudriere: https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/jail.sh#L150
 
Thank you. I think I overlooked that aspect of jail(8) since I always used the same RELEASE on host and jail(8) in the past. I will look into that.
 
I looked into those aspect of jails and I found that two new jail(8) parameters where introduced (see FreeBSD 10.2-RELEASE Release Notes) : osrelease and osreldate. According to the commit message (r280632):
Allow the kern.osrelease and kern.osreldate sysctl values to be set in a jail's creation parameters. This allows the kernel version to be reliably spoofed within the jail whether examined directly with sysctl or indirectly with the uname -r and -K options.
So it is technically possible to obtain the expected behavior without editing /etc/login.conf starting from 10.2-RELEASE onward. May be this is not yet implemented in iocage(8) due backward compatibility considerations.
 
Back
Top