Date: Mon, 24 Sep 2007 21:08:38 +0200 From: Erik Cederstrand <erik@cederstrand.dk> To: freebsd-questions@freebsd.org Subject: Re: Repeated PXE jumpstart Message-ID: <46F80B36.6020707@cederstrand.dk> In-Reply-To: <20070924174200.GA8539@sandvine.com> References: <46F23834.1050004@cederstrand.dk> <46F39CAF.5030306@cederstrand.dk> <20070921205940.V15829@tribble.ilrt.bris.ac.uk> <20070924174200.GA8539@sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ed Maste wrote: > On Fri, Sep 21, 2007 at 09:02:04PM +0100, Jan Grant wrote: > >> The alternative is to put PXE ahead of the HD in the boot order, and >> call back to the deployment host at the end of installation (prior to >> reboot) to signal a DHCP reconfiguration. >> >> It adds a PXE timeout to each boot; the upside is that replacing a >> wedging or otherwise broken install is just a matter of reconfiguring a >> DHCP server. > > You could instead load pxegrub and have it boot from the disk instead > of waiting for the PXE timeout. Or, if you're willing to accept a > network-booted loader, how about just having it load and boot the kernel > from the disk? Someone suggested this approach, but it gets complicated when I add more benchmarking clients to the mix later in the project. I know I can add host-specific setup to dhcpd.conf, and it's possible to do similar things with NFS (I'm installing over NFS) to put the main server in charge of controlling the clients, but it gets complicated if they aren't rebooting synchronously. I'd rather have the clients be in charge of when they reinstall (e.g. when the distribution-building machine has completed the next set of install files). I like Jan Grants idea, but it'll only work if FreeBSD crashes and reboots, not if it hangs, drops to debugger etc. Still, better than nothing! But until I have more time to play around, I'll let the clients commit their post-benchmarking suicide. Erik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F80B36.6020707>