Image Capture/Deploy issues 1.5.7
-
(New installs fist time user)
Fog version: 1.5.7
Linux version: CentOS7
Machine: HyperV- VMStorage Node also set up with same versions.
What is working:
pxe boot to fog from client.
Storage node is active.Issue:
Cannot capture or deploy image without running the SmartInstaller. Once smart installer is installed everything works but Multicast.Without SmartInstaller Capture:
Sits on screen stating: Unable to locate image store (/bin/fog.download) Args Passed:Steps attempted:
Verified that both the username and password are the same for both FOG and FOG Storage
vi /opt/fog/.fogsettings
Verified that WebHost has correct configuration.
Permissions on image files set:
ls - laR /images
chmod -R fog:root /images
Sources:
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Credentials_.2F_Passwords
https://wiki.fogproject.org/wiki/index.php?title=Vi
https://forums.fogproject.org/topic/9187/unable-to-locate-image-store-bin-fog-download/7Multicast Issue:
boots to session then sits waiting.Verified client number.
Verified port was enabled on firewall in initial server setup.
Tried other even numbered ports in rage of initial setup. (49152-65532)Big issue is not being able to multicast and having to boot a PC then use the installer then reboot then use mac address to then deploy the image.
Any help would be appreciated. Thanks.
-
@fallenhero234 So there are a couple of things and I don’t think it’s wise to tackle all of them in one go. So let’s start with the most interesting one (from my point of view):
Without SmartInstaller Capture:
Sits on screen stating: Unable to locate image store (/bin/fog.download) Args Passed:As I see it those two things should not be related whatsoever. But maybe I just get wrong what you are saying. With SmartInstaller you mean the fog-client being installed on the host machine, right?
The error “Unable to locate image store” has nothing to do with SmartInstaller/fog-client as FOG boots into a self contained Linux environment (which we call FOS) and doesn’t care about what is installed on the disk really.
But we have seen people reporting this error a couple of times lately. Please search the forums to see if there is anything of value for you there.About multicast: Let’s try to solve the other issue first but as a good starting point you can have a look at the log in
/var/log/fog/multicast.logand maybe upload the contents of that file here. -
@fallenhero234 said in Image Capture/Deploy issues 1.5.7:
Permissions on image files set:
ls - laR /images
chmod -R fog:root /imagesI assume you mean
chown -R fog:root /imagesIt should be
chown -R fogproject:root /imagesfor 1.5.7, so run that command to fix ownership.After that we can see if more steps are needed.
-
As an update:
Iv gone ahead and rebuilt our FOG client and allocated the space to fog without using a storage node.
I have casting/deployment in single form working just fine, but multicast is still an issue.
It will join the session but not start once the device joins. It just sits at the waiting to deploy screen. -
@fallenhero234 As I said before, We need the log to be able to help.
-
Im having issues pulling the log as it says permission denied
Im logged into the admin account and ran a sudo ru
Put me at root with same issue using /var/log/fog/multicast.log
This is my Fourth day working with linux so it may be something simple im missing. -
@fallenhero234 How do you try to “pull” the log file? Maybe just use WinSCP from a Windows computer to connect to your FOG server and copy the file over.
-
[07-24-19 2:21:11 pm]
=== ==== ===== ====
=== ========= == === == ===
=== ======== ==== == ==== ===
=== ======== ==== == =========
=== ==== ==== == =========
=== ======== ==== == === ===
=== ======== ==== == ==== ===
=== ========= == === == ===
=== ========== ===== ========= Free Opensource Ghost ======
============ Credits =============
= https://fogproject.org/Credits === Released under GPL Version 3 ==
[07-24-19 2:21:11 pm] Interface Ready with IP Address: 127.0.0.1
[07-24-19 2:21:11 pm] Interface Ready with IP Address: 127.0.1.1
[07-24-19 2:21:11 pm] Interface Ready with IP Address: 192.168.40.25
[07-24-19 2:21:11 pm] Interface Ready with IP Address: localhost.localdomain
[07-24-19 2:21:11 pm] * Starting MulticastManager Service
[07-24-19 2:21:11 pm] * Checking for new items every 10 seconds
[07-24-19 2:21:11 pm] * Starting service loop
[07-24-19 2:21:11 pm] * No new tasks found
[07-24-19 2:21:21 pm] * No new tasks found
[07-24-19 2:21:31 pm] * No new tasks found
[07-24-19 2:21:41 pm] * No new tasks found
[07-24-19 2:21:51 pm] * No new tasks found
[07-24-19 2:22:01 pm] * No new tasks found
[07-24-19 2:22:11 pm] * No new tasks found
[07-24-19 2:22:21 pm] * No new tasks found -
When checking the status this comes up also.
-
I ran a restart for multicast just now
-
So after doing a FOGMulticastManager restart i was able to get multicast going.
Then we moved the fog server to its resting place and the service had to be reset again.
Is it common to need to do this every time the fog server reboots?
-
@fallenhero234 Which Linux OS do you use? Might be related to an issue that was reported a while ago where FOGMulticastManager was not able to properly enumerate the network interfaces on boot up: https://github.com/FOGProject/fogproject/issues/268
I guess what we see here could be kind of along the same line where systemd starts up the services in the wrong order. Database not being up when it start the MulitcastManager. On the other hand it’s strange because we have a check in the code that waits to be able to connect to the database. So I can only imagine a situation where the database is in a strange state. But then, why would a restart of FOGMulticastManager fix it??
Do you see the message “Waiting for mysql to be available” in
/var/log/fog/multicast.logwhen this happens after a fresh server bootup? -
I rebuilt the system. Everything is good to go at this time.