From owner-freebsd-current@FreeBSD.ORG Sat Feb 19 09:58:49 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 06B171065673; Sat, 19 Feb 2011 09:58:49 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C84028FC17; Sat, 19 Feb 2011 09:58:48 +0000 (UTC) Received: by pwj8 with SMTP id 8so217778pwj.13 for ; Sat, 19 Feb 2011 01:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Qv4u9ltVgNyvA7dKVj8nSSCffm5ZZp3veH6Mx7djFq4=; b=Nm9h6qVyt5zxu5vDJHOj1xx/SAPXte4TMM/6BH6omMPY3aYUeX9cZd40HEqZ2HTSYD 91LEc/Ig3TbmBu0z4N22woE44u0c4r+BTpgD5vzlDozoJTqOQ3tlAN0nIv7rryJg7m3r WBxKZVgASTqvX1yeHURW4bJZ4qzemocfdFl78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=G5w2p5wLjFPvoysk/75CFq1GJqu96cjK3DT381i2xO05nTHailgRQlVeA10DAjC+mV +SqmmNlHyJYx+C1nOAN2Rshoya97yvREb/fWUsLnlmGZlc6ioM7wOtwYCuZGKjUy/zkG XSancPe6xtWNoRExt4Q75SVPJOOeDD22it0w8= MIME-Version: 1.0 Received: by 10.142.13.8 with SMTP id 8mr1285484wfm.133.1298108051640; Sat, 19 Feb 2011 01:34:11 -0800 (PST) Received: by 10.142.128.18 with HTTP; Sat, 19 Feb 2011 01:34:11 -0800 (PST) Date: Sat, 19 Feb 2011 04:34:11 -0500 Message-ID: From: grarpamp To: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 19 Feb 2011 14:11:35 +0000 Cc: Subject: FreeBSD Installer Roadmap 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 Feb 2011 09:58:49 -0000 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.