@johnomaz said:

Yes, it can be flagged as solved.

Good 😉

@Wayne-Workman That is much more elegant than either of my solutions. I doubt you will need my help, but give me a poke if you want me to look at anything with you.

I’m going to solve this only because it seems a very particular set of information was causing the problem. While I was concerned my recent changes were the main cause, it seems they really weren’t, potentially.

I’m only solving because the problem was relatively easy to correct for.

Also - when did this failure start? Was it working before? What changed?

Have you checked the mysql settings inside of /opt/fog/.fogsettings on the problematic storage nodes?

Are you refering to Wake On Lan ?

I should explain a little perhaps - and then explain a few options.

When a computer is configured in it’s firmware to boot to the network first, It will try that. DHCP hears the request and sends info. The PC confirms it’s received info - there’s a fraction of a second’s wait - then DHCP sends a “Use it” command once no other computer reports “no don’t use that, I’m using that IP”.

Then the computer network boots to FOG - as it was told. If it is registered - it will look for any active tasks and do those - if there are no tasks it will either (A) Show the boot menu for a specified time and then try to boot to the HDD or (B) not show a menu at all and immediately boot to the HDD.

Just depends on how you have it configured.

By default, non-registered hosts will show the menu so that you see it’s not registered. This menu also has a countdown that elapses - after it elapses, the machine tries to boot to the HDD.

Now - if you don’t like seeing the menu for registered machines - the very best that can be done is to set the timeout to 1 second. You can do that here:
FOG Configuration -> iPXE Boot Menu -> Menu Timeout (in seconds):*

Now, do not set this to 0 because 0 makes the menu stay up forever… 1 is as low as you can go.

@Developers is that normal? 0 causing the menu to just stay up?

@middendorf said:

@ch3i

4557, like FOG says is the actual git version?

Can you rename the fog and html folders (like fog.bak and html.bak) and rerun the installer.

@Tom-Elliott absolutely, was looking for how I could mark resolved this side funnily enough,

I created a new installation of Windows without system reserved partition.

Apply the following steps when the Windows partitioning window apeares:

Create a partition on the blank hard drive. Select the partition drive as the partition to install Windows on. Click “Next”. The 100MB partition will be created. Delete the partition which you created in step 1. Extend the 100MB partition to the desired size. Select the partition which you extended in step 5 and select ‘Format’. After formatting the ‘system reserved partition’ will now become normal ‘system’ partition.

I can confirm this works 🙂

@ambers said:

We are currently using 1.2 on Ubuntu version 14.04

Maybe a problem with GPT, have you install from scratch the computer ? If yes have you remove the old partition table ?

@Wayne-Workman didnt testet it thoroughly, but as I described it, it didnt work, (I made sym link /image - so no change in exports was needed?) , permissions and files created were ok - after changed exports to new location, everything startet to work.

I wanted to respond with a link:

https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

Please bear in mind that at the time of this post, this article is a work in progress - however at this point it does contain a lot of information and links to other information.

@josh.nicholson99 I should slow you down firstly - do your vlans go over slow and long distance links?

For example, my organization has every site connected via dedicated lines - but those lines are low speed links. We avoid heavy loads over the WAN links at all costs. EVEN THOUGH we have a vlan infrastructure that can easily bring any network to any port that we wish. If your organization’s setup is similar to this, I’d urge you to use the location plugin and setup storage nodes at each of your physical locations.

In the case that you have amazing WAN speeds or don’t have WAN links at all, then I’ve found these links that might be of interest:
https://communities.bmc.com/thread/41369
http://www.humboldt.co.uk/a-working-tftp-server-for-multi-homed-linux-systems/
http://www.tecmint.com/install-pxe-network-boot-server-in-centos-7/

It would seem as if dnsmasq is the answer… I haven’t looked deeply into it yet though.

Glad to see this is fixed. I helped to the extent of my abilities via forum chat but I came to a dead end basically. And Tom’s post explains why. Good to see a solution is found.

I love how this guy comes here - posts, gets impatient, posts again - then never comes back… and after he leaves, he gets 5 genuine pieces of advice from 5 different people - but he’ll never know that, will he?

All of us here have Jobs man! We are volunteers for the FOG Project!

@Tom-Elliott Phew, you weren’t wrong when you said it was a bit overkill. I’m a bit apprehensive about doing anything that I can’t understand what is happening to the FOG server. For example, if something breaks with this script, I don’t know exactly where to fix it.

I also still don’t have a bare metal backup of my FOG server yet, and I can’t afford to have it down, especially at the beginning of the school year (I work for a Public School). Possibly once I have a backup of it, and when school is out for a break or something, I’ll return to this and attempt it.

Unless you’ve got an easier idea to change those defaults, I’ll just put it on the back burner until further notice.

I’m solving this thread namely because the question that was asked, originally, is already displayed. The next series is specific to customizations and the changes required for our new stuff vs. the 0.32 inits.

I’m solving this thread. The reason your systems were failing to register wasn’t, specifically, a problem with FOG directly, but seemingly specific to this one system. Does this sound correct?

So let me get this straight, the only “PXE Reboots after…” is happening on the VirtualBox VM?

I am aware of issues with Virtual Box, specifically, and the only fix that I found (if you’re using undionly) is to do a power off, then power on. The other, more appropriate, fix is to use ipxe.pxe file rather than the undionly, but i also know that not all Physical systems will work with the ipxe.pxe.

@need2 said:

Make sure you have your Surface on the latest firmware, or if not the August firmware, at least the July firmware. They’ve done some serious cleanup on the Surface EFI firmware that has made it a bit more network boot friendly.

Note made here: https://wiki.fogproject.org/wiki/index.php/Filename_Information#efi