@207-tech said in Fog Service address is wrong:

/bin/fog.download it states it is unable to locate that directory

fog.download comes from the FOS Linux engine. When it throws that error it should printout the kernel parameters in the error message. Look to see if the old address is still displayed. If yes then look at the storage node configuration to make sure the default storage node has the proper IP address.

@george1421 I want to say thank you very much for your support and help.\It was very professional and fast, thanks again now I can continue enjoy a FOG solution in my environment

Best regards, Boris

@mashley With multcasting only one image is sent out from the server. So all the clients that participate in the multicast image work in lock step. So the speed of your image deployment is based on the slowest computer in the group. You do want to kind of group like systems (performance wise) together in a deployment group to get the best performance. If you have fast computers but one is behind a 100Mb/s link, that one behind the slow link will slow down the entire group.

@bsedash cross linking similar issue: https://forums.fogproject.org/topic/16244/fog-cannot-load-qlogic-network-driver-on-poweredge-r640/2

One solution two fixes. We might have a custom kernel soon to address this issue. I’m just waiting on feedback from the other thread.

@george1421 said in Database connection unavailable:

botched uploads

Nice thanks for the tips, worked

@george1421 Thanks. I’m going to debug a bit more next time I’m in the office.

@george1421 Thank you so much! That article helped immensely.

@chrisakak9
I think this is what you might need
https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/22

@flat4vw I found my answer got it updated.

@george1421 @Sebastian-Roth
hi guys,
the compression rate in the image caused the error
capturing and deploying works…
Thx 4 the support
thread closed … finally 😉

@juelson The output of the commands I asked you to run look normal except the directory listing of /images. There is a missing hidden file that FOG uses to know its connected to the correct image store.

There should be a file called .mntcheck in both /images and /images/dev This file is created by the fog installer so it should be there unless someone adjusted the contents of the /images directory.

So we can fix it with the following command. We will fix /images/dev so uploads work correctly while we are at it.

Key in these commands at the FOG Server’s linux console. You may need to use sudo if you are using a debian variant or do this as the root user.

touch /images/.mntcheck touch /images/dev/.mntcheck

This is a non destructive command so its OK to run them even if the file exists. Once the .mntcheck file is created you download should work better.

@juelson I’m not exactly sure what you are saying here, so let me reword what I think I understand your issue is using my words.

I’ve pxe booted and selected full registration to register my computer with FOG. Registration works just find but when I go to deploy an image and create the deploy task, when I pxe boot into the fog the iPXE menu it shows the computer is not registered with FOG. I know it completed registration OK because I can see it in the web ui.

I know I used more words than you did, but I applied what I think I understood with your issue to ones I’ve seen before. Did I explain the situation you see now?

@mgoh You could probably update the size with a sql command if you wanted. Not really a need to do it though.

@londonfog Not sure but I don’t think there are API calls for the iPXE menu stuff. I suggest you look into using a SQL query/insert or you might be able to code your own plugin to get what you want.

@jmccannon The current version of FOG only has admins and that is it. There is an admin plugin module, but I have never personally used it. I do agree that FOG needs to have and admin user and a capture/deploy/imaging user class.