@george1421 said in Cannot PXE boot:

I have also seen that some projects actually have a service page that lists if the services are running or not, and gives the admin a choice to stop or start a service.

I’ve got a DHCP plugin ready to be integrated into fog… just having a lot of trouble understanding the plugin system for such a large plugin.

But, I can easily create a two-file + small DB change plugin that will detect the status of services and offer the ability to restart on a click.

Again though, the one thing holding me back from going wild is a lack of understanding of the plugin system. People have attempted to explain it to me many times but it just doesn’t click. I need to be shown.

@adukes40 Sounds right.

@adukes40 no problem.

I can say for sure that the e6410 pxe boots just fine using the trunk (dev) build of 1.2.0.

The e6410 is a bios only system that does boot with the undionly.kpxe. Since you said that you had an older version of FOG installed, can you tell me what you have defined for dhcp option 67?

When iPXE boots, there is a series if hex values that indicate the build beyond the version number. What is the build number.

@Rwest Are you using FOG trunk or version 1.2.0. Please post a picture of the error you see when trying to deploy!

@fdrouard wol/wol.php path no longer exists.

@arnaudrigole As you can see there are no udp-sender processes running. So multicast just cannot happen. Those should be started by the FOGMulticastManager service (which seems fine on your server). So please check the logs as I suggested earlier.

@MadsMagnus Great to hear that you found out what was causing the issue! Marking this for addition to the #wiki article on debugging boot problems.

You’re experiencing FTP related issues. There are a number of things that cause this, but greater than 90% of the time it’s simply bad credentials.

This article contains everything you need to get it sorted:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@Tom-Elliott ok roger that. Thanks so much.

@Quazz Hi Quazz yes main problem of high cpu usage appears to be much better - main server with most number of hosts is sitting at 5-30% CPU load roughly with no active tasks running. I’m testing now with images running to double check under load.

cheers Kiweegie.

That’s what I figured. thanks for clarification.

@george1421 Upgrading to trunk has resolved this issue - thank you! 🙂

Hi, thanks for the reply.
I had to update via git (https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk) in order for these options to appear. I was using version 1.2.0 but could not find this. 1.3 changed everything and so far seems to offer what I needed.
Thanks.

@Wayne-Workman
That did Wayne, thanks again for the help. Updating passwords between storage node in gui, and .fogsettings, so they match, was the final answer.

@Wayne-Workman Thank you, I just finished imaging a machine with an older image, so it 100% was the image. No worries though, I’ll just build a new one. Thank you!

@Rich-C Tom has also been telling us the newer trunk kernels will work with 1.2.0 stable. So if you backup your current kernels you can download the latest trunk version using the following commands on your fog server. Just navigate to /var/www/html/fog/service/ipxe , rename the files and then execute these commands.

sudo wget https://fogproject.org/kernels/bzImage
sudo wget https://fogproject.org/kernels/bzImage32

These kernels are 4.5.3 as of today.

I do have to say my personal recommendation is to just upgrade to the trunk release to take advantage if the new features (as long as you can tolerate a little instability of the dev releases).

@Tom-Elliott Alright thanks for the help.

This was solved by changing interface defined in storage node, just as Tom said! thanks!

@george1421 agreed, but it ws already bought… so will work with what I got.