From owner-freebsd-current@FreeBSD.ORG Sat Mar 19 01:56:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04903106566B; Sat, 19 Mar 2011 01:56:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id CAD098FC0C; Sat, 19 Mar 2011 01:56:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LIA00D0081IR900@smtpauth1.wiscmail.wisc.edu>; Fri, 18 Mar 2011 20:56:06 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.65.155]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LIA001VJ81GB010@smtpauth1.wiscmail.wisc.edu>; Fri, 18 Mar 2011 20:56:05 -0500 (CDT) Date: Fri, 18 Mar 2011 20:56:04 -0500 From: Nathan Whitehorn In-reply-to: <9B41C412-A8C4-48B9-AF45-182E5658A238@macktronics.com> To: Dan Mack Message-id: <4D840D34.7030005@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.65.155 X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.19.14822, SenderIP=76.210.65.155 References: <4D7E228A.4090906@freebsd.org> <9B41C412-A8C4-48B9-AF45-182E5658A238@macktronics.com> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 Cc: freebsd-current Current , freebsd-sysinstall@freebsd.org, FreeBSD Arch Subject: Re: HEADS UP: sysinstall is no longer the default installer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 01:56:07 -0000 On 03/14/11 19:20, Dan Mack wrote: > On Mar 14, 2011, at 9:13 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. >> >> Changes to release(7) >> ----------------------------- >> >> Release builds work and look slightly different now, so everyone who snapshot tinderboxes will likely find them breaking shortly. The nearest analog to the old make release (with version-control checkouts and a chroot) is src/release/generate-release.sh, which can be run as generate-release.sh head /path/to/chroot/dir. If you want to include ports and documentation on the release media, CVSUP_HOST must be defined in the environment to point to a cvsup mirror. The output is placed in /R in the chroot directory, as before. >> >> If the chroot is unimportant (it ensures a total clean-room build, but may not be necessary in most cases), you can get a release build using the regular makefile, like so: >> cd /usr/src >> make buildworld buildkernel >> cd /usr/src/release >> make obj release >> >> >> > > > Thanks! For what it's worth, I built a new release using this new method and the only problem I ran into was getting dropped to the "mountroot>" because the memstick's root partition failed to mount. I am not sure if this has anything to do with your changes or not but I thought I would bring it up. After mounting my usb stick with : ufs:/dev/da0a it booted into bsdinstall without issue. I don't know if this was do to kern.cam.boot_delay not being long enough or if it was a problem with the creation of the memstick image. Hm. I'd be interested to know if this is repeatable. The memstick stuff is a fairly new feature, and so hasn't been tested to quite the same degree as the ISOs. In case anyone else wants to try it, there is a memstick image (and ISO) here: http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110313/ > During bsdinstall, there were a bunch of console debug messages spewing alongside the bsdinstall text but they cleared before I could take a picture. Yes, there seem to be some LORs in UFS that get triggered if you untar massive quantities of files very fast. They seem harmless, though. > Now we just need a ZFS template for the partition tool :-) Yes. Hopefully this comes in through collaboration with the pc-sysinstall people. Having gptboot and gptzfsboot be the same thing would also help a great deal toward that goal. > Thanks again! > Glad you liked it! -Nathan