@vanopstp15d try

mysqlcheck -r fog

There is a wiki page to reset the default fog admin’s password. Its here: https://wiki.fogproject.org/wiki/index.php/Reset_WebUI_FOG_password

I would also look at both the apache and php-fpm’s log files in /var/logs directory to see if there is any error messages listed in there.

Next Server IP address was wrong on DHCP server. TFTP is working now! Thank you @george1421

@rodluz said in 503 Error and stuck at "attempting to update database":

So I changed the pm.max_children setting to 150

Good catch on the max_children setting. If you would have had a current version of FOG that setting would be 35. I think 150 is a bit excessive since each child consumes ram. I think 50 might be a better choice to start with. Most people don’t start 20 simultaneous unicast streams so I can say we’ve not run into this issue before with the standard 35 max children. 5 IS a bit low.

So to recap you had 2 issues, one was the memory limit and the other was the max children setting.

Once you get past your image push crunch, you might consider upgrading to the latest version of FOG.

Well I can say, that is a VERY good question. FOG is only intended to clone local block level devices. iSCSI is not necessarily in scope. With that said, it would be interesting to see it work. 😉

So let me ask you this, if you manually register this VM and then schedule a debug deploy task (tick the debug checkbox before you hit the the schedule task button. Then pxe boot the VM. This will drop you to a linux command prompt on the VM. So to the question (since you seem to be familiar with iSCSI) can you mount the iSCSI lun from the FOS Linux client? If you can then we might have a solution. I don’t know off the top of my head if the iscsi tools are install in FOG Linux (they should be but I don’t know for absolute). If you can connect to the iSCSI LUN then document the process so we can create a bash script to do the same.

@Sebastian-Roth It’s worked ! I’ve done your solution three times in a row and it seems worked.
Thanks you for your job and your disponibility.

@Atton So now you can ping the workstation by their short windows names?

It did run as expected when I included the bash reference at the top of the copy script and changed the mode of the new fog.download script to 755.

You should see the script run right after FOS Linux picks up an IP address. The line will start out with * Running post init scripts.......

You should have a chance to see that message if you run the fog compatibility checker from the iPXE menu.

Just figure it out. I used dnsmasq and I changed its configuration file to my new ip address and my client computer could boot fog.

@Veerakumar Thanks for the update. I was wondering why you wanted to use that other field in the “FOG Boot settings”…

As always, the community comes through! Not sure how this got askew, but following these directions I was able to fix the issues. The image pulled correctly and at the end updated the database info. The image is good, I am all set. Thank you again this was awesome!

@nelsonnc Sounds a bit like STP issue to me as well. The quickest way to check is to connect a dumb mini switch between that client and your building switch. See if that makes a difference.

How do you know the client can reach the FOG server? When it’s booted to it’s OS from disk, can you open that exact URL in the browser on that client? http://dlk.fog.local/fog//index.php (double slash is not an issue)

Turns out someone was annoyed that our network went down and plugged in their personal router. Thank you for the advice.

Hi EduardoTSeoane,

Thank you! Restarting the FOGSnapinHash service with systemctl restart FOGSnapinHash worked! I did check if this service was running but never thought about restarting it. This gave me some more energy to search the forum.

I found this post also noting the FOGSnapinHash interval is 30 minutes. Then I found one can change that interval on the FOG server by:
FOG Configuration >> FOG Settings >> FOG Linux Service Sleep Times >> SNAPINHASHSLEEPTIME from 1800 seconds to …

I still think it’s very strange someone should have to wait for 30 minutes after creating a Snapin that reuses a file with a default FOG installation, as it seems to be a common thing to do because of the Snapin File (exists) drop down menu in the GUI, but I’m glad and thankful my problem is solved!

Best,
J den Hartog

@gpd187 said in Cannot PXE boot target capture device.:

Could not start download: Operation not supported

Please post a picture of that error on screen!

@chunter2 Leaving it won’t hurt anything. One might think, if its working now its good enough.

@george1421 said in Cant deploy images from master node and storage node at the same time.:

@paat said in Cant deploy images from master node and storage node at the same time.:

But do i get this right if you go this way you have no automatism?

Yes you won’t have unattended deployments if you don’t pxe boot through fog, BUT you won’t accidentally wipe the CEO’s laptop either if you force the IT tech to at least sit in front of the computer to start imaging process. The rest of this method is all no toch.

Hey I created a new image with a script which starts with the setupcomplete.cmd and this fixed the Uefi-Boot issues via bcdedit.
I didn’t use the dell cctk tool yet because I have still a few Fujitsu machines left but maybe i’ll switch to it because it seems very powerful (firmware deployment, bios managment etc.)

The actual problem seems to solve by itself. I don’t know what happened exactly but I deployed the image to 50 machines and both servers (master and node) deployed the images. Maybe I was to impatient.
If I’m right the master server checks if there are open slots on each server and distributes and controls the image process
I think the thread can marked as solved for the moment.

Thank you for your help George!

had the option to remove encryption in the console, already solved! thanks anyways.

This question is a bit vague on details, so the answer is it depends.

If you sysprep the image and you are using windows 10 then the answer is probably. The 9020 is pretty old now so windows 10 probably has all of the native drivers for for the 9020 built in. You will probably want to ensure the firmware is updated on the 9020 to the latest and set the firmware to uefi mode to match the configuration of the 7760. The difference in generation of computers are quite large so there is a risk that it won’t work because the technoliogy between the two platforms are quite different. You will also need to make sure you have enough ram in the 9020 too. Finally on the 9020 you will need to swap out the spinning HDD for a SSD drive or running windows 10 on the 9020 will give an unhappy experience.

@foguser2018 Please start a new thread with pictures of how you have it setup. I understand your situation may be similar but your configuration may not be exact. To avoid confusing future readers we like to keep issues isolated if possible unless your conditions match exactly.