Date: Fri, 15 Jun 2001 21:32:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: paul@akita.co.uk Cc: arg@arg1.demon.co.uk, freebsd-small@freebsd.org Subject: Re: Still confused on what I assume to be a simple problem... Message-ID: <200106152132.OAA24264@usr02.primenet.com>
next in thread | raw e-mail | index | archive | help
] > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106152132.OAA24264>