040ee119 error on boot
-
[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?
-
Anybody got any news on this?
-
your latest revision
[quote=“Tom Elliott, post: 27370, member: 7271”]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,[/quote]
seems to work decently well, I still see a number of these errors but I am not stuck waiting 5 minutes anymore.
-
All,
Currently in trunk there are two files dealing with undionly.kpxe.
The first one (undionly.kpxe) is the exact one from revision 1312. Please test this one as a potential fix for now.
If you are able, the second one (undionly.kpxe.INTEL) is a more recent git pull with the “older” intel drivers that I suspect was/is causing the issues we’re seeing presenting us all with this error. I have not seen any errors with this file, but all I have is VirtualBox, and it works perfectly for me.
-
[quote=“Tom Elliott, post: 27420, member: 7271”]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?[/quote]
Hi Tom,
[B]I have tried the following:[/B]
[url]https://mastacontrola.com/undionly_ROM.kpxe[/url]
[url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/undionly.kpxe[/url]
[url]https://sourceforge.net/p/freeghost/code/1312/tree/trunk/packages/tftp/undionly.kpxe?format=raw[/url][B]I will try these two now:[/B]
[url]https://mastacontrola.com/ipxe.kkkpxe[/url]
[url]https://mastacontrola.com/ipxe.kkpxe[/url][B]Is there any more information you can provide for the error(s) you’re seeing?[/B]
I’m getting the 040ee119 error (0x040ee119)[B]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?[/B]
First time trying ipxe with this system, only just created a new server to try out the latest version of FOG. The NIC is the Atheros AR8131The acer TravelMate B113 models in our fleet work flawlessly with iPXE.
My setup is Ubuntu 14.04, Fog 1.0.1 on an Isolated Network.
-
[quote=“DanielR, post: 27537, member: 17896”]Hi Tom,
[B]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?[/B]
First time trying ipxe with this system, only just created a new server to try out the latest version of FOG. The NIC is the Atheros AR8131The acer TravelMate B113 models in our fleet work flawlessly with iPXE.
My setup is Ubuntu 14.04, Fog 1.0.1 on an Isolated Network.[/quote]
The NIC (Atheros AR8131) is referring to your fog server or the client NIC that is failing?
-
[quote=“Tom Elliott, post: 27550, member: 7271”]The NIC (Atheros AR8131) is referring to your fog server or the client NIC that is failing?[/quote]
It is the NIC on the client, not the server. Sorry for the confusion. -
The install/upgrade script fails on CentOS: Starting FOG Multicast Management Server…Failed!
It is possible to start the service manualle by running “service FOGMulticastManager start”. Trying to stop it with “service FOGMulticastManager start” returns an error FAILED.
-
[quote=“pmonstad, post: 27646, member: 17422”]The install/upgrade script fails on CentOS: Starting FOG Multicast Management Server…Failed!
It is possible to start the service manualle by running “service FOGMulticastManager start”. Trying to stop it with “service FOGMulticastManager start” returns an error FAILED.[/quote]
This, by chance, needs to be in a forum by itself. Your message reported here has NOTHING to do with the 040ee119 error.
On the topic of this posting,
I’m already aware of this issue AND how to fix it. Why it’s failing you ask? Because there’s a schema update needed to be performed. The FOG Service files can’t access the database because something needs to direct it where to go. The workaround, for now, is to open a browser to:
[url]http://<FOGSERVERIP>/fog/management[/url] and apply the schema update. Then perform the install script again, it should succeed. The reason why you see a FAILED message with “service FOGMulticastManager [b]stop[/b]” is because it’s not running, even if you get a successful “start” message.
