From owner-freebsd-current Fri Mar 1 16:13: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id 2B53737B402; Fri, 1 Mar 2002 16:13:00 -0800 (PST) Received: from user-1120a0j.dsl.mindspring.com ([66.32.40.19] helo=europa2) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 16gx90-0006Kn-00; Fri, 01 Mar 2002 19:12:59 -0500 Message-Id: <3.0.6.32.20020301191123.00daaf48@imatowns.com> X-Sender: ggombert@imatowns.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 01 Mar 2002 19:11:23 -0500 To: Robert Watson , julian@elischer.org From: Glenn Gombert Subject: Re: more -current testers Cc: Cliff Sarginson , current@FreeBSD.org In-Reply-To: References: <3.0.6.32.20020301173731.00da4ab0@imatowns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 >power. > >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 >things. > >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 >robert@fledge.watson.org NAI Labs, Safeport Network Services > > > Glenn Gombert ggombert@imatowns.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message