@george1421
As always, I appreciate the help! I am happy to help out where I can.

I was able to remote in and find out what was going sideways with the OP’s system. I’ll fill out the details in a bit, but there is the keys.

mods-enabled/php5.conf set handler

9.4

sites-enabled/001-fog.config

It appears to be an issue with at least debian 9.4 at the moment where php-fpm wasn’t being enabled causing the sluggish UI and high apache usage.

@xpalis said in Multicast is slow:

multicast speeds reach up to 1.5-1.6 GB/min ONLY if i connected fog server separately from my network.

So we see that your FOG server and the clients are able to do full speed. So it’s probably your network equipment or some kind of configuration of those. Would you mind drawing up a quick schema of your network structure including subnet information so we know better what your setup looks like?

@Kami Can you please boot the client your are trying to capture into Windows and take a picture of the disk management dialog? While you are there make sure fast boot is disabled (a lot of the Windows updates to enable fast boot over and over again).

@george1421 Pffft…i’m there with ya brother. 😉

@george1421 nope I haven’t because I don’t know that it slows everybody down, and even if it is slow, it’s not broken.

Thanks for the feedback. I got the chance to spend some time with the fog server today and it looks like the main issue was with selinux. Appreciate the help!

Upgrading the firmware worked!!! No idea what has changed in the last month, but I am just glad for a fix. Thanks for your help!

I’m so close to getting this working The only issue now is that i get now is a “no viable macs to issue” I re-ran the installer 15 min ago and that did not help per this thread https://forums.fogproject.org/topic/12006/fog-perform-full-host-registration-no-viable-mac-to-use/5
I renamed the .fogsettings file and re-ran the install still getting No Viable Macs to issue

So close yet so far 🙂

@Tom-Elliott
So my interface completely locked up. I restarted the server and had no luck at all getting to my interface. I ended up having to remove PHP completely and then let the FOG installer re-install PHP. My interface is back up. I have not ran any tasks yet. I’m hoping it stays up long enough to get something done.

Here are the log when I try to list scheluded tasks
in /var/log/httpd/ssl_error_log

[Mon Jun 04 08:24:48 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 95, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 08:27:09 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 95, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 08:36:00 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 95, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 08:47:45 2018] [error] [client 192.168.1.10] PHP Warning: trim() expects parameter 1 to be string, array given in /var/www/html/fog/lib/fog/fogbase.class.php on line 1316, referer: https://fogus.univ-rennes1.fr/fog/management/?node=task&sub=active [Mon Jun 04 14:10:47 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 54, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 14:11:18 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 86, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 14:29:39 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 86, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active [Mon Jun 04 15:18:51 2018] [error] [client 192.168.1.10] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/fog/lib/fog/fogcron.class.php on line 86, referer: https://fogus.univ-rennes1.fr/fog/management/index.php?node=task&sub=active

Arnaud

@amerhbb said in Problem capture image windows10 "Error 5 could not open i node 305764 through the library input/output error":

And this steps don’t change my images or my hosts???

Correct. Your images are stored in /images directory. The fog application is installed in /opt/fog and /var/www/html/fog.

@john-l-clark If your image was from a machine that was in BIOS mode and the media to initially install was BIOS media as well, then the image is being deployed to the HDD/SSD with BIOS partitioning and not UEFI boot partitions. In this case the UEFI/BIOS would not consider it a UEFI bootable device (as it has no UEFI boot partition). Presuming your image is whole disk and not a single partition.

I have seen posts around about converting images that are BIOS to UEFI, but didnt pay much attention to them. If the process of setting up that machine with a new image isnt too much of a burden, that may be your best bet. Fresh install OS with UEFI settings/media, setup what you need and capture.

Hope this helps

I haven’t added such a thing for one main reason. Multicast sessions are intended to be things you’re sitting in front of the systems for. I’ll see about adding a feature like this however as I can see the value in it, and didn’t think much about it 3.5 years ago when I created the session capability. If that tells you how long before, as far as I can recall, anybody asked for such a thing.

@amerhbb The error says the filesystem is not clean, so please read through this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

@sebastian-roth

Update:
The switches were waiting for 260sec (4min 20sec) for the clients to send out a “I still want to receive this multicast stream” but the clients didn’t so the switches stopped sending the multicasts. I’ve changed that so the switches will now wait for 1260sec (21min) before stopping the multicast.

Our networks team had a look and muticasting is now working!

@tom-elliott Yes. Thank you. Image capture completed.

@george1421 Wow! That was it PXE is now working! Thank You Thank you Thank You

@quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

@quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

@zer0cool I think it will redirect anything with url/fog so try going one directory higher.

Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!