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.

@Sunks I use this method to clean out tasks and other odd database junk:
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

I really only do the first batch of cleanup commands in this link, deemed the safe ones to perform.

@davemccracken Not pointing at anyone here! Just good you know how it happened and it’s not something out of the blue or “FOG messed up”! 😉

@xburnerx00 said in Image not compressing:

I wanted ssd but people in charge dont think they’re worth it for old machines

They are looking at it from the wrong direction. For $60USD you can extend an old machine’s life for 2 more years. Then you move the SSD to a new old machine. There is very little price difference to not switch to an SSD. Understand that you don’t need a 500GB disk because most of that is wasted. Windows 10 is happy to fit in 70GB of space. So if you don’t have much data a 127GB or 256GB is more than enough.

But I understand what you are saying, its not your checkbook that pays the bills.

@Fernando-Gietz Thanks, now its working!

[EDIT: sorry didn’t see this marked as “solved”]

@jconway1006, not sure if you were able to get your web service back up.

After testing on CentOS, I found that 1.5.7 would not work, and I had to move to dev-branch (1.5.7.2)… not sure why, but it worked. Maybe a clean install on the VM server is best.

I’ve also noticed with VMware it frequently takes more than one try to get the iPXE connection. To get around it

boot to EFI bios and try PXE network boot

at each failed attempt, choose the shutdown option in blue screen

rinse and repeat

Found the issue! After some research and discussion with Cisco, we had to add “PIM” to the vlan on our core, even though both the server and client are both on the same vlan!

Used the command - ip pim sparse-dense-mode on vlan 1 interface and it started working like a charm! I really appreciate everyone’s assistance here. This will help our institution so very much.

I was using notepad ++. I guess creating the files from scratch uses the windows CR EOL format. I switched them all to LF and will never have this insanity happen again!

thx!