Date: Tue, 14 Sep 1999 10:20:00 +0200 From: Sheldon Hearn <sheldonh@uunet.co.za> To: Eliezer Rodriguez Gonzalez <elie@uncle.cult.cu> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Remote system upgrade via NFS problems. Message-ID: <27100.937297200@axl.noc.iafrica.com> In-Reply-To: Your message of "Mon, 13 Sep 1999 16:37:59 -0400." <Pine.BSF.4.05.9909131632010.11964-100000@uncle.cult.cu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Sep 1999 16:37:59 -0400, Eliezer Rodriguez Gonzalez wrote: > I guess this behaviour is normal, I just need to know how to avoid it > and perform the upgrade on the remote machine taking advantage of the > previous build process. The problem is that you're doing something _very_ involved and delicate when you upgrade from aout to elf. If you were just doing an upgrade from, last week's STABLE to this week's STABLE, it'd be easy: On the box that hosts the source, do ``make buildworld''. Copy your obj tree to some backup, e.g. cp -pR /usr/obj /usr/obj.mint Export your obj tree and source tree to the hosts requiring upgrade as normal. You can now do ``make installworld'' from those hosts, one at at time. In between each ``make installworld'' that you perform on the hosts, you should copy the backup obj tree back to the exported tree, e.g. rm -rf /usr/obj/* chflags -R noschg /usr/obj rm -rf /usr/obj/* cp -pR /usr/obj.mint/* /usr/obj This whole process of preserving the obj tree may not be necessary any more. A long time ago, I heard that the ``installworld'' target messed with some of the stuff in the obj tree. If you'd like to try skipping the preservation steps, I'd appreciate feedback. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27100.937297200>