040ee119 error on boot
-
All,
I may have found a fix, thanks in great part to those understanding it was timing, not a pxe problem itself.
I worked most of my evening trying to get this figured out by playing with the source files. However, it was so simple and I’m sorry I missed it. Thank you Junkhacker for the code piece to help me.
This seems to fix the issue with Virtualbox as well, though I wasn’t seeing the reported issues on hardware boxes. I’m almost certain this will fix the issue.
I retagged the svn 1.0.1 branch to contain this fix.
For those experiencing this problem, please use the following command as the root user on your FOG Server.
[code]mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe.BROKEN
wget http://svn.code.sf.net/p/freeghost/code/tags/1.0.1/packages/tftp/undionly.kpxe -O /tftpboot/undionly.kpxe[/code]Please let me know of any other issues as you encounter them.
Thank you,
-
Still getting the 040ee119 error.
Client:
[img]http://puu.sh/8MNgz/a6a0bc919b.jpg[/img]DHCP Options:
[img]http://puu.sh/8MNjs/792c153ef0.png[/img]Device details:
[img]http://puu.sh/8MNoB/15faf53b54.png[/img]Using 0.32 works fine (pxelinux.0) but once I switched to 0.33B & 1.0.0 & 1.0.1 & This Patch I still have this issue.
-
Hello all,
Short time lurker, first time poster.
I am getting this error as well in only one of my companies sites but not the others. The suggested fix does not however solve the issue.
-
Hey, Tom. Just wanted to let you know that this DID fix the issue for me. The error appears a couple of times but doesn’t immediately boot me out. I guess the dhcp process now has time to finish and the computers are booting. Nice work!
-
[quote=“Tyler Coles, post: 27188, member: 24184”]Hey, Tom. Just wanted to let you know that this DID fix the issue for me. The error appears a couple of times but doesn’t immediately boot me out. I guess the dhcp process now has time to finish and the computers are booting. Nice work![/quote]
With the 0x040ee119 error looping until the iPXE gets a renewed address is not a good fix. Now if you line up 30 computers at once it will be random on which comes up first, instead of guaranteeing on first try.
I had sometime to test on a lab…yes 30 computers at once. I rebooted them all at once (Deepfreeze
) and I watched them closely. It was to the point that each computer would randomly get to the “Fog Menu”. Sometimes on the first try for iPXE sometimes on maybe the 7th. I had two that just finally looped until almost 20 times, then I shut them down myself and rebooted. Then these last two got to the “FOG Menu” on the first try. This was not an issue with pxelinux.0, nor with undionly.kpxe for fog 0.33b but in the upgrade to 1.0.0 and 1.0.1 this issue continues. This is on both physical Desktops/laptops and VM’s.[I] I’m leaning towards and environmental issue.[/I] Maybe something wrong with my switches or my DHCP. DHCP is handing out addresses on a live network, so don’t ask if its working. Still exploring all possibilities.FYI:
Cisco switches ENABALE portfast (otherwise PXE/iPXE will not work)
Netgear DISABLE STP (otherwise iPXE will not work) -
I also got the repeating 0x040ee119 error after applying this fix. I assumed it would just keep repeating indefinitely, so I left it just to see. About 5 minutes later I walked over to the computer and luckly saw it just loading into the FOG menu, where I told it to do full inventory and registration. Then, I got the following errors:
[url=“/_imported_xf_attachments/0/772_FOG errors.JPG?:”]FOG errors.JPG[/url]
-
I’m hoping to have made some headway on this issue.
It seems, to me, that ipxe.kpxe may be more appropriate for our needs (for these scenarios) rather than the use of undionly.kpxe.
I was doing a lot of research, for most of this morning (as well as last night) and while it seems the sync --timeout 500 has helped more in some cases, there is still a lot of this issue occurring in general.
So what this lead to was me trying many, many, many different configuration changes and when none of those seemed to help (as I can forcibly replicate on my Virtual Box systems) I thought, hey, let’s just try rom-o-matic’s undionly file. Well, that was a no-go because the undionly.kpxe they provide is under the standard configuration which doesn’t allow us to get some of the commands and required elements for our needs (e.g. login, console, frame_buffer, params, etc…) Which means it doesn’t work. The only place to get those files is from the advanced menu option which removes the ability to use undionly.kpxe. Why? Probably the nifty little feature where you can specify which drivers you need.
So I created the config based on what we were using and downloaded it. I tested and everything worked perfectly within VirtualBox. I must specify, this is only, seemingly, working well on VirtualBox. I don’t have all the systems you all do, so please give this file a shot.
[code]mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe.KINDAWORKINGMAYBE
wget -O /tftpboot/undionly.kpxe --no-check-certificate https://mastacontrola.com/ipxe.kpxe[/code]I hope this helps out a majority of the issues, but there’s not guarantee.
-
[quote=“Tom Elliott, post: 27205, member: 7271”]I’m hoping to have made some headway on this issue.
It seems, to me, that ipxe.kpxe may be more appropriate for our needs (for these scenarios) rather than the use of undionly.kpxe.
I was doing a lot of research, for most of this morning (as well as last night) and while it seems the sync --timeout 500 has helped more in some cases, there is still a lot of this issue occurring in general.
So what this lead to was me trying many, many, many different configuration changes and when none of those seemed to help (as I can forcibly replicate on my Virtual Box systems) I thought, hey, let’s just try rom-o-matic’s undionly file. Well, that was a no-go because the undionly.kpxe they provide is under the standard configuration which doesn’t allow us to get some of the commands and required elements for our needs (e.g. login, console, frame_buffer, params, etc…) Which means it doesn’t work. The only place to get those files is from the advanced menu option which removes the ability to use undionly.kpxe. Why? Probably the nifty little feature where you can specify which drivers you need.
So I created the config based on what we were using and downloaded it. I tested and everything worked perfectly within VirtualBox. I must specify, this is only, seemingly, working well on VirtualBox. I don’t have all the systems you all do, so please give this file a shot.
[code]mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe.KINDAWORKINGMAYBE
wget -O /tftpboot/undionly.kpxe --no-check-certificate https://mastacontrola.com/ipxe.kpxe[/code]I hope this helps out a majority of the issues, but there’s not guarantee.[/quote]
To add on to this, if this fixes some of your systems, but you’re still seeing issues on others, please try:
-
[quote=“Tom Elliott, post: 27209, member: 7271”]To add on to this, if this fixes some of your systems, but you’re still seeing issues on others, please try:
[url]https://mastacontrola.com/ipxe.kkpxe[/url][/quote]
I’ve, essentially, recreated the infamous ipxelinux.0 file. Please try this as well if you all can?
-
Hi Tom,
I’ve tried all the files you have posted here to no avail. Any suggestions?
-
Hi, that fix worked for me…
Now to figure out how to use this thing, first day trying it… imaging damn slow asus eeepc’s
cheers, Craig
-
How long are you letting the system go on it’s retry before all is failing? I know what the issue is, and have made all attempts I can think of. For most, it appears to be DHCPDISCOVER is the place where it’s failing. This is where’s it’s going out to the DHCP Server to Discover an IP. I am planning to post to the forums, and you all can help.
All I have to test this issue with (which I can fix with ipxe.pxe, ipxe.kpxe, and ipxe.kkkpxe) is VirtualBox VM’s. I can reproduce the error and “fix” the error now on my Virtual Box Machines. So I have a starting point on my side.
One trend that I’m seeing this happen every too often is a specific Manufacturer. This manufacturer appears to be Lenovo in quite a few cases. The next are Dell (probably a specific model) and Asus.
Try to limit environmental variables as much as possible.
-
Best case, if you can do it, install DHCP server on the installation of FOG and connect system either with an unmanaged switch or VIA crossover cable. If you’ve already installed it, you can change the DHCP status of .fogsettings, though a fresh install would be highly recommended in this scenario to ensure OS is clean as well as the install.
-
Check all networking switches that can be managed have portfast enabled (cisco) and/or *STP Spanning Tree Protocol) are disabled on the switch. The and/or meaning with Cisco, portfast should be all that’s needed, but turn off Spanning Tree Protocol if you can just to ensure this is NOT a factor in blocking the DHCP from iPXE.
My guess is that it’s not specific to the manufacturer, but rather the drivers iPXE is using. So if you know it please post with the following information:
Manufacturer
Model
BIOS/Firmware Version for that model.
Chipset on NIC (Realtek 8168/9, Atheros, Intel, Broadcom, etc…)Hopefully we can hear back on an answer. Something changed and I don’t know what it was. For a good while, all seemed fine, then release happened and I’ve been banging my head over this for the last few days.
I hope you all are still with FOG and not getting too frustrated. I am frustrated enough, I don’t need you all worrying over this too.
-
-
Hmmm…so I downloaded the undionly.kpxe directly from ipxe.org and threw it up on my /tftpboot folder. Renamed it to wolf.kpxe and changed my dhcp 67 to wolf.kpxe. I embedded nothing. Guess what error message I get for most of my machines?
0x040ee119
So there is nothing wrong with your embeded scripts! its all ipxe
The infamous pxelinux.0 may need to come out of retirement.
-
One more try everybody:
[url]https://mastacontrola.com/undionly_ROM.kpxe[/url]
Please try it, hopefully more success?
-
FOR ME I get these results with undionly_ROM.kpxe
Attempt(s) ==> Configuring (net0 xx:xx:xx:xx) …
After: Initializing …ok ==> different machines show a bit of a different output
Dell D610’s, Dell D630’s, HP DC5700’s read:
Waiting for linkup …ok
Configuring (net0 xx:xx:xx:xx) …Dell E6410’s and HP DC7800 read:
Configuring (net0 xx:xx:xx:xx) …[B]Round 1: (1st boot)[/B]
VM --> over 20 attempt(s) didn’t get to the “Fog Menu”
Dell D610 --> 1 attempt(s) to get to “Fog Menu”
Dell D630 --> 2 attempt(s) to get to “Fog Menu”
Dell E6410 --> 1 attempt(s) to get to “Fog Menu”
HP DC5700 --> 1 attempt(s) to get to “Fog Menu”
HP DC7800 --> 1 attempt(s) to get to “Fog Menu”[B]Round 2: (2nd boot)[/B]
VM --> over 20 attempt(s) didn’t get to the “Fog Menu”
Dell D610 --> 3 attempt(s) to get to “Fog Menu”
Dell D630 --> 1 attempt(s) to get to “Fog Menu”
Dell E6410 --> 7 attempt(s) to get to “Fog Menu”
HP DC5700 --> 1 attempt(s) to get to “Fog Menu”
HP DC7800 --> 5 attempt(s) to get to “Fog Menu” -
All,
It seems there may be two options available. Until I can get a solid fix for things with ipxe, please try:
[url]https://mastacontrola.com/ipxe.pxe[/url] in place of undionly.kpxe This may not work on all systems, but should work on newer and medium aged systems.
If that doesn’t work, please give a go with this command:
[code]wget -O /tftpboot/undionly.kpxe https://sourceforge.net/p/freeghost/code/1312/tree/trunk/packages/tftp/undionly.kpxe?format=raw[/code]
This one is from svn revision 1312 and seems to work on numerous systems. I have issues with VirtualBox, but that’s fine if our “real” systems work in a more consistent manner.
Hopefully this makes sense until I can get information from ipxe devs.
-
undionly.kpxe–r1312 --> GOLD STAR!..at least on all my machines
-
One for go, while the above link should help out all those having issues: if you’re daring enough, please give a try to svn rev 1704.
I’m working on a theory right now, so I understand the hesitation:
Please try the file in rev 1312 with the commands as above and let us know if this is working for you.
Then, if you can, please try the latest undionly.kpxe as well:
[code]wget -O /tftpboot/undionly.kpxe https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/undionly.kpxe[/code]
I’m trying something out and am in hope that this one will also receive a gold star.
Thank you,
-
Having the same issue with one type of laptop in our fleet. The acer aspire 1830T
I have tried every single file mentioned in this thread without success. Did you have any luck Justin P?
-
[quote=“DanielR, post: 27398, member: 17896”]Having the same issue with one type of laptop in our fleet. The acer aspire 1830T
I have tried every single file mentioned in this thread without success. Did you have any luck Justin P?[/quote]
Can you be more specific on which files you’ve used? I’ve got quite a few for testing and would just like to know which you’ve tried.
For example, have you tried the undionly.kpxe in [url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/undionly.kpxe?[/url]
Have you tried the undionly.kpxe from revision 1312? Which can be found with the command:
[code]wget -O /tftpboot/undionly.kpxe https://sourceforge.net/p/freeghost/code/1312/tree/trunk/packages/tftp/undionly.kpxe?format=raw[/code]Is there any more information you can provide for the error(s) you’re seeing?
What I mean by this, are you getting the 040ee119 error or some other message?Are you getting this message on multiple systems or just this Acer? What’s the NIC on that system? Has ipxe ever worked for this system?