Posts made by MikeBC

@george1421 I have experienced major issues using the WD19 dock for network booting for imaging to FOG, I don’t use them for this application. I don’t suggest using them either as far as possible for this application, but rather try using WD15 docks they work and have fewer issues it would appear in my experience for imaging purposes with FOG. I don’t know why, just what I have learnt from troubleshooting over a course of time. I did several cross-over experiments with several Dell laptop models using the WD15 & WD19 docks and it always pointed to the dock type being used with errors/issues experienced. Hope this helps, all the best.

@oceanfish I had issues using a Dell WD19 dock as well especially via network boot to FOG. I did change to Dell WD15 dock and they seem to work much better with far fewer issues relating to network boot to FOG. Maybe try that as course of action.

@george1421 Thank you. I will delete them shortly to avoid any further issues.

Looks there was finally as solution. I ran yum update -y today and after a server reboot the image capture with database update worked 100%. I must thank @Sebastian-Roth for assisting me in the chat bubble running various scripts and looking many possible fixes to try remedying the issue experienced. The support received was fantastic, thank you kindly.

@Sebastian-Roth

[root@imagingout ~]# ls -al /images/dev
total 0
drwxrwxrwx.  6 fogproject root 130 Oct  6 08:20 .
drwxrwxrwx. 10 fogproject root 186 Oct  6 08:21 ..
drwxrwxrwx   2 fogproject root 190 Mar 20  2020 082e5f1dface
drwxrwxrwx   2 fogproject root 222 Jan 14  2020 64006a486167
drwxrwxrwx   2 fogproject root   6 Apr 30 15:39 ecf4bb70a96c
-rwxrwxrwx.  1 fogproject root   0 Oct 11  2019 .mntcheck
drwxrwxrwx.  2 fogproject root  34 Oct 11  2019 postinitscripts
[root@imagingout ~]# cat /etc/exports
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
[root@imagingout ~]#

@Sebastian-Roth I ran the capture twice once to the /images/Client directory and then to the /images/ directory both times same error occurred that I have been experiencing. I have attached output.

@Sebastian-Roth I ran the task at about 10H30 or so. I wasn’t in front of the PC at the time to verify error on completion. I will run it again shortly and provide error message again.

@Sebastian-Roth I have attached logs as requested

@Sebastian-Roth I have supplied output as requested

@Sebastian-Roth incidentally yes they did. However, I did delete that host and used a separate machine to test and problem with the 503 service unavailable still remains/persists. I also tried the dash and same 503 error came up.

@Sebastian-Roth Thank you for assisting. The image path listed is to a Client folder for client specific images. So some context to this. We have client specific images captured to a Client folder and then we have oem images for a wide variety of OEM vendors relating to makes and models in an oem folder. I also have a Test folder R&D/development purposes. I will try the dash, but I have captured over 300 images using this method with the slash. I only capture as needed when required. We focus on deployment of captured imaged.

Regarding the hosts query, my techs boot via pxe to deploy as such apart from the server running I don’t have any other hosts running, if I have this answered this correctly. We do have up to 50 different PC’s having an image being deployed at a time, not sure if this the load issue? I have a separate server as a back-up that runs fine with both capture and deployment, that is running version 1.5.8

We don’t use a proxy server for our network. Here is the version detail on login page:
Latest version: 1.5.9
Latest development version: 1.5.9.5

Also, I have updated kernel: bzImage version: 5.6.18 & bzImage32 version: 5.6.18

I have uploaded output of commands requested.


Please could I get some assistance to resolve this issue. Some brief context of how the issue happened is, after extended power outrages and the server shutting down due to UPS dying. I ran yum updates and the problem went away previously.
This time it did not work. I ran yum updates and updated Fog to version 1.5.9 from 1.5.7 and this has not solved the issue. I can deploy images without error/issue only capturing is an issue presently, which I need to urgently resolve. The error happens after image has captured and database needs to update.
Server is running Centos 7, Gnome 3.28.2

I have ensured the user credentials in TFTP under Fog settings and the Storagemanagement-Storage Nodes are identical.

I would really appreciate a fix/solution so as to mitigate further problems when power outages happen again in future.