From owner-cvs-src@FreeBSD.ORG Fri Nov 2 13:09:46 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B666516A418; Fri, 2 Nov 2007 13:09:46 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id E121D13C4AC; Fri, 2 Nov 2007 13:09:45 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id lA2Cuhob050508; Fri, 2 Nov 2007 15:56:43 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id lA2CuheW050507; Fri, 2 Nov 2007 15:56:43 +0300 (MSK) (envelope-from yar) Date: Fri, 2 Nov 2007 15:56:43 +0300 From: Yar Tikhiy To: Warner Losh Message-ID: <20071102125643.GA50249@comp.chem.msu.su> References: <200710310926.l9V9Qhi4041450@repoman.freebsd.org> <20071031.111228.85322655.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071031.111228.85322655.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 13:09:46 -0000 On Wed, Oct 31, 2007 at 11:12:28AM -0600, Warner Losh wrote: > > 3) With a bit of hackery around rtld(8), it becomes possible to do destructive > > cross-installs, e.g., i386->amd64 over the live system. > > but this can lead to security issues.) That's why a destructive > > cross-install isn't possible w/o hackery yet. > > Does this mean I can now 'sidegrade' my FreeBSD/amd64 box to > FreeBSD/i386? or is only the 32-bit -> 64-bit direction supported. The approach to the issue in the makefiles is rather general, so it should be OK to 'sidegrade' between any two arch'es. However, some arch'es can be mutually incompatible WRT the boot disk format, e.g., MBR vs GPT. Moreover, even the same boot disk format may need different boot blocks. With all these difficulties in mind, i386 and amd64 present the simplest case as they share the same boot disk format and boot blocks. I see no fundamental obstacles to going from amd64 to i386 or vice versa, but I don't have a free amd64 machine to play with, so I was able only to test that the i386->amd64 installation finished OK -- I couldn't see if the resulting system would boot. The exact procedure I used was as follows: mv /rescue /rescue.sav cd /usr/src make installkernel TARGET_ARCH=amd64 DESTDIR=/ make -DNO_RTLD installworld TARGET_ARCH=amd64 DESTDIR=/ PATH=/rescue.sav exec sh cd /libexec chflags noschg ld-elf.so.1 mv ld-elf.so.1 ld-elf.so.1.old cp /usr/obj/amd64/usr/src/libexec/rtld-elf/ld-elf.so.1 . chmod 555 ld-elf.so.1 chflags schg ld-elf.so.1 reboot Notes: `cp -R /rescue /rescue.sav' would create a separate file for each link to rescue(8), so mv is much better. DESTDIR=/ is there to convince our build subsystem that you do know what you're doing. It won't let you install for a different arch unless DESTDIR is set. `exec sh' switches to /rescue.sav/sh, thus releasing the old ld-elf.so if the shell was the only user process using it. If you dare follow the procedure from multi-user mode, you'll still need to mv the old ld-elf.so out of the way, as attempts to overwrite it will fail with ETXTBSY. The 32-bit loader ld-eld32.so is installed for amd64 via a special target in src/Makefile.inc1 and it isn't affected by -DNO_RTLD, so you don't have to copy it manually when 'sidegrading' to amd64, it'll be there just after installworld. -- Yar