HP 8300 Elite All-in-One with Intel 82579LM iPXE loading problem
-
Hello all
I am having a problem with iPXE and a specific model of machine and Ethernet adaptor: HP 8300 Elite All-in-One (AIO) with the Intel 82579LM Gigabit Ethernet Controller (Intel Boot Manager v1.3.81)
[U]My system specs are: [/U]
[LIST]
[]Ubuntu 12.04 LTS 64bit, fresh install, updated
[]FOG 1.1.1, fresh install
[*]Windows 2008 R2 DHCP server (option 66 set as FOG server IP)
[/LIST][U]The problem:[/U]
This model and Ethernet adaptor combination gets a DHCP address, gets and iPXE entry point, but hangs at “iPXE initialising devices….” The machine then hangs and must be hard powered off.
[IMG]http://i60.tinypic.com/2vbvkw4.jpg[/IMG][U]So far, my observations are:[/U]
[LIST]
[]iPXE (and then the FOG menu) works fine on seven other HP model laptops/desktops we have, 3 of which also have the Intel 82579LM
[]The other working models with the 82579LM have a different version of the ‘Intel Boot Manager’ (v1.3.63, v1.3.95, 1.3.72)
[/LIST]
[LIST]
[]The HP 8300 boot fine on my existing FOG 0.32 setup, on the same VLAN and DHCP (just pointing to my existing 0.32 server)
[]The Apache and server logs don’t indicate anything untoward
[/LIST][U]Things I have tried:[/U]
[LIST]
[]Reading the forums and Googling until my eyes bleed
[]Put the test HP 8300 machines into their own VLAN when I can control the boot file name (Windows DHCP option 67)
[]Tried utilising all Tom Elliot’s suggested files (ipxe.pxe, ipxe.kpxe, ipxe.kkpxe, undionly.pxe, undionly.kpxe, undionly.kkpxe)
[]Tried numerous other iPXE files from around the internet: no change
[]Tried a different VLAN, just in case there is a problem coming for DHCP: no change
[]Rebooted DHCP server and FOG server
[]Updated the BIOS on the test HP 8300 machines: no change
[]Made sure legacy boot is ON and secure boot is OFF in the BIOS boot settings
[]Attempted to update the 82579LM network boot ROM, thinking that the particular version of the ‘Intel Boot Manager (v1.3.81)’ may be to blame but then found out this is not possible with the ‘on board’ versions of the adaptor
[]Created a bootable iPXE CD to test with: boots from CD OK, but no change, still hangs at the same place
[]Built my own iPXE files using this process ([url]http://www.fogproject.org/wiki/index.php/Building_undionly.kpxe[/url]
but no change
[]Tried adding different versions of the e1000e driver (v2.3.2 | v2.5.4 | v3.0.4)
[]I am not sure I totally understand the iPXE build process, so maybe not doing it correctly!
[]Tried to chain loading iPXE from pxelinux.0 using this process ([url]http://www.fogproject.org/wiki/index.php/Chainloading_PXE_to_iPXE_using_pxelinux.0[/url]) but again, I don’t think I totally understand what it going on here, so wasn’t a help yet
[/LIST]I love the new v1.1.1 and the new features it brings, but I’m being held back from implementing to production cause of this one painful buggy machine! If I didn’t have 400 of them, I‘d work around this…
[IMG]http://i59.tinypic.com/mt5jb6.jpg[/IMG]
I am aware that this doesn’t appear to be a FOG problem, but is an iPXE problem, but does anyone have suggestions or pointers as to where I can go from here?Also, I apologise in advance if this has been answered elsewhere, but I am research and reading weary…
Thank you.
William
[url=“/_imported_xf_attachments/1/1061_error.txt?:”]error.txt[/url][url=“/_imported_xf_attachments/1/1062_foginstall.txt?:”]foginstall.txt[/url]
-
Have you tried to Undionly.kpxe.INTEL version yet? Normally we would recommend this if it was flashing an error, but to me it seems it never get far enough to error out. I am curious to figure out why.
Thanks for all your documentation on your troubleshooting steps, it really helps to visualize what is going on.
You could run this code, you are welcome to change the first line it is simply renaming your current undionly.kpxe we want to keep it since the rest of your network seems to like the file. This is a different version of the boot file and may help with resolution.
[code]
sudo mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe.6.25
wget -O /tftpboot/undionly.kpxe http://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/undionly.kpxe.INTEL[/code] -
[quote=“Jaymes Driver, post: 31265, member: 3582”]Have you tried to Undionly.kpxe.INTEL version yet? Normally we would recommend this if it was flashing an error, but to me it seems it never get far enough to error out. I am curious to figure out why.[/quote]
Sorry, I omitted that one in my original post. Yes, I tried that one first and again just now to make sure, but the same problem.
[quote=“Jaymes Driver, post: 31265, member: 3582”]Thanks for all your documentation on your troubleshooting steps, it really help sot visualize what is going on.
[/quote]
Thank you for your reply and help! -
SUCCESS! Well sort of…
What I have now is a fully [U]functioning[/U] boot menu for all hardware types, including the troublesome HP 8300 above, BUT it is not pretty! The menu is all there and I can register a host, run memtest, boot thru to hard disk etc, but it doesn’t have any formatting and images. I suspect that has to do with where I’ve got up to below…
[IMG]http://s15.postimg.org/5yygciuzv/IMG_20140627_121528.jpg[/IMG]
After more reading, trial and error and failing, I decided to go back to attempting another [COLOR=#0000ff]undionly.kpxe[/COLOR] build from scratch.
I downloaded the iPXE Git and started again using [URL=‘http://www.fogproject.org/wiki/index.php/Building_undionly.kpxe’]this process[/URL] as I did above, except this time, I only edited the [COLOR=#0000ff]ipxescript[/COLOR] file: I didn’t change the [COLOR=#0000ff]general.h[/COLOR], [COLOR=#0000ff]console.h[/COLOR] or [COLOR=#0000ff]settings.h[/COLOR] files before building. I ran make and copied the reuslting files to /tftpboot and voila! The painful 8300 boots and gets to the above working, but ugly FOG boot menu!
The line that causes the HP 8300 Elite All in One with the 82579LM NIC to freeze is line 145 of [COLOR=#339966][COLOR=#0000ff]general.h[/COLOR][/COLOR]
[COLOR=#000000][CODE]#define IMAGE_TRUST_CMD /* Image trust management commands */[/CODE][/COLOR]
[COLOR=#339966][COLOR=#008000][COLOR=#000000]If I comment out this line and rebuild, the 8300 boots OK. Leave it un-commented, and the 8300 hangs as in my first post.[/COLOR][/COLOR][/COLOR][COLOR=#339966][COLOR=#008000][COLOR=#000000]The contents of my working [COLOR=#0000ff]ipxescript[/COLOR] file are:[/COLOR][/COLOR][/COLOR]
[CODE]#!ipxe
sync --timeout 500
dhcp || reboot
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://10.0.115.43/fog/service/ipxe/boot.php##params[/CODE]This is a combination of the lines recommened on the Wiki how to page, what’s is in [COLOR=#0000ff]default.ipxe[COLOR=#000000] and another I have seen around the 'net. So far, changes in this file make no difference to the outcome of the build.[/COLOR][/COLOR]
[COLOR=#0000ff][COLOR=#000000]So what does this all mean? I hoping a one of the developers can explain, becuase it’s getting over my head! It may also need to be something to take over to the iPXE forums…[/COLOR][/COLOR]
-
SUCCESS!! Again…
OK, I feel a little silly about the ugly menu above now. Becuase I didn’t initially edit any of the config files before doing a build, some settings were left out. I realized, as soon as I opened up [COLOR=#0000ff]console.h[COLOR=#000000] that line 25 was still commented out:[/COLOR][/COLOR]
[CODE]#define CONSOLE_VESAFB /* VESA framebuffer console */[/CODE]
[COLOR=#0000ff][COLOR=#000000]meaning the vesa console menu wouldn’t be able to load properly, hence my ugly menu above. Kinda reminds me of the ol’ DOS days…[/COLOR][/COLOR]
[COLOR=#0000ff][COLOR=#000000][/COLOR][/COLOR]
[COLOR=#0000ff][COLOR=#000000][IMG]http://s14.postimg.org/xmgtc0wht/IMG_20140627_145833.jpg[/IMG][/COLOR][/COLOR][COLOR=#0000ff][COLOR=#000000]Now I have functioning AND pretty FOG menu! I’m now going to set up a storage node at each of our campuses (seperated by a WAN link) for imaging at both locations from the one main FOG server.[/COLOR][/COLOR]
[COLOR=#000000]I hope these posts help someone else around the 'net in the future.[/COLOR]
[COLOR=#0000ff][COLOR=#000000]Thanks again FOG![/COLOR][/COLOR]
-
Okay, I’ll rebuild with image_trust_cmd, maybe we’ll see more success with others?
-
Just to confirm: it’s IMAGE_TRUST_CMD commented out.
It’s worth a try, even as a test for others with trouble with similar model Intel NICs. I’m at home at the moment, but I’ll post my iPXE config files / undionly.kpxe next week.
FOG menu appears to all be working OK, but I haven’t got the storage node up yet to test an upload and download of images yet. I’m worried that this definition might be doing something else that is broken by leaving it out.
I’ll test an uploads/downloads next week and report back.
Thanks for your reply, Tom.
-
The IMAGE_TRUST_CMD is not referring to “images” in the sense of FOG, but rather literal “images” such as Pictures. So having it or not having it shouldn’t really matter.
They are rebuilt in SVN Trunk:
[url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/[/url] -
[quote=“Tom Elliott, post: 31637, member: 7271”]The IMAGE_TRUST_CMD is not referring to “images” in the sense of FOG, but rather literal “images” such as Pictures. So having it or not having it shouldn’t really matter.[/quote]
Ah OK. That’s all good then.
[quote=“Tom Elliott, post: 31637, member: 7271”]They are rebuilt in SVN Trunk:
[url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/[/url][/quote]That’s awesome, Tom. We love FOG here at our School (and so does my brother at his School) and I’m glad I’ve been able to contribute.
