From owner-freebsd-questions@FreeBSD.ORG Sun Apr 26 00:19:17 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 342BB106564A for ; Sun, 26 Apr 2009 00:19:17 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id B747B8FC19 for ; Sun, 26 Apr 2009 00:19:16 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:57946 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1Lxs5C-0001uj-3W for freebsd-questions@freebsd.org; Sun, 26 Apr 2009 02:19:00 +0200 Received: (qmail 72457 invoked from network); 26 Apr 2009 02:18:55 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 26 Apr 2009 02:18:55 +0200 Received: (qmail 89241 invoked by uid 1001); 26 Apr 2009 02:18:55 +0200 Date: Sun, 26 Apr 2009 02:18:55 +0200 From: Erik Trulsson To: Tim Judd Message-ID: <20090426001855.GA89151@owl.midgard.homeip.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1Lxs5C-0001uj-3W. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Lxs5C-0001uj-3W ff3d4ce3c88e31b5970d889dfa7f92a8 Cc: FreeBSD Questions Mailing List Subject: Re: Modern FreeBSD Installer? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 00:19:17 -0000 On Sat, Apr 25, 2009 at 05:45:49PM -0600, Tim Judd wrote: > Reading the second half of these mailings got me thinking. Thinking of ways > to detect what CAN be done, and what CAN'T -- based entirely on the hardware > at boot. I think that we might come to a middle ground to get something > working. Here's my thought process right now, with hopefully ample samples > to example my angle (that was fun to say). > > > It's based on two principles. First is the CPU class. If it's a 486 or > 586, run a pure dialog(3) interface. If it's a slow 686 (and the fudge > factor to define slow is based on Xorg's *recommended* CPU specs + the > software installation CPU/RAM needs), run the dialog(3) interface. If it's > a fast 686, default to a X environment. As long as you have sufficient RAM (and you don't actually need all that much of it) running X on an older CPU should not be much of a problem. (Unless X.org has bloated really badly over the last couple of years.) > > Second (which ties into the first) is the hardware that was probed during > boot-time. If a /dev entry (or even some sysctl) exists for a pci/agp/pci-e > device, it can run a graphical installer. If it finds none of the graphical > adapters, and sees serial ports, enable the dialog(3) as well. I feel like > some pseudo-code might help paint the picture more. > > > text-mode_install = graphic-mode_install = false > if (CPUCLASS<=586 || CPUSPEED<=(Xorg-suggested-minimums+install > requirements)) { > set text-mode_install true > } else { > set graphic-mode_install true > } > if (found(VGA-graphics) && graphic-mode_install) { > exec xinstall > } else { > # enable console installer > exec sysinstall > } > > > > I seem to find this very logical and can't (yet) see any flaws with doing > this. sysinstall is built, we'd just need to maintain it and create the > x-based installer. Run it with a minimalist (twm?) startup so we don't > waste time booting. That logic will often do the wrong thing for servers. They are the most common case where people want to install using a serial console, but typically do have a (fairly simple) graphical adapter and could run a graphical installer perfectly well. That does not necessarily mean that the person doing the install wants to do it. Better would be to check (somehow) for the presence of a keyboard and a screen. If those are not present forget about X. If they are present then the user at least has a possibility of using X. Also keep in mind that there are graphical adapters/screen combinations where X will not work correctly without first tweaking configuration files. Things have improved greatly here in recent years, but it is still not perfect. Text mode is still a good deal more compatible with all kinds of weird hardware. > > I've also thought about the concept of a web-ui installer, even if it's run > from the local machine. The benefit of a webui installer is that you can > give the disk to someone, tell them to put it up on a publically available > IP address and just sit back and let it run. but I ramble on.... > > > > And also brainstorming now has brought me another idea about installing base > with the concerns Jordan Hubbard wrote in 2000 mentioned in this thread. > Again based on the hardware probed (this one being the amount of RAM in the > box, in contrast to the amount of disk space needed to install on disk), > create a in-ram disk as the staging area when you write to disk. The other > idea is to use dump/restore instead of tar files. > > It is possible to have a 3GHz machine with 256MB ram as a valid combination, > but when bin distribution is about 128MB in size, and kernel distribution is > 128MB in size, and blindly running an X install -- not wise. > > > > Last idea is to do similar to what Ubuntu (used to) do. Provide a X-based > installer CD and a console-based installer CD. > > > I'd be happy to provide feedback; these were brainstorming ideas and would > really like to see progress move toward a more eye-candy installer. I fail to see what the point of an X-based install would be - other than pure eye-candy, which does not seem very important for something like an installer which is used so rarely. -- Erik Trulsson ertr1013@student.uu.se