Date: Fri, 1 Mar 2002 18:58:29 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Glenn Gombert <ggombert@imatowns.com> Cc: Cliff Sarginson <csfbsd@raggedclown.net>, current@FreeBSD.org Subject: Re: more -current testers Message-ID: <Pine.NEB.3.96L.1020301183610.97153A-100000@fledge.watson.org> In-Reply-To: <3.0.6.32.20020301173731.00da4ab0@imatowns.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020301183610.97153A-100000>