svn commit: r256256 - in head: . etc etc/defaults etc/rc.d share/man/man5 usr.sbin/jail

[Hiroki Sato]

Remko Lodder <remko at FreeBSD.org> wrote
  in <04E9979E-1D97-4AA2-A7AE-F9D8457B3599 at FreeBSD.org>:

re>
re> Hi Hiroki,
re>
re> On Oct 10, 2013, at 11:32 AM, Hiroki Sato <hrs at FreeBSD.org> wrote:
re>
re> > Author: hrs
re> > Date: Thu Oct 10 09:32:27 2013
re> > New Revision: 256256
re> > URL: http://svnweb.freebsd.org/changeset/base/256256
re> >
re> > Log:
re> >  - Update rc.d/jail to use a jail(8) configuration file instead of
re> >    command line options.  The "jail_<jname>_*" rc.conf(5) variables for
re> >    per-jail configuration are automatically converted to
re> >    /var/run/jail.<jname>.conf before the jail(8) utility is invoked.
re> >    This is transparently backward compatible.
re> >
re> >  - Fix a minor bug in jail(8) which prevented it from returning false
re> >    when jail -r failed.
re> >
re>
re> Thanks for doing such a massive update. However it seems to break the
re> ezjail utility.
re> My jails didn't restart after I upgraded to the most recent -head
re> version
re>
re> FreeBSD nakur.elvandar.org 10.0-ALPHA6 FreeBSD 10.0-ALPHA6 #7 r256311:
re> Fri Oct 11 13:27:54 CEST 2013
re> root at nakur.elvandar.org:/usr/obj/usr/src/sys/NAKUR amd64
re>
re> If I replace this with an older version, the utility starts and
re> complains about certain things not being done properly. The
re> system does not mount devfs nodes anylonger and thus is basically out
re> of function.
re>
re> I was not expecting this much fallout from this change, others that
re> will be upgrading will loose the ability to start their jails until
re> they can
re> resolve this by hand.

 Can you send me your ezjail configuration and differences of the
 results (error messages, mount handling, etc) between old and new
 rc.d/jail?

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20131012/4b8150d4/attachment.sig>