Fog Advanced Menu ISO Booting
-
Hey guys, I’ve searched the forums both with the search feature here and by using a google boolean search and read just about every thread I could find about this issue. I want to see if there is some kind of update on this or a workaround.
The issue is this, I have successfully setup an advanced boot menu it works fine
initrd http://${fog-ip}/fog/iso/acronis_true_image_2014.iso
chain memdisk iso raw ||
goto MENU[/CODE]That is the entry I am using to load Acronis’s Boot Disc. The problem is that when I load this ISO, it says loading from HTTP on the top of the screen with a percentage indicator but the download itself takes way longer than it should. The Acronis image is about 500mb and it takes almost 2 minutes to load the ISO into RAM before running it. On another computer if I just browse to [url]http://fogipaddress/fog/iso[/url] and download the same ISO it downloads in 3 seconds consistently. Why is the download taking SO much longer with the advanced boot menu, especially considering I can image a device with an 8gb Windows 7 image and transfer with ipxe at 7gb/min.
This is not a network issue, something isn’t configured right or ipxe is showing it downloading via HTTP but its actually reverted to TFTP or something.
Any insight? Where I can look?
-
Maybe try here?
[url]http://forum.ipxe.org/showthread.php?tid=7061[/url]
Also maybe try kernel memdisk ISO over chain as, if I’m reading the chain right, chain does two actions but after the item befor it has completed. So maybe try
[code]
:ACRONIS
kernel memdisk iso raw
initrd http://${fog-ip}/fog/iso/acronis_true_image_2014.iso
boot ||
goto MENU[/code] -
Also,
Another option to try as I’m re-reading other reference materials.
Maybe:
[code]chain memdisk iso raw[/code]
Is this the issue? I think it is as it’s, from what I can tell, attempting to load memdisk from tftp, therefore trying to download the iso file under tftp methodologies.
What if you try chaining the chain line to:
[code]chain http://${fog-ip}/fog/service/ipxe/memdisk raw iso[/code] -
I just tried both suggestions and the download rate remained the same.
I checked to make sure KeepAlive was enabled for Apache and it is. The only other thing I have found is [URL=‘http://lists.ipxe.org/pipermail/ipxe-devel/2013-October/002864.html’]this[/URL] where httpd isn’t sending content-length header and that would make for very slow ipxe http downloads. The only thing that isn’t making sense to me here is the fact that just browsing the apache directory and downloading in an internet browser maxes out the link speed, imaging a computer maxes out the link speed, but ONLY when trying to download an ISO to boot from RAM is the download significantly slower.
-
Alright,
Can you try, just for these scenarios, using the ipxe.pxe file as your undionly.kpxe?
See if this helps you out at all?
It will likely break other systems, but this is just to test a theory i’m running through my head.
-
That’s the issue man, you figured it out. Once I switched to ipxe.pxe the ISO booted in 3 seconds, damn near instantaneous.
-
Any ideas as to what the difference is between the two pxe boot files that would cause this? Would it be something as simple as changing the setting that differs between the two and then recompiling a new undionly.kpxe for use in FOG?
-
No.
I’m currently in the works of trying to come up with a decent solution for a couple of reasons.
ipxe.pxe is the “preferred” method of booting ipxe. However it rely’s on the native ipxe driver code for each of the nics of which they do not have all drivers for all nics.
undionly.kpxe is the method we use because I don’t have a clue what type of hardware is going to be trying to boot. It was easier to make a decision to start with something that, usually, works for nearly all systems. Undionly.kpxe uses the nic’s undi driver which is a “generic” driver built into the nic’s firmware.
undionly.kkpxe is similar to undionly.kpxe but really only used for those bios’ that have buggy firmware built in causing other issues that I can’t, and ipxe itself can’t, predict. It seems to work on most buggy systems where undionly.kpxe seems to fail.
If you want, you could try booting using the undionly.kkpxe but something leads me to think it’s the nic’s undi stack limiting your connection. We were really just “lucky” that the ipxe.pxe had the nic’s driver which was what my “theoretical” thoughts where.
Hopefully this helps explain that.
-
That explained it very well thank you
-
Any progress on this?
the ipxe.pxe boot file, how limited is it in terms of the builtin NIC drivers it has? Is it random? Is it safe to assume devices made in the past 2-3-4-5-6 years should all work and undionly.kpxe is to ensure compatability for all devices including legacy older models?
I’m trying to determine how likely I am to run into issues ditching undionly.kpxe if all the computers on my network were made within the last 3 years.
Is a fix/patch in the works and just wait?
-
ipxe does not give time frames for patches or upgrades.
If you want to know if ipxe will work for your machines, try changing your dhcp option 67 to ipxe.pxe and see if your systems work.
You can try searching ipxe’s forum for a supported hardware list and compare your nics to their list.
-
Nice. that fixed my problem hahaha. thanks
old code :
:winpe initrd http://${fog-ip}/iso/ampe.iso chain memdisk iso raw || goto MENUOld code
:winpe kernel memdisk iso raw initrd http://${fog-ip}/fog/iso/ampe.iso boot || goto MENUNow sure what it change. but its working !
