@ntex
Nevermind, I’m too tired clearly, fixed the original configuration has another prefix= to empty.
So this line was creating a conflict with one above.
Time to rest for today. long day, thanks anyways!!
@ntex
Nevermind, I’m too tired clearly, fixed the original configuration has another prefix= to empty.
So this line was creating a conflict with one above.
Time to rest for today. long day, thanks anyways!!
Hi,
Read some topics on this:
Using FOG to PXE boot into your favorite installer images
iPXE Setup For Many OS’s Under BIOS and UEFI
Booting VMware ESXi in iPXE
But I’m dealing with weird error, I decided to use HTTP after NFS not working, but it’s not this either probably:
kernel http://${fog-ip}/os/esxi/6.7u3/efi/boot/bootx64.efi -c http://${fog-ip}/os/esxi/6.7u3/efi/boot/boot.cfg
What I don’t understand is if I set prefix to:
prefix=http://10.200.0.67/os/esxi/6.7u3/
Why after booting into ESXi installer the path changes to path used on menu for Boot Installer files ?
http://10.200.0.67/os/esxi/6.7u3/efi/boot
Thanks in advance for any suggestions.
Awesome!
BTW, little off-topic do you know why I had issues initially to upload on forum?
Was due to the fact fresh user account and low reputation?
Now I tested seems fine.
@george1421 said in Proliant ML110G7:
@NTex Good going. Now I did work on a project to turn a Windows server into a FOG storage node. Once I proved that it worked I dropped the project because, why?? I have it documented here: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog
I realize this is a one off situation but if you need it then use it. But I think the fragmentation or what ever is going on with your MPLS circuit will be a problem when you get to the imaging point because FOG uses NFS to transfer the file from the FOG server to FOS Linux running on the target computer. Having a storage node at the remote sites might be the better solution if you can’t image over your WAN connection.
So it might be the actual MTU and fragmentation, probably just happens for this old NIC and on these locations, who knows.
Come to think about it, theses sites are kind located more on country side, far from big cities, where usually ISP have more issues like this due to distance / infrastructure, etc.
Working Server, one of those I didn’t had issues, capture file
Has no fragmentation, right ?
I mean you see loading it fine here:
I think (at least I) learned something, MTU can cause issues like this.
I wish I would had this idea sooner, using another workstation with portable TFTP Server while keeping the same DHCP, just had to change Option 66 to point to the Workstation.
I actually copied ALL the PXE files from our Fog.
I can use this workaround for 4 locations, and saved us couple thousand miles of driving and replace the servers physically, at least for now.
Nevertheless, I will keep your special version that you compiled for me.
Brainstorming this puzzle with you was a pleasure, thanks for all the help you gave and support, truly awesome. @george1421
@george1421 said in Proliant ML110G7:
@NTex Ok here is a “special” version of undionly.kpxe https://drive.google.com/file/d/1XYe4SsM0ZLiJae1paIb8PFDnPVV0M3D7/view?usp=sharing
Once loaded it will ignore any direction given by dhcp and request default.ipxe from 10.200.0.67 over the tftp protocol. Once that file is loaded it will then switch to http.
Well now that I think about it, the default undionly.kpxe would work too (ugh) as long as you bring over default.ipxe to your tftpd64 server too. THAT file points directly at your FOG server. I didn’t think far enough ahead in the process. That makes this special undonly.kpxe not that special.
Yes, you’re right
While you were compiling your project, I did this:
Copied the portable tftp64.
Then I copied ALL files from Fog Server located at /tftpboot.
I saw the boot file being loaded, immediately
I captured the event using local tftpd nevertheless, if you want to look at it
Capture using local tftpd
Once Fog Menu loaded, I selected my “Install CentOS” option and it’s loading:
Still I download your special version, might be useful in future ?
I’m going to try now on server that I know it worked before to see if we see the MTU fragmentation to prove, if this was the root-cause.
@george1421 said in Proliant ML110G7:
@NTex said in Proliant ML110G7:
f I do from this very server (OS terminal) i do the command of tftp to our fog server to download undionly.kpxe and does no problem.
But in this case you are using the OS’ tftp client, where when you are pxe booting you are using the nic card’s PXE rom that contains the tftp client. I don’t remember HP servers, but I know Dell and you can update the bios, but that doesn’t necessary mean you update the NIC firmware. Through the lifecycle controller the NIC and RAID firmware is a separate install.
Yes, there is a difference between client and PXE.
I checked HPE all these servers have the latest NIC firmware.
I mean these servers are pretty old!
They release packages to patch on Linux, so I’ve done all that in the past.
@george1421 said in Proliant ML110G7:
Just to confirm your fog server is at 10.200.0.67? Once iPXE gets loaded and running it access the FOG server over http which is a bit more WAN friendly than tftp.
Yes, that’s the IP.
Yes, I noticed the MTU is smaller on this location, so gets 106 bytes on 2nd window.
These WAN links are all Fiber 20 mbps, minimum.
Might be due to VPN, using part of MTU though.
My thoughts were always towards to I wonder if it’s actually the card firmware might be bogus and doesn’t load the bootfile, but is the same version for the working servers.
And like I said on initial post, if I do from this very server (OS terminal) i do the command of tftp to our fog server to download undionly.kpxe and does no problem.
So I can deploy like tftpd64 server on Windows client and then change my DHCP to get that client instead and capture all the action ?
Would it work ?
Yes, you’re right I start capturing before the actual bootp.
Problem was using capture on Appliance.
This capture was on Switch port where the actual server is connected, so you will see a lot more traffic.
iLO IP is .2 and gateway .254.
See if this has what you want I filtered to dhcp I saw option 594 or something.
Thanks
@george1421
Fixed the previous post, I was having issues uploading files directly on forums.
Attached screenshot from iLO that gives me the view / control on the client:
I attached both captures.
Fog Server Capture
WAN Side / Server
Hello again,
I actually done both (WAN and Fog) in past, but never done on mirror way, this is good idea.
I use Meraki location, since has a capture tool, it’s very good.
On the WAN side, I capture all traffic for host DHCP IP and on Fog Server the ports mentioned.
It actually loop for while and can take sometime to finally give up on loop and time-out, so I set it as 180 seconds on both ends.
There was once took 30 mins to finally give up.
The screenshot will show you … like not loading.
Usual behavior, is the use graphical representation of pipes and slashes while loading PXE bootfile, instead of …
Attached screenshot from iLO that gives me the view / control on the client:
I attached both captures.
Fog Server Capture
WAN Side / Server
I’m really curious to see, if you can discover the reason on these specific servers, even if I can’t solve it remotely for some odd reason.
I’m not used to not get some the answers, I always like to find why something doesn’t work like how it should work.
Thanks for everything.
PS - Edit uploading on forums doesn’t seem to be working for me, throwing “Something went wrong while parsing server response”, hold let me fix it.
Yes, you understood correctly.
Different locations, we did like around 200 migrations, with no issue whatsoever. These locations all have the same template.
All other servers boots fine on this specific model and all other models, even some recent Lenovo, I have no issues.
I also tried to run tftp command from the actual server while inside the OS shell, it download the PXE file from our Fog server, no problem.
This happens only when we try to PXE boot those.
I have some Windows workstations on all these subnets I can use, only
One site I have MX Meraki those have a incorporated Wireshark as tool, which I can save it too.
Thanks
Hi,
I’ve been enjoying these forums as avid reader and technical help.
Manage to do my Windows Images UEFI and Legacy for deployment.
Manage to have my Linux OS to be installed through HTTP
Also, helped me to get some diagnostic / maintenance tools, such as GParted on PXE Boot.
I can easily deploy and really fast my images / OS’es installs even through my MPLS Wan Links.
I even discontinued completely my WDS, is gone forever.
So, overall it’s been working very good.
We’re doing a mass Linux Migration old system SLES11 to CentOS 7 / 8 using HP iLO.
I have many hardware generations that goes through G7 up to G10.
Now for some reason I have 4 servers of 35 of this G7, won’t boot at all.
They will get an IP from DHCP fine, no problem.
Fog Server will receive the request I checked the logs, but aborts and then loops on this:
Aug 28 03:19:47 fogserver xinetd[1328]: START: tftp pid=10927 from=10.173.72.153
Aug 28 03:19:47 fogserver in.tftpd[10928]: Error code 0: TFTP Aborted
Aug 28 03:19:53 fogserver in.tftpd[10929]: Client 10.173.72.153 finished undionly.kpxe
Aug 28 03:19:53 fogserver in.tftpd[10929]: Client 10.173.72.153 timed out
I also checked the tcpdump tool and traffic goes back to the server.
Being MPLS I have no firewall between these servers.
Also, it’s just this 4 servers, the other 31 servers had no issues.
And checked PXE boot is enabled on this INTEL 82574L
Also card firmware is the exact same for all 35.
I tried all the Fog Legacy PXE files, as well.
Any way I can find out the root-cause for this problem ?
Thanks for your help and keep up the good work.