Date: Fri, 01 Mar 2002 19:13:51 -0500 From: Glenn Gombert <ggombert@imatowns.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@freebsd.org Subject: Re: more -current testers Message-ID: <3.0.6.32.20020301191351.00daaf48@imatowns.com> In-Reply-To: <200203020008.g2208TH47729@apollo.backplane.com> References: <Pine.NEB.3.96L.1020301183610.97153A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <dillon@backplane.com> > >: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 > Glenn Gombert ggombert@imatowns.com 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?3.0.6.32.20020301191351.00daaf48>