From owner-freebsd-arch@FreeBSD.ORG Sat Feb 19 14:55:33 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 AC00B106566C for ; Sat, 19 Feb 2011 14:55:33 +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 7F6EE8FC0C for ; Sat, 19 Feb 2011 14:55:33 +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 <0LGV00300DGKND00@smtpauth1.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 19 Feb 2011 08:55:32 -0600 (CST) Received: from comporellon.tachypleus.net (adsl-76-208-68-88.dsl.mdsnwi.sbcglobal.net [76.208.68.88]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LGV0033DDGI3E00@smtpauth1.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 19 Feb 2011 08:55:31 -0600 (CST) Date: Sat, 19 Feb 2011 08:55:30 -0600 From: Nathan Whitehorn In-reply-to: To: freebsd-arch@freebsd.org Message-id: <4D5FD9E2.9030603@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.68.88 X-Spam-PmxInfo: Server=avs-13, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.19.144218, SenderIP=76.208.68.88 References: User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Subject: Re: FreeBSD Installer Roadmap 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: Sat, 19 Feb 2011 14:55:33 -0000 On 02/19/11 03:34, grarpamp wrote: > Sysinstall is fine, as I'm sure any replacement will be. So I'll > just note a few things I'd like to see in any such replacement... > > 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > on the box were needed with that. Operators skills were in question, > so having them use the dialog menus properly was a pain and often > resulted in non-zeroed disk or half built systems. And though all > else was cloned, it needed a separate.cfg for each box due > to: > > fqdn, gateway, ip/mask > interface - sometimes changed > root disk - sometimes changed > > Would have killed for a simple console shell script to ask those > questions of the operator, per machine. > > 2 - Being able to skip, replace, or prefix/suffix each stage of > whatever the installer would do with a shell script (ala: distSetCustom > local) would be cool. > > 3 - Options to dd if=/dev/zero of=/dev/[x] bs=1m, where x are any > boot sectors, drives, slices, partitions, labels, etc that would > otherwise be blown away but not fully wiped beforehand. > > > And a request for some remaining bugs to be fixed, implemented anew > or figured out... > > 1 - Setting debug=yes was great[a], up until you tried to get that > resultant file off the system or view it. Due to the way things > were mounted with mfsroot and the alt-f4 shell being separate, I > never did figure out how to do that. > > [a] - only when calling /stand/sysinstall from your development box > to test your install.cfg, and the install process. Not when actually > installing a box. > > 2 - mediaClose - didn't work right. I couldn't get the base > distribution bits from one ftp server, and the local distribution > bits from another. > > > And in general, I'll cheer for whichever camps are doing... > As opposed to mfsroot, boot a stripped kernel, on real filesystem, > with init to shell to installer. > and installroot things from there. > Some sort of plaintext backend that can read a config. > Pluggable frontends, at minimum 80x25 console shell, then > dialog/web/xorg/whatever. > Network boot, retrieve config via net, etc. > > It would be cool to have an 'installer build' config option set > available during buildworld too. Much like you can configure crunchgen > to customize the crunch, you could customize certain parts of how > you wanted the installer to work. Particularly for things that might > take up space, what it thinks are its first places to get input, > boot from, display, where to find its config while blind, etc. > And a stripped buildworld kernel config for use with the installer. > Call it just more permutations on the liveCD concept. > You've basically described how bsdinstall (and, largely, pc-sysinstall) works in this mail. The zeroing thing would have to be done by hand (e.g. from the installer script or a shell), and there is currently no built-in fetch a configuration from the network option. The 'installer build' option is also something you have to do by hand, although it is not complicated. Since the installation process is controlled by a shell script, any of these things would be easy to add. Since we have several months yet to add them before the release, patches are very welcome. -Nathan