@tom-elliott
Nice move! Thanks a lot!
i give it a try!

Hi!

Search for dhcp.conf or dhcp3.conf or something in /etc edit this file with nano or vi for each host you need an entry of this form:

host MYCOOLHOST {
hardware ethernet 00:00:00:00:00:00;
fixed-address 1.2.3.4;
}

Replace the 00:00:00:00:00:00 hosts MAC Replace 1.2.3.4 with your desired IP restart dhcp service or simply reboot

hth
xibeaga

@george1421
thanks Georges!

it s ok!

nice!

@sebastian-roth
I’m currently creating a new FOG server as a test to see if it does the same with that, if it works fine, I’ll re-install FOG on the old server, however, as it’s a school, and staff are teaching using the PC’s that have been imaged with FOG, If I was to re-install FOG would it affect the machines if the client (the FOG Service) can’t talk to the server, IE, it’s not going to reboot or disconnect from the domain or anything?

Thanks,

Dan

@tom-elliott
That did it, sorry I didnt find that post in my searching.

https://forums.fogproject.org/topic/11722/problem-during-upgrade-from-1-5-0-to-1-5-2/18

I just didn’t read enough. Disregard! This fixed it.

@george1421 Yes that fixed it! and yes i realize that both these errors imply that someone messed with my server. I may have unintentionally done it myself but i dont know when. i’m also doing all of this in a votech class room with immature high schoolers around and they may have screwed with something. doesn’t really matter though, its fixed ad i thank you for helping me sir.

@sebastian-roth I looked at the shared pcap with a fresh set of eyes this AM and that is consistent throughout the dhcp server responses. It correctly sets the string length but doesn’t terminate the string with 0x00. While it complies with the letter of the IEEE document, it doesn’t follow common practices. I did check a few other pcaps I had laying around and all responses from those random dhcp servers had the string length and 0x00 in the hex code. It appears this Infoblox dhcp server is doing something a bit different. The OP may need to get with Infoblox and show them what he is seeing.

@sebastian-roth I changed that line but do not see any difference. This is what I altered:

explode("\n", $mainFallback), array( 'goto MENU', ':get_console', "console --x 1024 --y 768 --picture $this->_booturl/ipxe/$bgfile " . "&& goto console_set || goto alt_console", )

I also noticed a vast difference between the size of the menu in BIOS and UEFI, the BIOS version is actually a little too big if anything, but the UEFI version takes up maybe 1/4 of the screen.

Any way to get these 2 menus on par in terms of size with each other?

As an aside, I thought setting the resolution to 1024x768 (matching my bg) would get the background to display, but it has not.

I guess next step is to try and save my bg as 800x600 and see if it displays, then as png instead of as jpg.

Thanks

@tom-elliott Awesome! Thanks a bunch Tom. I was able to get it resolved with the tips in that post.

Well, I mounted the ISO for 6.5 on the server, copied everything over, recreated the menu and edited the boot.cfg and the same issue:

The bootx64.efi and boot.cfg load as expected The VMWare ESXi installer loads files according to the boot.cfg The VMWare ESXi installer starts, the band/progress bar at the bottom gets past a couple stages and then PSOD on the “storage-stack” portion every time.

(all related to 6.5 U1 A10)
Tested 2x R620’s, one with all newest firmware, both have same issue. Tested on an FC630, works no issues.

ISO burned to physical media runs as expected and works in both R620’s via UEFI DVD/CD boot.

I am going to try and alter the 6.5 install to run over ftp instead of http to see if it changes anything. I had done this prior I think, but want to be sure. I will pass everything via ftp (bootx64.efi, boot.cfg and all modules from boot.cfg).

If that doesnt work I will just give up on the R620’s getting PXE booted ESXi 6.5 U1 A10. As long as its 1 or 2 machines/models that arent critical I can live with that but if the crashes become the rule and not the exception thats going to cause issues for me.

Lastly, is there anyway to via UEFI do something similar to a memdisk/iso load? I know memdisk itself is BIOS only, is there a way to UEFI boot straight from ISO?

Thanks

EDIT: ftp crashes just the same, i give up unless I can UEFI boot the ISO

@ravigon Thank you very much for reporting this. Most definitely this difference is due to Microsoft changing something through a patch made public after our wiki article was initially published. I will get this updated photo into the wiki and again thanks for this! #wiki worthy.

@shad0wguy Looks like it may have been an issue with the AD integration on the NAS I have set up as my storage node. The user account I have set for fog wasn’t able to authenticate.

@george1421 A coworker was able to resolve the problem coming in with a fresh mind. Apologize for the wasted thread

@thebrennan47 That helps out quite a bit. I thought there was a bit more going on here than I originally imagined.

You need to change up your configuration. Your storage node is acting as a gateway between the fog server and the target systems. You need to change the served subnet on each storage node. Each storage node needs to be connected to a unique subnet. On the surface you have a routing problem not a fog problem.

Consider if you are using subnets 192.168.1.x on each storage node. If a computer on SN1 talks to the fog server, and a computer on SN2 talks to the fog server and each has the same subnet, how will the fog server know where/who to respond to.

So how to fix it? Give SN1 imaging network an IP subnet of 192.168.1.x./24. Give SN2 imaging network an IP subnet of 192.168.2.x/24. Give SN3 imaging network an IP subnet of 192.168.3.x/24.

Now go to your internet router and create a static route (or you can do this on your FOG Master node) that describes the subnets beyond each storage node. Like

ip route add 192.168.1.0 mask 255.255.255.0 via {SN1 LAN interface}
ip route add 192.168.2.0 mask 255.255.255.0 via {SN2 LAN interface}
ip route add 192.168.3.0 mask 255.255.255.0 via {SN3 LAN interface}

You will need to change the dhcp server settings on each SN too to match their respective imaging network range.

Once you have routing and unique IP addresses in play FOG should work a bit better.

Hi Tom.

I wanted to update you, I have performed fresh installs of Ubuntu on all 3 servers, and installed the latest working branch version of FOG, 1.5.2.10

This time I did not import my hosts and old images and started fresh by re-registering hosts to test with. This time I am not having issues with the location plug in. Perhaps it was the old host data which was causing these issues.

Anyways, I appreciate all your help and time, and your effort on this wonderful product which makes many other peoples lives much easier.

Fixed in working branch.

If you have ubuntu (likely based on the path of the error log file) AND FOG was working great yesterday and now its not AND you changed nothing, blame it on Ubuntu. Review this document and see if it fixes your issue: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@mrlemur I don’t think there’s a way to set a default. On a positive note, you can use groups to set the location for many hosts at once. You can also temporarily set max clients to zero for the storage node you don’t want to use. Using FOG’s searching functionality, and with know edge of your naming convention, you should be able to quickly sort hosts into groups by location.