Index: faq/faq4.html
===================================================================
RCS file: /cvs/www/faq/faq4.html,v
retrieving revision 1.265
diff -u -p -r1.265 faq4.html
--- faq/faq4.html	1 Jul 2008 11:01:40 -0000	1.265
+++ faq/faq4.html	30 Sep 2008 01:40:04 -0000
@@ -2541,6 +2541,11 @@ command will do what you need, allowing 
 sector-for-sector.  This would provide the same functionality as
 commercial programs without the cost.
 
+<h3>PXE boot automated installation</h3>
+For architectures which support PXE booting (currently amd64 and i386)
+there is support for
+<a href="faq6.html#PxeInstall">scripted installation</a>
+
 <a name="getdmesg"></a>
 <h2>4.15 - How can I get a dmesg(8) to report an install problem?</h2>
 When <a href="../report.html">reporting a problem</a>, it is critical to
Index: faq/faq6.html
===================================================================
RCS file: /cvs/www/faq/faq6.html,v
retrieving revision 1.269
diff -u -p -r1.269 faq6.html
--- faq/faq6.html	8 Jun 2008 20:36:10 -0000	1.269
+++ faq/faq6.html	30 Sep 2008 01:40:06 -0000
@@ -1504,8 +1504,6 @@ that will permit PXE booting, as well.
 Many ROMs on older NICs support network booting but do NOT support PXE;
 OpenBSD/i386 or amd64 cannot currently be booted across the network by these.
 
-
-
 <p>
 <h3>How does PXE booting work?</h3>
 First, it is wise to understand how <a href="faq14.html#Boot386">OpenBSD
@@ -1594,6 +1592,18 @@ a customized kernel.
 Note that <tt>/etc/boot.conf</tt> is only needed if the kernel you wish to
 boot from is not named <tt>bsd</tt>, or other pxeboot defaults are not 
 as you need them (for example, you wish to use a serial console).
+
+<p>
+In order to support finer grained control over boot parameters in a heterogenous
+environment pxeboot will check the following paths for boot parameters before
+/etc/boot.conf (only the first file found used):
+<ul>
+<li><ul>/etc/boot.conf.<i>x0x1x2x3x4x5</i></ul>, where <i>x0x1x2x3x4x5</i> is the PXE
+interface mac address with colons removed.</li>
+<li><ul>/etc/boot.conf.OpenBSD-<i>mm.n</i>-<i>arch</i></ul>, where <i>mm.n</i> is the 
+OS version and <i>arch</i> is the machine architecture.</li>
+</ul>
+
 You can test your tftpd(8) server using a 
 <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=tftp&amp;sektion=1"
 >tftp(1)</a> client, making sure you can fetch the needed files.
@@ -1649,6 +1659,36 @@ The <a href="faq4.html#bsd.rd">bsd.rd in
 Yes, although with the tools currently in OpenBSD, PXE booting is
 primarily intended for installing the OS.
 
+<a name="PxeInstall"></a>
+<h3>Can I do an automated install using PXE?<h3>
+When the cd version of bsd.rd is booted via PXE
+the script /install.netboot is invoked before any user interaction.
+install.netboot performs the following steps:
+<ul>
+<li>Create a dhclient.conf including a request for option-225.
+<li>Invoke dhclient on the PXE boot interface.
+<li>Extract the value of option-225 from the DHCP lease file as <b>url</b>.
+<li>Attempt to retrieve a script using ftp, trying in order 
+<b>url</b>.<i>x0x1x2x3x4x5</i> where <i>x0x1x2x3x4x5</i> is the boot
+interface mac address with colons removed, 
+<b>url</b>.OpenBSD-<i>mm.n</i>-<i>arch</i> where <i>mm.n</i> is
+the operating system version and <i>arch</i> is the architecture
+(both as returned by uname), and finally <b>url</b> as the full path.
+<li>If it finds a script it saves it to /bootscript, makes it
+executable, and runs it. Only the first script found is executed.
+</ul>
+<p>
+If no script is found due to no option-225 value in the lease
+file or no valid url then install.pxe attempts to clean up by
+deleting the DHCP lease file, deleting the dhclient.conf file,
+running ifconfig down on the boot interface, and finally running
+ifconfig delete on the boot interface.
+<p>
+The custom install script should perform an installation
+and then reboot, otherwise install.netboot will do the cleanup and
+then return control to the default installation script which
+will then sit at the install/upgrade/shell prompt waiting
+for user input.
 
 <a name="CARP"></a>
 <h2>6.11 - The Common Address Redundancy Protocol (CARP)</h2>