Image Capture/Deploy issues 1.5.7

[Quazz]

@fallenhero234 said in Image Capture/Deploy issues 1.5.7:

Permissions on image files set:
ls - laR /images
chmod -R fog:root /images

I assume you mean chown -R fog:root /images

It should be chown -R fogproject:root /images for 1.5.7, so run that command to fix ownership.

After that we can see if more steps are needed.

[fallenhero234]

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.

[Sebastian Roth]

@fallenhero234 As I said before, We need the log to be able to help.

[fallenhero234]

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.

[Sebastian Roth]

@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.

[fallenhero234]

[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

[fallenhero234]

When checking the status this comes up also.

[fallenhero234]

I ran a restart for multicast just now

[fallenhero234]

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?

[Sebastian Roth]

@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.log when this happens after a fresh server bootup?

[fallenhero234]

@Sebastian-Roth

I rebuilt the system. Everything is good to go at this time.