@Sebastian-Roth

Of course I go back to take a picture to share and it works 100% right away no error… Not sure what happened.

Got it to happen again. And after this I couldn’t even see the nic in the PXE menu. Starting to think this is a machine / usb adapter issue not a FOG issue. Here’s the screenshot anyway:

IMG_3907.jpg

I rebuilt my master and slave from scratch. Everything worked as expected, this topic can be resolved.

Just close it. Maybe I’ll put together a Galera tutorial one of these days for FOG.

@ConJon @jmason As we haven’t heard from other users this being a problem I suspect pretty much all current UEFI firmwares are able to find Windows bootloaders by themselves and I don’t see why we should mess with this if there is no need for 99% of users. I’ll put this to the archive unless I hear otherwise from someone.

If you still see this issue talk to your mainboard manufacturer first to provide an updated UEFI firmware.

@processor I still have not found the time to look into this. Can you check if this is still the case or if replication picked it up?

@Dan_Ansel No problem, there’s so much to think about, it can be hard to figure out what’s going wrong!

@0juke You are more than welcome to help us improve this part of FOG. I don’t think we will find the time to add your suggestions in the near future. Just too many other things on the list.

The problem here is that you have 2 DHCP Servers.

192.168.6.15 and 192.168.6.152

@magikmw Glad to see you found and fixed this. It’s good to know you really know your way around in that network stuff. It’s very hard for us to diagnose and help out with that kind of things.

@Sebastian-Roth yes i checked and now works its fine

@Sebastian-Roth So good news and bad news. The bad news is that I am running a Ubuntu server. Good news is that the failed update appears to have saved me from problems. At least my server still seems to be functional. My other problem(my problem, not FOG problem it turns out, stupid fast boot), is fixed(crossed fingers) and I’m capturing with my 1.5.5 server right now. Guess I’ll wait to try updating again until 1.5.8 comes out. 🙂

Philip

Follow up discussion here: https://forums.fogproject.org/topic/13686/windows-10-deployment-stuck

@dobler555 Any news on this topic?

@zclift15 Any news on this?

@Redbob Any news on this?

The PCAP revealed that there were some left overs from an old software that would open an application on a public network share on boot up of that system. Removing that stuff fixed the issue and fog-client domain join works perfectly fine now again.

@Sebastian-Roth I’m currently using 1.5.7, but due to a little more thorough research, it appeared to be an issue with the apache webserver. After correcting the PHP time zone It now works as intended. Thank you for your help though.

@Mark-krikunov Did you actually verify that TCP port 445 is open on your clients?

for me using ubuntu server 18.04.03 LTS running MariaDB 10.1.41 and FOGPROJECT 1.5.7

this was the final solution

with the installation / upgrade of fogproject choose a password for mysql : type_here_your_fog_database_password

then make sure that password is the same as your mysql database:

login to mysql root with command = mysql -u root

then use following command to make passwords match fogproject

SET PASSWORD FOR ‘root’@‘localhost’ = PASSWORD(‘type_here_your_fog_database_password’);

Greetings

Jimmy

@Sebastian-Roth If my memory serves me correctly we did encode all of this for a little while, but too my knowledge we’ve moved away from encoding special characters in preference of using proper sanitization of inputs into the database. That’s not to say everything was fixed, but I’m pretty sure we moved away from this particularly because the & would get encoded as &amp, then the & in the &amp would get encoded, and so on and so forth.