IPXE vs. PXE
-
I want everyone possible to take notice and make suggestions and point issues in my logic as well.
Thanks to collaboration with Junkhacker, I’m starting to test out iPXE through chainloading so we can have much better success with images.
I’ve already got the base components working, but will be testing over the next couple of days to make sure I get other things ironed out.
What does this mean?
The first thing that comes to my mind is I can use service files to check/test for task creations. This means we can rid the need of 01-XX-XX-XX-XX-XX-XX files being generated/ftp’d to the system. All I have to do is send the MAC address (for now) to the boot file and check if there’s a task for that system in queue, if there is, it would send the task along in the same way the PXE file used to do it. No need for FTP access during task creation. (BIG PLUS IN MY EYES)
The second thing that comes to mind, and probably will wait for the next-next versioning, is we could, basically, get rid of the CAPONE plugins and fully integrate the DMI/Image Associations into the base of fog. Essentially this would create an integrated means of “bypass.gz”.
The third thing that this would allow for is, login verification and sending for the location patch. One way Junkhacker described this helping, and I loved the analogy, was you could think of this as bringing the Location Plugin and giving it a couple pounds of steroids per day. The login verification would be done from the login menu, assigning whomever credentials authenticate, as the person who’s “managing” rather than “creating” the current task process.
There’s many more things this could mean, but understand that I’m still testing out the kinks, so the old PXE System is still available and in use.
-
I hear a FOG 0.33c coming
I like the sounds of this!
-
I’d say it’s more:
FOG 0.33-rc1
-
That sound really good to me. would be awesome if you could implement ipexe into fog. Like u highlighted would open up alot of possibilities.
-
Interestingly enough, I have just, ( this week ), created an IPXE based boot cd/usb, for 0.32, capone only not tasks, and also DELL diags.
What is very noticable is the speed difference downloading bzImage and init.gz, ipxe uses http which is much faster.
The pxe boot config is tiny, it just chains the menu via http.
My wish list for the future would be very much as yours.- move from pxlelinux/tftp to ipxe/http for the initial boot and bZimage and init.gz download.
- pass the mac address, manufacturer, model and asset to the service code, and lookup the image association.
- Add authentication for the http requests.
- use http to initiate the move after uploads.
- If the image download could be moved to http from nfs as well, this would mean that we could go totally http, which would make getting fog to work across a firewall much easier. I’ll set up a test to see how the speed compares.
As a say a wish list, of which IPXE is just the enabler, some of these would have to be long term.
-
Can we get a released stable 0.33b before we start running on too big a project. 0.32 is getting old enough that it doesn’t work on some brand new systems out of the box. maybe this for 0.34
-
VincentJ,
While I understand the prospect of this seems like a huge idea, the method I’m taking currently will allow us more adaptability and compatibility.
Another part of the method of this is it will still, more or less, be the same as the PXE system we currently use, but slightly faster on loading to the systems. The menu I’ve created, while not as “pretty” as the PXE with the background is IDENTICAL to the one we currently have. I will be adding task “on-the-fly” generation and it’s all generated from one file rather than being forced to FTP a file into a directory. I’ve only decided to go to this because it’s faster, simpler to maintain, and removes one component to the task generation areas.
I hope you understand. It, ultimately, will not add much more time on me developing fog as I can basically rely on one script to do all the work I need performed.
-
r1211 released.
With it comes the elements of iPXE.
I haven’t a chance to test all elements, but please test and let me know.
Thank you.
-
Excellent work Tom, thanks.
A minor issue the ipxe menu could do with a longer timeout, or preferably none at all.
A gotcha to avoid. if you are running virtual box and your client hangs downloading bzImage or init.gz, you need to change the network card type to intel. The entry I found suggested that vmware had the problem as well.
I seem to be getting Unmountable boot device on deploy of xp single partition, is the ipxe init.gz the latest version.
Keep up the good work. -
The ipxe menu is defaulted from the FOG Web GUI. So FOG_PXE_MENU_TIMEOUT or whatever it’s called, times 1000 gives you the seconds. So if you want it as a longer timeout, change that on the FOG Web GUI under FOG Configuration->FOG Settings
The init.gz should be the latest version, yes. I have imaged a couple of times today just to make sure all was working properly.
-
Great work Tom, iPXE is certainly the way to go for future.
Only one thing I would ask and this relates to the previous way of doing it.
I use the old 01-XX-XX-XX-XX-XX-XX method and manually create some of those files for use by Thin Clients (that boot across the network and are diskless) and ESXi AutoDeploy hosts
Would it be possible using iPXE to still achieve this?
I imagine it would be a feature request, however it would require the ability to create a permanent task for a specific MAC address or group of MAC addresses with custom parameters.
-
depending on what exactly you’re doing with those manually created pxelinux config files and how much they interact with fog, at this point there is nothing stopping you from keeping doing what you’re currently doing. just keep using pxelinux and your 01-XX-XX-XX-XX-XX-XX files, but in your default file chainload to undionly.kpxe
-
Or if you know the macs of the systems just add a simple if statement and perform the task right from ipxe.
