@fmaster007 the … translates to the path of your fog installer, not the path on Linux of /lib

You can use a dns name and create a split horizion dns where you make fogserv.domain.com at each school point locally to the local fog server.

The issue is as Wayne said, Once the client touches a fog server it becomes tattooed to that fog server. Now if you know that ahead of time you can synchronize (i.e. copy the ssl certificate from your master FOG servers to the other remote fog servers) then have the clients reach out via dns name. If you have any clients that have touched one of the older non master fog server, you will have to reinstall the fog client on the target computer.

Can one of the @developers or @moderators or @testers check to see if this bug exists in 1.5.2 please? I’m not able to do it at the moment.

I found out that the error was caused because the fog account was not recreated when we upgraded. All is well now except for name changing and getting them on the domain automatically. I think that is also a password issue.

@ddavis
If rebooting the server does not fix the problem it could be an apache problem, you could run a

tail -f /var/log/apache2/error.log``````

let this run and see what you get when you try modifying your changes.

@wayne-workman

Going from 1.5.0 to 1.5.2 resolved the issue.

Glad that helped. The beauty of an active forum where ones struggle becomes others solution. Pretty cool.

@andythemayor Lol, my bad. I thought you were OP. I didn’t read…

Also, changing the memory to 256 resolved the issue, thanks for the help!

I am having this issue with 1.5.2

Just throwing this out there, might absolutely not be related and me just missunderstanding whats actually happening here.

I had problems Imaging a computer at point when switching from a hdd machine as image-source to an ssd.

I had to change the host primary disk to the correct one - I think from sda to sda2 or something along those lines - for this to work.

Rereading again I suppose this is in another direction, but just in case.

A pending host is a host with the FOG Client installed that is not registered in your FOG Server.
That FOG Client is calling home to your FOG Server and is added as a pending host - because it is unknown and therefore untrusted until you (the admin) claim it. Claiming is basically saying ‘Yes, that’s one of ours, trust it’

This was made aware a while ago and has been addressed in the github working branch which will become 1.5.3.

@wayne-workman
That worked!

Legend - exactly what I needed.
Nodes are visible and I can continue the project 😄

Where do I mark this as solved and buy you a virtual beer!

@george1421 I had downloaded the 6077 again and not 6078 🙂
END USER ERROR 🙂

@julianh said in Ubuntu upgrade to 16.04.4 LTS kills Fog:

I have a dedicated fog Server that was somewhat expensive with its SSD arrays, so I can’t migrate to a new box, I can’t afford it.

You could migrate to a VM first - then from the VM back to the nice hardware. Keep the VM as a spare - but first use the VM and ensure everything is correct and working - and imaging.

@adowns Seems like it is the same issue i’m having.

I’ve detailed in the topic I raised how I get this to ‘work’ for a small number of machines, but I would not call it a fix by any stretch of the imagination.

There is definately an underlying issue, and Tom is aware.

Please see https://forums.fogproject.org/topic/11799/1-5-2-on-debian-multicast-session

@tom-elliott said in Change menu boot order:

So ordering becomes problematic as the all hosts items show in either the non reg or reg hosts. So priority should go where? Should non reg hosts be displayed before or after all host items. Or vice versa? Similarly for reg hosts. Or should we just do it based on numbers.

I looked into this a bit then got lost how fog imported the pxeMenu table. I was hoping it was a sql query to where I could just add a new integer field to the table as display order. Then use a sql statement like
select * from pxeMenu order by pxeOrder asc, pxeID asc That would allow pxeOrder to override pxeID if set, otherwise pxeID indexing would work the same as it does now. You could default pxeOrder to 0 so the pxeMenu would work as it does today and then let the FOG Admin mix up the menu. But alas I could not pull it off, but it was the plan.