@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!

@george1421 This is just a very bad guess since I can’t test this at all.

net0.dhcp/43:hex = 6010B080FAAAA03C0A802C8C0A80368C0A8016600 net0.dhcp/60:string = PXEClient

I’m more confident that net0.dhcp/60:string = PXEClient will work than the the option 43 one.

net0.dhcp/43:hex = 6010B080FAAAA03C0A802C8C0A80368C0A8016600 net0.dhcp/60:string = PXEClient set altiris-server:ipv4 10.96.50.15 set net0/next-server ${altiris-server} cpuid --ext 29 && set arch x64 || set arch x86pc iseq ${platform} efi && set plat efi || set plat 0 chain -ar tftp://${altiris-server}/BStrap\\${arch}\\BStrap.${plat} boot || goto MENU

Our master server and one storage node is on 1.4.4
the two newer storage nodes, both having the same problem as described, are on 1.5.2

We have had issues in the past upgrading hence the mixed versions.

Thanks.

Hi once again!

Our problem, as it stands today, is solved. We ended up trying to install the FOG server on the same subnet with the host machines, which worked. After that we tried putting the machine back on the subnet where all our VMs are located. That broke it. Later the network admin realized that during his configuration he accidentally left a space after the IP on option 66. After that was fixed things stated working out.

So in the end what I was chasing was a typo.

A big thanks to @george1421 for being as helpful as You could during the troubleshooting process.

I am now happily deploying my Windows 10 images. 🙂

Thanks a lot guys !
Let(s go updating ! 🙂

@quazz
That worked!

@fog_rob Were you able to resolve this issue? I didn’t see any responses so I’m almost tempted to just reinstall from scratch. Even with update to 1.5.3 the issue persists for me.

I follow with my problem 😞
I think that the best option is ask this new feature 🙂

@george1421
Ok great

@bretfred https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Yea not sure why the shrunk partition is listing the same size as the resizable one. So I went ahead and deleted the second recovery partition. Recaptured the image as not resizeable. Was able to get it to restore to the smaller drive. Even after i recaptured it still showed the data partition as 64GB not sure why but hey it worked. Thanks for your help.

Hola @Joe-Schmitt ,

Both. My gold image installs the client during the sysprep and, normally, the technician uses an image with the client installed.

I have other question 🙂
If I update the server version, is necessary reset the encryption data?

It looks better afin reinstall of the clients ! 🙂

I had to do several times the mysql command :

UPDATE hosts SET hostPubKey="", hostSecToken="", hostSecTime="2018-05-29 09:47:07";

BUT it works.

Thanks.

NB : i don’t know how to mark the topic as “solved”

@sebastian-roth
Thanks to the suggestion, the tcpdump software helped me to understand that the host did not send any data packet to the FOG server during the closing phase of the snap-in. All this was due to the fact that my script assigns a static IP to the Host when certain parameters occur, so, in the IP assignment phase, the Host was offline and the snap-in was unable to communicate with the FOG server. So I solved the problem by inserting a 10-second pause in the script with the powershell start-sleep command, allowing the Host to return online before closing the snap-in.
I wanted to thank you for your availability and tell you that you are doing a great job with FOG.

@george1421 That is good to know, I will then probably try to update the kernel every once in a while…

I currently have Win 1709 and use Proxmox, let’s hope that there will be no problems 😉

What goes wrong with your storage node?

What are you trying to accomplish? Deploy from different storage nodes in different locations? (read up on location plugin if you haven’t already)

How did I miss this??
Thanks man, it was the password thing.

Simple fix. awesome I’m up and running.

how do I mark as resolved?

@Sebastian-Roth Yes it does return. I even see a ton of data being downloaded. I have cut off the data towards the end due to the length of the capture.

563 13.682607 10.86.96.177 10.85.195.199 TCP 74 50514 > 8080 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1729539897 TSecr=0 WS=128 569 13.742557 10.85.195.199 10.86.96.177 TCP 78 8080 > 50514 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=400875488 TSecr=1729539897 WS=64 570 13.742594 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1729539912 TSecr=400875488 571 13.742693 10.86.96.177 10.85.195.199 HTTP 161 CONNECT fogproject.org:443 HTTP/1.1 575 13.801898 10.85.195.199 10.86.96.177 TCP 66 [TCP Window Update] 8080 > 50514 [ACK] Seq=1 Ack=1 Win=771008 Len=0 TSval=400875548 TSecr=1729539912 576 13.864407 10.85.195.199 10.86.96.177 HTTP 105 HTTP/1.1 200 Connection established 577 13.864424 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=96 Ack=40 Win=29312 Len=0 TSval=1729539942 TSecr=400875608 579 13.87112 10.86.96.177 10.85.195.199 TLSv1.2 583 Client Hello 582 13.992592 10.85.195.199 10.86.96.177 TLSv1.2 1414 Server Hello 583 13.992609 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=1388 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 584 13.992616 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=613 Ack=1488 Win=32128 Len=0 TSval=1729539974 TSecr=400875738 585 13.992893 10.85.195.199 10.86.96.177 TCP 1414 8080 > 50514 [ACK] Seq=1488 Ack=613 Win=771008 Len=1348 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 586 13.992908 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=2836 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 587 13.992916 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=613 Ack=2936 Win=35072 Len=0 TSval=1729539974 TSecr=400875738 588 13.992928 10.85.195.199 10.86.96.177 TLSv1.2 640 Certificate, Server Key Exchange, Server Hello Done 589 13.995298 10.86.96.177 10.85.195.199 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 593 14.114585 10.85.195.199 10.86.96.177 TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message 594 14.114752 10.86.96.177 10.85.195.199 TLSv1.2 182 Application Data 598 14.237584 10.85.195.199 10.86.96.177 TCP 1414 8080 > 50514 [ACK] Seq=3561 Ack=855 Win=771008 Len=1348 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU] 599 14.237599 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=4909 Ack=855 Win=771008 Len=100 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU] 600 14.237607 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=855 Ack=5009 Win=40704 Len=0 TSval=1729540036 TSecr=400875988 ...... ..... .... ...

@FlareImp I guess you need to elaborate a bit more on how your whole network is structured for us to be able to understand and give appropriate information.