From owner-freebsd-small Fri Jun 15 14:28:57 2001 Delivered-To: freebsd-small@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [64.211.219.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B7D037B401 for ; Fri, 15 Jun 2001 14:28:51 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA03624; Fri, 15 Jun 2001 14:28:47 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAzCaOch; Fri Jun 15 14:28:37 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA24264; Fri, 15 Jun 2001 14:32:40 -0700 (MST) From: Terry Lambert Message-Id: <200106152132.OAA24264@usr02.primenet.com> Subject: Re: Still confused on what I assume to be a simple problem... To: paul@akita.co.uk Date: Fri, 15 Jun 2001 21:32:39 +0000 (GMT) Cc: arg@arg1.demon.co.uk, freebsd-small@freebsd.org X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ] > The issue here is that you have decided to use PicoBSD rather than a ] > normal system. Putting a normal system on CD is fairly straightforward, ] > and is almost certainly what you want to do unless you have peculiar ] > requirements that you haven't stated. ] ] I don't think you understand. From other posts (that may or may not have made ] it to the list), I've stated that this is a completely custom piece of ] software. This is not a BSD box for the use of BSD - it's a box that runs ] in-house software to do one particular job, and it happens to have been ] written for BSD. All I want is a kernel, some libraries, a few applications, ] some rc scripts and the ability to dial up with a modem. The machine will go ] onto a customer's site in the middle of god knows where. I don't want anything ] on it that does not have to be there. This CD is not for use - it's for ] automated installation. A very, very, very specific installation designed for ] people who have never seen a command line in their lives. They *certainly* ] don't want to know about disk partitions, disklabel, etc. as that defeats the ] object of this exercise. ] ] In other words, I want PicoBSD. A modified install image. But the libraries ] and apps are a bit chunky, can't be shrunk and therefore I need to burn it up ] to CD. The customer takes the CD, puts it in his machine, 10 minutes later ] they fill in some details they are prompted for (custom stuff I'm doing), and ] that's it. They have a working system, on the hard disk, fully installed, and ] they never have to think about it again. The FreeBSD insteallation and release process is not capable of doing this at this time. I recently posted some patches to sysinstall, which were designed to permit the use of kernel configuration files other than "GENERIC" in the production of CDROM images. These patches were rejected by Jordan as "unnecessary", even though there are a lot of us who would use them (including anyone with a custom engineering workstation environment, etc.). You can pick these patches up from the mailing list archives. This isn't the whole thing, though, since there are several other things you will need to do that have been pretty much ignored in the FreeBSD community, so far: o Base system components are not registered with the package system, and are installed monolithically. This means that you can't omit them in a particular installation. The workaround for this lack is to install them, and then delete off the stuff you don't need (sort of a reverse 'mtree' scenario). This doesn't work well if you are doing an install to small media, such as flash, since the install image is very large; the fact that it gets small enough to fit later is insufficient consolation o The install system is not scriptable. This means that even if you broke the base system up into components, you would be unable to automate the installation process. The workaround for this is to replace sysinstall with your own program; potentially, this program would invoke a shell script at a known location on the CDROM, which could do all the necessary partitioning work, etc., and untar an image of your system which was hand-crafted, and added to the CDROM. o It's hard to replace sysinstall. The image building process makes it very difficult to do an easy replacement of sysinstall, since it has so many bad assumptions (the assumption that it will build and use a sysinstall program). The workaround for this is to change the boot blocks to load your program instead of sysinstall, and just let it build the thing. The problem with this is that you could run out of space on the boot floppy image on the CDROM which is being used to do the boot from CDROM. o If you boot to a login prompt, there are a series of things that you can do to "rebadge" the system (an important thing for embedded systems that ship in real products). These are poorly documented; I'm working on an article to tell people how to address this. Unfortunately, to do a complete job, you need to patches to /bin/login (I posted these as well), patches to the boot prompt statement in /usr/src/sys/boot/i386/boot2/boot2.c, and patches to the FreeBSD kernel itself, to permit stripping/replacement of Copyright statements (this *IS* legal, even if it is quite undesirable from the projects perspective, so long as credit is given in the accompanying documentation). Most of these patches have also been rejected through a failure to commit them, and that has stalled my completion of the article (actually, a series of them for Pentad Embedded Systems Journal). o There are other issues, such as default configuration files for things like putting a "-P" in /boot/config to permit use of a serial console (if the thing has a consle at all), and the creation of /etc/ttys based on compilation options for the "make release" process, to start a getty on the port; similarly, /etc/login.conf and /etc/gettytab contents need to have "plus user information" or "replace these" options. Note: There are "patch" processes wedged into the "make release" process. These are woefully inadequate for your needs, since using them damages your ability to do a "make rerelease" or to make an updated system (say for tracking -stable bug fixes), since it will result in unresolvable cvs conflicts, in the same way that patching GENERIC instead of using your own config file will cause problems. o FreeBSD doesn't support the "field upgrade" operation on embedded systems very well since the conversion to ELF broke "nextboot". I have code to do this about 3/4's complete, and promises of help from a couple of other people, so this might be possible to fix in the near future. o FreeBSD's startup scripts are rather monolithic; this pretty much means you end up having to "roll your own", or have to install everything and config the hell out of it with a very big rc.conf and a potentially very large rc.local. This is being addressed: -current is talking about bringing in the NetBSD rc scripts. This isn't very helpful, unless there is an MFC ("Merge From Current"), since it is unlikely that 5.0 will be usable in a product for a very long time (perhaps as far away as late 2002 and a 5.2 release). Sorry. I guess this is your workaround for the "field upgrade" problem? I've got code that addresses a lot of these things (thought not the rc file stuff and not the software layering stuff), but there seems to be little willingness to commit the code. This may be because making FreeBSD more usable for embedded systems conflicts with the interests of WindRiver Systems; certainly, there is no rational explanation for keeping these things broken that has been presented as an alternative explanation. I suspect that for the immediate future, you will find that you will have to do the "replace sysinstall using a patch" approach, and have an image of the system you want and a script that spams it onto the disk without sufficient error checking... I know that that's not the answer you wanted. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message