From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 10 03:24:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8536816A4CE for ; Sat, 10 Jan 2004 03:24:14 -0800 (PST) Received: from oneplusone.ch (oneplusone.ch [212.55.208.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC30143D41 for ; Sat, 10 Jan 2004 03:24:11 -0800 (PST) (envelope-from ast@marabu.ch) Received: from oneplusone.ch (localhost [127.0.0.1]) by oneplusone.ch (8.12.9p1/8.12.9) with ESMTP id i0ABO4i3009800; Sat, 10 Jan 2004 12:24:04 +0100 (MET) (envelope-from ast@marabu.ch) Received: (from uucp@localhost) by oneplusone.ch (8.12.9p1/8.12.9/Submit) with UUCP id i0ABO3IC009799; Sat, 10 Jan 2004 12:24:03 +0100 (MET) (envelope-from ast@marabu.ch) Received: from marabu.marabu.ch (marabu.marabu.ch [192.168.21.3]) by nano.marabu.ch (8.12.9/8.12.9) with ESMTP id i0ABLWux019127; Sat, 10 Jan 2004 12:21:33 +0100 (MET) (envelope-from ast@marabu.marabu.ch) Received: by marabu.marabu.ch (8.7.5/20001028-ast-8.3) id MAA16839; Sat, 10 Jan 2004 12:21:31 +0100 (CET) Message-Id: <200401101121.MAA16839@marabu.marabu.ch> MIME-Version: 1.0 (NeXT Mail 3.3 v124.8483.6) Content-Type: text/plain X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b6) Received: by NeXT.Mailer (1.124.8483.6) From: Adrian Steinmann Date: Sat, 10 Jan 2004 12:21:29 +0100 To: freebsd-hackers@freebsd.org X-Organization: Webgroup Consulting AG, Apollostrasse 21, 8032 Zurich X-Phone-Numbers: Switzerland, Tel +41 1 380 30 83 Fax +41 1 380 30 85 Subject: Remote installs without FD/CD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 11:24:14 -0000 The "Discussion on the future of floppies in 5.x and 6.x" thread prompts me to report how we have been upgrading FreeBSD remotely since FreeBSD 3.x. First, we build: . custom minimal kernels for each HW type in the field; we store this kernel in /boot/maint/k.HW.gz . custom MD image for each machine with networking and SSH; we store this MD image in /boot/maint/fs.HW_m.gz when we want to go into "maintenance mode", we simply tell the boot loader to: unload load /boot/maint/k.HW load -t md_image /boot/maint/fs.HW_m set vfs.root.mountfrom=ufs:/dev/md0c autoboot 10 which brings up the machine in ramdisk yet networked, ready to be upgraded. It is reassuring but not necessary to have console access, since the above loader commands can be put into /boot/loader.rc in anticipation of the maintenance boot. The MD image employs a crunchgen which includes /bin/sh, SSHv1, atacontrol, camcontrol, fdisk, disklabel, newfs, tunefs, and tar among other utilities to partition/label/populate ESDI, SCSI, and DOC2K "mass" storage. We prepare stripped down 32MB and 64MB "Styx distributions" (FreeBSD plus selected ports minus lots of stuff) as tarballs for the population. Until now (4.x, i.e., -stable), we have been able to make single bootfloppies containing the boot loader, k.HW.gz, and fs.HW_m.gz for all our hardware types. We create 2 floppies for "GENERIC" hardware (i.e., with fs.GENERIC_m.gz on the 2nd floppy). However, we rarely use such floppies and hence will probably drop them altogether as we go to 5.x. This will remove the space restriction on the MD image, opening up many new possibilities. As a spin off, we make a special ISO image which is a stock miniinst.iso including the GENERIC Styx MD image and tarballs so an "offline Styx install" can be done by booting from that CD and choosing "Fixit from Live CD" in sysinstall. If there is interest, I can furnish a src snapshot of our extensible build system mentioned in http://www.styx.ch/workshop.html which is a step-by-step description on how we do remote upgrades. Adrian