I would be happy to try and revise it as well, I think that many people
would find booting diskless kernels (for debugging & development purposes)
quite useful as well :)

At 04:08 PM 3/1/2002 -0800, you wrote:
>    There is a 'diskless' manual page, /usr/src/share/man/man8/diskless.8.
>    It is somewhat out of date and it would be nice if it had a dhcpd.conf
>    example.  It would be great if someone did a major rewrite of it.
>                                       -Matt
>                                       Matthew Dillon 
>                                       <[EMAIL PROTECTED]>
>: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
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
Glenn Gombert

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

Reply via email to