I am having some problems to understand your query so I need you to asnwer for me some questions. When you say the BIOS are you referring to the client BIOS or the server one?
Is it possible to configure the software you are using to tell the node what exactly do? I am saying this beause most of the times the PXE is just to deploy Operating Systems and during this process is not possible to access the SATA drive until it starts installing the oS.
Sorry, this fell off my radar for quite a while...
By "the BIOS" I mean the BIOS on the NUC, I am not sure what you mean with the distinction between client and server in this context.
Machines in Emulab are allocated to users who then have "bare metal" access to them. They can do anything to the contents of the hard drive so we cannot assume that the machine will boot from disk after they are done. So we always boot from the network (PXE) to ensure we can regain control of a machine regardless of the state of its disk. A typical lifecycle for a machine is then: PXE boot our custom boot loader which contacts Emulab and is told to load an image on the disk; the boot loader uses TFTP (via the PXE network stack) to load a memory-based re-imaging OS/filesystem; transfer control into that OS which then re-images the disk and performs customizations on it; PXE boot again into the boot loader which is now told to boot from disk; using BIOS calls, load the boot sector from the disk; and transfer control to that code.
So the custom boot loader need to be able to access both the network and the disk in the same invocation. Traditionally, we have used BIOS-provided interfaces to do both, but it appears that does not work on the NUC--we get one or the other depending on what device we booted from.
Again, we have a workaround, I was just curious whether this behavior was expected.