From owner-freebsd-questions@FreeBSD.ORG Fri Oct 19 14:04:02 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E356338 for ; Fri, 19 Oct 2012 14:04:02 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 292348FC0A for ; Fri, 19 Oct 2012 14:04:01 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.net [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id q9JE400Y005221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Oct 2012 09:04:00 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Oct 2012 09:04:00 -0500 From: dweimer To: Shane Ambler Subject: Re: ZFS / Boot Environments / Jails / Upgrading form Source Code Organization: dweimer.net Mail-Reply-To: In-Reply-To: <508105E2.5060208@ShaneWare.Biz> References: <508105E2.5060208@ShaneWare.Biz> Message-ID: <41d7c0dab7877515ec4d14a8eb4a7e63@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 Cc: FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:04:02 -0000 On 2012-10-19 02:48, Shane Ambler wrote: > On 19/10/2012 07:44, dweimer wrote: > >> First step replace the usr/src within the jail with new source using >> svn, easy enough. Then start make buildworld... oops, I have a >> problem now, the usr/obj/usr stuff is now under >> /usr/obj/usr/jails/release91rc2..., However I want it to be under >> /usr/jails/release91rc2/usr/obj/usr. > > If the jails base dir is /usr/obj/usr/jails/release91rc2 then it can > only access files below that base dir. That is part of the jails > security. > > If your jail is based at /usr/obj/usr/jails/release91rc2 then the > jail > by default will buildworld into /usr/obj of the jail system which > translates to /usr/obj/usr/jails/release91rc2/usr/obj on the base > system. > > You can adjust the settings within the jail but it will always be > within the release91rc2 dir so you can't use the jail to install into > /usr/jails of the base system. The base of the Jail, is /usr/jails/release91rc2, however, I did forget to mention that I was running the buildworld and buildkernel from the base system, with the intent to install using the DESTDIR=/usr/jails/release91rc2 command line option > >> From looking at the usr/src/Makefile It looks like I need to set >> the >> MAKEOBJDIRPREFIX=/usr/jails/relase91rc2/usr/obj/usr/src/tmp >> environment variable, but is that the best solution here? There's >> also a /usr/obj/lib32 directory (system is running amd64, I assume >> this is for 32 bit libraries), so I would likely need to do >> something >> here as well, that I haven't gotten to yet. > > lib32 is part of the final system - you don't need to handle it > separately. See man src.conf if you want to turn off the creation of > 32bit libs. Got it, Fine with leaving it there, just wanted to know if there was a separate option to define where it ended up. > You can set MAKEOBJDIRPREFIX (default /usr/obj ) to define where the > binary files are made. > You can also set DESTDIR (default is / ) for the installworld step to > define where they get installed. It appears I went to deep on my definition of the MAKOBJDIRPREFIX, made the above path after seeing some output at the start of one of my buildworld attempts, which is what led me to believe there would be a second choice. > When you start a buildworld or buildkernel the compiled binaries are > stored within MAKEOBJDIRPREFIX. When that is complete the > installworld > or installkernel steps install the files from MAKEOBJDIRPREFIX into > DESTDIR to create a workable system. That prevents a failed build > from > destroying part of your running system. > > If you want to experiment with different versions then you can also > try- > > mkdir /usr/jails > cd /usr/jails > svn co http://svn0.us-west.FreeBSD.org/base/releng/9.0 9.0-src > cd 9.0-src > set MAKEOBJDIRPREFIX = /usr/jails/9.0-obj > set DESTDIR = /usr/jails/9.0-base > make buildworld && make installworld > > cd /usr/jails > svn co http://svn0.us-east.FreeBSD.org/base/releng/9.1 9.1-src > cd 9.1-src > set MAKEOBJDIRPREFIX = /usr/jails/9.1-obj > set DESTDIR = /usr/jails/9.1-base > make buildworld && make installworld Here was the key information I needed, found several examples searching but none stated the MAKEOBJDIRPREFIX=, as you state below they are not needed for the running system, guessing most people clean them up afterwards so they aren't concerned they don't exist in the same boot environment in the end. I prefer to keep them in the same boot environment if possible, just so that if I delete a boot environment I know I got rid of everything that belonged to it and don't end up uselessly eating up extra disk space. I do delete the /usr/obj/usr directory prior to any rebuild, from old documentation I read when I first started doing source upgrades as a method of improving the speed of the buildworld. I am sure those were written for a 32bit system, which is why the lib32 directory wasn't included in those instructions. >> I know the /usr/obj/usr directory can be deleted after the >> installation of the source, does the same go for the /usr/obj/lib32 >> directory? if so > > Anything in MAKEOBJDIRPREFIX (/usr/obj) can be deleted after you have > installed it, including lib32 which are libs to allow running 32bit > programs on a 64bit system. Looks like I am on the right path, now time to give it a try with the new environment variables, thanks for your help Shane. If all goes well on this step, only things I have left to figured out and test is creating zfs snapshots by hand of volumes outside my boot environment, and mounting those read write within the jailed systems base so that I can fully test my applications against the latest live data without changing the actual data. Don't expect to have any trouble with this one. And then last of all need to test removing a HD from my Virtual Machine, adding a replacement, and rebuilding the mirror, again don't expect this to be a problem, just need to work my way through them and get the steps down before I am comfortable doing these procedures on a system that I need to run when its completed. -- Thanks, Dean E. Weimer http://www.dweimer.net/