On Fri, 1 Mar 2002, Glenn Gombert wrote:

>    I have spent several months figuring how to do diskless mounts for
> test kernels, run debuggers from serial terminals and do remote kernel
> debugging with gdb, and spent lots and lots of time doing is as well. 
> Some 'up to date' "How To's" are really needed to support this kind of
> debugging and testing efforts, the material in the FreeBSD manual is
> helpful to a point, but much 'key' information on such subjects is just
> not there and has to be dug out of mailing list archives and just
> sending e-mails to various people who have done such things in the past
> and ask for help, taking up their time...which could be saved with some
> up-to-date documentation :))

If you want to start writing that stuff up for inclusion in the FreeBSD
Handbook or some related location, I'd be happy to review it for content,
since I use what sounds like a very similar development environment.

In my environment, I have a central build and file server, and then a
series of network booted crash machines.  The central server has two
ethernet cards, one going to the "outside world" for some definition of
outside, and the other a dedicated development network.  The server runs a
DHCP server for the development network, a TFTP server to server copies of
pxeboot(8) for the development network, and NFS exports of a /usr/netboot
tree where I store the diskless roots, kernels, et al for the crash boxes.
Typically, I'll use


as the roots for each environment, point tftpd(8) at /usr/netboot as its
root, and appropriately configure the DHCP server to point each host at
the right root directory to pull down pxeboot, and for its later NFS root.
I also hook up serial consoles for each box; currently working on remote

Depending on what I'm working on, I may use the crash boxes in different
ways.  Frequently, I'll boot them entirely from the network, with a
complete installkernel and installworld into their roots under
/usr/netboot.  However, if I'm doing filesystem related work, I may do
more disk-centric installation mechanisms.  I haven't tried the modified
install floppy trick.

Some cute tricks..

newfs is faster than fsck.  If you need to use local filesystems on the
box, and don't care about persistent data, it's a lot faster to newfs the
file systems than do the file system check :-).  If that's true for even
one file system, it's an improvement.  Sometimes I wonder if that wouldn't
be a good change for all installs :-).

Some boxes appear to have broken serial break support.  There's a kernel
option for an alternative break key that can be quite useful.  I have this
problem with two SGI boxes I'm using for various TrustedBSD-related

I can configure the hard disks as dump devices, and by swapping back and
forth between kernels, I can pull the dump over to the development server. 
It may be you can dump over the network, but perhaps not :-). 

It's possible to replace the kernel out from under a machine while still
crashing/dumping/rebooting.  This can dramatically reduce the
develop/compile/install/test/crash/repeat cycle by coallescing the test
and crash bits with the other bits, since you can compile while still
testing or crashing.

If you have multiple machines, you can easily allocate them to various
projects, etc, etc.  I have a couple of scripts that help populate a
system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc,
etc.  I generally also tweak the rc.diskless[12] scripts a bit based on
what I need.  I also tend to enable remote root login and empty passwords
for the crash box in sshd_config so that I can login into the machines
once they come up very easily. 

Occasional PXE bugs can be very frustrating.  Some machines I've used have
no problem loading pxeboot from a different machine than the DHCP server.
A couple of others ignore the server specification in the DHCP response
and insist on trying to tftp pxeboot from the DHCP server.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to