I   would be happy to help with this, I will revise a section at a time in
Developers Handbook on "Kernel Debugging" and then post it for review. I
hope it helps others (and can save some precious time of other busy folks
as well), I will try and have a section done by the end of next week :)

At 06:58 PM 3/1/2002 -0500, Robert Watson wrote:
>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
>  /usr/netboot/crash1.decoverly.watson.org
>  /usr/netboot/crash2.decoverly.watson.org
>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
Glenn Gombert

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

Reply via email to