<div dir="ltr">You can look at <a href="http://xcat.sf.net">xcat.sf.net</a>. xCAT does diskless clients for centos, suse, and others. It boots things mostly into ramdisk. Has some complicated options to balance persistence versus stateless, memory usage versus nfs access, etc.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 10:42 AM, Richard Hornbaker <span dir="ltr"><<a href="mailto:Richard@hornbaker.com" target="_blank">Richard@hornbaker.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Robin.<br>
<br>
Thanks for the pointers. I left out what's probably an essential detail in my explanation...<br>
<br>
The goal is for a node to operate independently once it's booted, rather than continue to use the NFS mounted OS image. What I'm striving for is a combination of the NFS model you mention, but with a local RAMdisk for the OS filesystem as done with the ISO method.<br>
<br>
My gut says this is possible, just unusual for an NFS setup. Conceptually, I think what I want is the process used by ISO (where the source is copied to a RAMdisk, then booted), just using an NFS source instead of an ISO image in RAM. I just don't understand enough about the boot loader and kernel processes to hack it out.<br>
<br>
The preference for simplicity & speed (I think) is to copy / boot a pre-built OS image, rather than launch an installer. Pretty much exactly what I see with NFS-based diskless examples, but adding a step to copy the filesystem to a local RAMdisk and boot from there.<br>
<br>
Is it possible to spec this during the boot process, or... Is it possible to relocate the filesystem root after Linux boots? If so, maybe a solution is to create the RAMdisk during OS boot, copy the filesystem there from NFS, and point the local filesystem root to the RAMdisk? (I'm pushing the bounds of my OS skills here, so don't laugh.) The only drawback there is pulling the same content twice - once to boot, and again to create the RAMdisk.<br>
<br>
The torrent idea is blue sky at the moment, and not a requirement. I agree it'll require some work at the DHCP server to dynamically steer booting nodes to different sources.<br>
<br>
As for the hardware validation tools, I haven't dug into their details yet - they're being used today under Linux, but manually and with no data logging or orchestration which were hoping to add here. I'll explore your comments about memtest86 to see if we might add something more thorough there.<br>
<br>
Thanks!<br>
Richard<br>
<br>
<br>
Sent from a mobile device - pardon the typos!<br>
<div class="HOEnZb"><div class="h5"><br>
On Dec 4, 2013, at 1:54, Robin Smidsrød <<a href="mailto:robin@smidsrod.no">robin@smidsrod.no</a>> wrote:<br>
<br>
> On 03.12.2013 18:05, Richard Hornbaker wrote:<br>
>> I could use some pointers on a concept I'm chasing. The idea is a diskless boot for CentOS, but using NFS or HTTP sources instead of ISO.<br>
><br>
> Couldn't you use the tried and true NFS root method that has been<br>
> available for years and years? Go to <a href="http://tldp.org" target="_blank">tldp.org</a> and search for "NFS root"<br>
> and you'll find several HOWTOs. Not sure how well they work with current<br>
> distros, but I'm going to assume it hasn't changed that much.<br>
><br>
>> I've found examples of ISO diskless boot, and NFS/HTTP installers, but not NFS/HTTP diskless boot.<br>
><br>
> I've got Ubuntu Live (casper) booting over NFS in my example menu (see<br>
> <a href="http://ipxe.org/examples" target="_blank">http://ipxe.org/examples</a>), but I'm guessing you don't want to boot a<br>
> live system, but something installed, right?<br>
><br>
>> * Easily modified boot files. I need to hand this off to customers, and using NFS or HTTP sources make this very easy compared to ISO. If folks need to change files, I'd like them to be able to just modify them in the boot server's filesystem.<br>
><br>
> Should be no problem. Change the file on the NFS server and you're done.<br>
> Reboot if required.<br>
><br>
>> * Upon boot, each node would operate like a torrent server, becoming an additional boot source and serving up its filesystem as source for other booting nodes. Another reason for it to be filesystem-based and not ISO-based.<br>
><br>
> Well. That would probably require some form of orchestration and<br>
> clustering support tool. My guess you'd need to script a reasonable<br>
> amount of stuff to set up each node automatically. My favorite is<br>
> currently SaltStack.org.<br>
><br>
>> If push came to shove, I could tolerate the duplicate RAM consumption with an ISO boot if the ISO could be accessed and served up by the node once booted. But this image is for hardware verification (incl. RAM tests), so a small footprint is preferred.<br>
><br>
> If you've already booted Linux you can't run tools like memtest86+.<br>
> Those would have to be part of what you do before you boot your kernel.<br>
> My guess is that you might find some use in PuppetLabs Razor product. It<br>
> has a microkernel that does inventory and a way to boot a node in<br>
> verification mode (for memory tests and such) before it is put into<br>
> production. Not sure exactly how it all works. Just copying what I've heard.<br>
><br>
>> I haven't had a lot of success booting from HTTP or NFS in a diskless scenario, only ISO. Any pointers? Maybe to folks who've done this before?<br>
><br>
> Boot a kernel + initrd (use either NFS or HTTP protocol, or even TFTP,<br>
> doesn't matter), specify kernel options to mount the nfs root system,<br>
> that should be it.<br>
><br>
> Also browse <a href="http://forum.ipxe.org" target="_blank">forum.ipxe.org</a>. You might find some useful information in<br>
> the archives there.<br>
><br>
> -- Robin<br>
> _______________________________________________<br>
> ipxe-devel mailing list<br>
> <a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a><br>
> <a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel" target="_blank">https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel</a><br>
><br>
_______________________________________________<br>
ipxe-devel mailing list<br>
<a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a><br>
<a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel" target="_blank">https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel</a><br>
</div></div></blockquote></div><br></div>