HEADS UP: sysinstall is no longer the default installer

Nathan Whitehorn nwhitehorn at freebsd.org
Mon Mar 14 16:38:58 UTC 2011

On 03/14/11 10:38, Giorgos Keramidas wrote:
> On Mon, Mar 14, 2011 at 3:13 PM, Nathan Whitehorn
> <nwhitehorn at freebsd.org>  wrote:
>> 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
>> By default, this will include ports and documentation if you have them
>> checked out to /usr/ports and /usr/doc, though this behavior can be modified
>> (see the top of the makefile). In addition, some architectures (i386, amd64,
>> powerpc, powerpc64, and maybe ia64) have release media that can be
>> cross-built, so you can set TARGET/TARGET_ARCH appropriately for those.
>> Output goes to .OBJDIR, which is /usr/obj/usr/src/release in the case of the
>> above commands. The equivalent to disc1 is called release.iso, the memstick
>> image (i386, amd64 only) is called memstick, and a directory of distfiles
>> for FTP mirrors is generated named ftp.
> Any "user interface" changes that affect the release.7 manpage and may
> catch people building their own release images should be updated in the
> manpage itself too.

Yes. I was hoping to update the manpage in the next couple days.

> Some of the stuff I'd like to see fixed in the release.7 manpage are:
>    - The requirement for CVSUP_HOST should be explicitly mentioned in
>      release.7 for releases that have NODOC.
>      Note: I haven't run a release with the new Makefile yet, but is it
>      still possible to use a local CVS mirror, e.g. /home/ncvs for these
>      files instead of a cvsup host that is only accessible over the
>      (potentially much slower) network?

It isn't possible right now. If you have a pre-existing checkout (from 
whatever source), make release will use that. John Baldwin mentioned the 
cvs changes to generate-release.sh and I'll try to get those in soon.

>    - The make variable ${DATE} is automatically set to the build date. We
>      should probably mention this in the default BUILDNAME description
>      (since it's such a generic variable name).
>    - BUILDNAME is automatically set to a default that may have to be
>      documented to the manpage, so that people know what to expect when
>      they type just "make release" and sit back.
>    - There's a ${BASE} variable set to 9.0 that release engineers may
>      have to manually update when they roll-out release and stable
>      branches. This should be documented in the "shortly before the
>      release" checklist we have in
>      http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html

Some (most) of these variables don't exist anymore. The CD is just 
always named 'release.iso' at the moment, for instance. That can easily 
be changed, however.

>    - The directories that "make release" creates, and the names of the
>      ISO image files should be mentioned in release.7 now that we have a
>      chance to make a batch of useful updates to the text.
> Naturally, I volunteer to *make* the mdoc changes.  As long as someone
> (e.g. you Nathan?) who is acquainted with the new release building
> Makefile can hepl me by reviewing the updates and making sure they look
> reasonably close to the new state of everything.

Sure. I have the feeling that there are going to be a lot of feature and 
change requests today with regard to release infrastructure, so I'll let 
the dust clear for a day or two and we can start hashing out the 

More information about the freebsd-arch mailing list