From owner-freebsd-stable Mon Jan 25 10:20:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19090 for freebsd-stable-outgoing; Mon, 25 Jan 1999 10:20:01 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19048 for ; Mon, 25 Jan 1999 10:19:58 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with SMTP id SAA22360; Mon, 25 Jan 1999 18:18:58 GMT (envelope-from arg@arg1.demon.co.uk) Date: Mon, 25 Jan 1999 18:18:57 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk cc: Greg Quinlan , freebsd-stable@FreeBSD.ORG Subject: Re: Making a bootable CD for FreeBSD-stable? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 25 Jan 1999, Dom Mitchell wrote: > On 25 January 1999, "Greg Quinlan" proclaimed: > > Has anyone got any ideas about a diskless configuration of FreeBSD on a > > bootable CD-ROM. > > > > ie. > > no swap > > /var & /tmp ... etc as ram disks. > > > > Too complex or too easy? > > > > All I need is for someone to point me in the right direction! > > Look in the -current archives, about 6 months ago. Satoshi asked this > one. I seem to recall that the conclusion was "don't bother, you'll fry > your CDROM drive far too quickly". Depends what you want to do with it. I have a setup where this suits me just fine: I want to boot, load an application and just sit there running it all day. With enough RAM, everything sits in core and so the CDROM doesn't get burned out. My particular application is a production-line functional test system for a piece of consumer electronics. The great benefit to me in the CDROM boot approach is that the machines in question are 'just windows PCs', hence if they get broken/corrupt on the factory floor, local people can fix them, whereas if they had full FreeBSD installations I would get called out on site to fix trivial problems. Additional benefits are that the CDs simplify sending updated test software (and, crucially, backing out to the previous version in the event of problems), and the CDs provide a more bullet-proof audit trail - by freezing all the software and its installation details - if any issue should arise as to what test standard was applied. While my application is perhaps unusual, I imagine that quite a lot of the sort of applications that PicoBSD is aimed at would gain from the extra space on a CD - routers, Xterminals etc. One advantage for me is that only the normal working set has to fit in RAM - you can have all the usual FreeBSD tools on there so that for debug use you can live with a bit of CD thrash and just log in on another VT. I've been using 2.2.x, and the only significant problem I hit was with the bootstrap not honouring the -C flag from /boot.config - see patch below. There was also a problem with cd9660 root not working on IDE drives, which has since been fixed. I also hit a PC with BIOS that just won't recognize the output of mkisofs as bootable. A CD-RW drive is essential to get you through the trial-and-error of hacking /etc/rc* to get rid of everything =================================================================== RCS file: /repository/src/sys/i386/boot/biosboot/boot.c,v retrieving revision 1.60.2.3 diff -c -r1.60.2.3 boot.c *** boot.c 1998/02/27 22:56:14 1.60.2.3 --- boot.c 1999/01/25 18:12:26 *************** *** 165,171 **** * XXX this is now too strict. Settings given in boot.config should * not be changed. */ ! loadflags &= (RB_DUAL | RB_SERIAL); /* * Be paranoid and make doubly sure that the input buffer is empty. --- 165,171 ---- * XXX this is now too strict. Settings given in boot.config should * not be changed. */ ! loadflags &= (RB_DUAL | RB_SERIAL | RB_CDROM | RB_VERBOSE); /* * Be paranoid and make doubly sure that the input buffer is empty. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message