From owner-freebsd-arch@FreeBSD.ORG Mon Mar 14 16:57:26 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF1A1065673; Mon, 14 Mar 2011 16:57:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB048FC15; Mon, 14 Mar 2011 16:57:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D383946B38; Mon, 14 Mar 2011 12:57:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F0548A01B; Mon, 14 Mar 2011 12:57:25 -0400 (EDT) From: John Baldwin To: Nathan Whitehorn Date: Mon, 14 Mar 2011 12:55:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D7E228A.4090906@freebsd.org> <201103141144.32815.jhb@freebsd.org> <4D7E3A9E.10800@freebsd.org> In-Reply-To: <4D7E3A9E.10800@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103141255.16292.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 14 Mar 2011 12:57:25 -0400 (EDT) Cc: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, FreeBSD Arch Subject: Re: HEADS UP: sysinstall is no longer the default installer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:57:26 -0000 On Monday, March 14, 2011 11:56:14 am Nathan Whitehorn wrote: > On 03/14/11 10:44, John Baldwin wrote: > > On Monday, March 14, 2011 10:13:30 am Nathan Whitehorn wrote: > >> I just committed (r219641) changes that make the release infrastructure > >> (src/release/Makefile) use bsdinstall by default instead of sysinstall > >> on install media. A big thank you is in order to everyone who provided > >> advice, criticism, and testing for this project over the last few months! > >> > >> Along with sysinstall, the original sysinstall build stuff has been > >> preserved (now /usr/src/release/Makefile.sysinstall) and will continue > >> to be for the lifetime of the 9.x release series, although it will not > >> be used by default. This change modifies the process of building > >> releases somewhat, so I'll outline changes that people who run snapshot > >> buildbots will have to make below, and some next steps planned with the > >> installer. > > Please consider supporting using SVN or CVS to obtain docs, ports, and source > > trees. I have a custom SVN repo at work that is not exported to CVS and > > available via csup and am able to use the existing SVNROOT SVNBRANCH variables > > with 'make release'. Having support for this sort of thing would be useful. > > I have also made much use of LOCAL_PATCHES in the past for building releases, > > so having support for that would be useful as well. > > SVNBRANCH works now, and source comes over SVN, the others via cvsup. > Support for a different SVNROOT and regular cvs for ports and docs can > certainly be added. In the case of LOCAL_PATCHES, you can just use the > regular makefile on your patched tree -- I don't think the chroot and > checkouts make much sense in this case. Hmm, I've actually used LOCAL_PATCHES a lot to test out changes while still doing builds in a chroot (I'm paranoid about not having pollution from the build machine in the release builds so have always used the chroot). Being able to use CVS and a custom CVSROOT and SVNROOT would be good to have. > > I think for re@ especially it is nice to just do 'make release TAG=7.2' (or > > some such) and have it DTRT to check out matching ports, doc, and src into the > > chroot, etc. I think the new process should be similarly automated. > > The generate-release.sh script likely needs some work. It exists almost > purely for the benefit of re@, and I don't know exactly what their > requirements are. A list (or patches) would be very welcome. The feature > you want here, though, can be obtained now by the CVSUP_TAG and svn > branch arguments to generate-release.sh. Note that re@ uses CVS to checkout ports and docs rather than cvsup. There was also logic in the old release Makefile to take a single CVS-style src tag and convert it into suitable tags for docs and ports. An example of the re@ style is found in the bottom of the old release(7): EXAMPLES The following sequence of commands was used to build the FreeBSD 4.9 release: cd /usr cvs co -rRELENG_4_9_0_RELEASE src cd src make buildworld cd release make release CHROOTDIR=/local3/release BUILDNAME=4.9-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs RELEASETAG=RELENG_4_9_0_RELEASE After running these commands, a complete system suitable for FTP or CD- ROM distribution is available in the /local3/release/R directory. > > Have you tested network installs using PXE or the like? This was fairly easy > > before as you could copy the '/boot' directory from a bootable ISO and the > > mfsroot was self-contained. Do you now have to put the entire contents of > > release.iso up via NFS? Is there a subset you put in the NFS root and then do > > an NFS or FTP install? > > > > Yes, I have, and it works well (tested on i386, sparc64, and powerpc). > Right now, you need the whole system (which is a regular installworld + > the rc.local to give the installer menu, and, optionally the distfiles). > For the future, the set of things the installer needs from the userland > is intentionally fairly small. I need to do some work anyway to make a > minimal system for bootonly CDs and the like, which should also a > smaller system for PXE as well. Ok. -- John Baldwin