I’m having a hard time imagining it working as you say that it is. DHCP isn’t supposed to work that way.

From your description its not clear where its failing. Do you see the iPXE menu but when you select registration or such that is where you are seeing the attemp and the NAK?

I clear picture taking with a mobile phone would help set the context.

The target computer should only pull a dhcp address from the current subnet. There is no way that I know (outside dhcp reservations) to get an IP address outside of where the client is currently located.

If the client is being told something unexpected we can use wireshark with the capture filter of port 67 or port 68 to only capture the dhcp traffic. That wireshark computer only needs to be on the same subnet as the pxe booting computer to capture the traffic. I sure would like to see that pcap to better understand what the target computer is doing. You can either upload the pcap here, or upload it to a file share site and IM me the link and I will take a look at it. Please don’t mask out IP addresses because it makes it much harder to see who the actors are.

@nerdstburns Please take a picture of the error in screen and post that here. The notice on space is only a general message and does not necessarily apply in this case.

@nerdstburns Since the pxe booting computers are on a different subnet than the fog server, you will have to go the wireshark route.

Install wireshark on a 2nd computer on the gamers vlan. Setup a capture filter of port 67 or port 68 and then pxe boot a computer until you get the error.

The stop the wireshark capture. You should see a dhcp DISCOVER from the target computer and then one or more OFFERS from dhcp servers that heard the DISCOVER packet. Make sure you know these responding dhcp servers if you have more than one answer.

Look at the OFFER packet (in the center section) and expand it there should be an ethernet header section where you would have …

It may be just easier to post the pcap here or to a file share site and IM me the link. It would take me twice as long to type out what to look for than for me to just look at it.

@nerdstburns said in Updating Fog Server 1.x.x:

will I have problems updating to a stable version if I have 1.5.9RC2?

No you will not have issue the only thing you will need to do to switch back is this

git checkout master git pull cd bin ./installfog.sh

The current 1.5.9RC2 is very stable and there will (probably) be no (true) difference between 1.5.9RC2 and 1.5.9 GA other than the name change.

@D-Bandit Please check the state of the service by running systemctl status FOGSnapinReplicator. So you see any errors there?

@jenesis

I have resolved the issue , on my Nic configuration i had more than one IP Adress set , and that confused the ssl key creation process.
Once i went back to one ip adress , the keys were created and the setup complete.

I had to install fog through Squid proxy that i have setup , just for that. Because of the way my network is built.

Hope this helps some one.
Chears

@Mr_Jay84 Just be aware that if you want to pxe boot across subnets, then you will need to add the fog server as the last server in your vlan router’s dhcp-helper/dhcp-relay service. Once you do that then you can pxe boot across subnets if you need it.

@Sebastian-Roth said in New fog installation, stopping web service failed.:

@berndttoast23 said in New fog installation, stopping web service failed.:

Thanks for your reply, I took your advice but unfortunately it produced the same result. Any other ideas?

Did you really pull the very latest version via git?? As mentioned by George this changed was pushed only a few days ago and it’s not part of the last RC version but only the very latest from dev-branch.

Thank you @Sebastian-Roth! That worked!!

It’s working ! 🙂
Thanks.

@Sunks The screen shot you provided is the end results of what happened. It doesn’t really tell us the error itself.

So here is what I want you to do.

Schedule another capture/deploy (what ever you were doing) but before you hit the schedule task button, tick the debug checkbox on that same screen. Then pxe boot the target computer. You will be presented with several screens of text that you need to clear with the enter key. Eventually you will be dropped to a linux command prompt. This is debug mode.

Now we are going to single step through the capture deployment process. The process will pause a breakpoints in the code. You will need to press the enter key to move to the next breakpoint. You want to view the partclone screen(s). The error message will be scattered about the partclone screen, typically with white text with a black background. We will need to see this error. Grab a screen shot of this partclone error and post it here.

To start the process key in fog at the linux command prompt.

@george1421 Thank you for all your help!

I was able to get it to boot consistently by changing some adapters on the VM.

For the capturing image issue i resolved that as well.

An error has been detected!
Init Version: 20200517
e2fsck failed to check /dev/sda1 (shrinkPartition)

The solution was to remove the capture task and replace it with a debug task. Once in debug I ran fsck on the /dev/sda1 partition. Then I changed the image to Multiple Partition Image Single Disk Non resizable in the web GUI on the fog server.

Thanks again for all your help.

Jon

That error says that partition 4 is too small. So it seems to think that the image is bigger than the spin 5’s drive.
Looking at your image settings I’d recommend recapturing using partclone zstd at compression level 19. Probably won’t fix this problem, but might speed up your imaging while saving space on the server.

I believe the when fog captures the image it shrinks it down to only what is actually in use, so your scenario should work. Personally, as a fail safe, I use a 80 GB virtual disk size for my images which never had an issue deploying to 120 GB drives. Granted after a while we found that users with 120 GB drives ran out of space just from windows maintenance (updates, caches, etc.), well that and the users never deleting an email in outlook.

So if it’s feasible, maybe try recapturing the image with the virtual drive being smaller than anything in your environment. (80-120 GB perhaps).

So this issue is resolved?

I don’t know if this means anything but if I hover of the first column it shows this.
6a935ce0-623c-4f72-8fad-d30bd7a94be3-image.png

My workaround that has worked so far was to make the source image drive small, 28GB in my case, and it seems to always work now so long as the target drive is bigger, a complication with the last partition not wanting to be any closer to the beginning of the drive as it was on the source disk (i think), but it can be further away with no issues:

https://forums.fogproject.org/topic/14571/imaging-windows-10-v2004-with-uefi-gpt-partitions-onto-31gb-or-smaller-drive-and-failing/3

Correct, it is uploading properly now. Thanks for the assistance!