@dparsons said:

I have been receiving a persisting error message during PXE network boot …

Can you give us some more information on this. Usually when a client PXE boots and there is no FOG task scheduled for this host it will boot to the PXE menu and as a default chainload the OS from disk. You’d never run into the screen that you posted in the picture.

See if you still have a task scheduled in the FOG web UI (icon in the top menu that looks like a stack of three horizontal bars). Take a screenshot an post here.

The errors seen in the picture are most probably pointing to a hardware issue. Not something FOG is causing I think. What happens when you change boot order to directly boot from disk on this machine? Does it load Windows from the disk? Or is this a machine with an empty disk that you wanted to deploy your image to? We need more information on this to be able to help.

Here’s the setup guide that I followed originally to install FOG:
https://www.ceos3c.com/sysadmin/create-generalized-windows-10-image-deploy-fog-server/

This guide does not seem to talk much about the FOG installation itself. So I am wondering what exactly did you follow?! Just asking because the pictures show a very old version of FOG and I really hope you have a more recent version installed!

@Greg-Plamondon My fault, sorry for this. I just pushed a fix to the dev-branch. Please pull the latest changes any try again.

@AndrewC said in Dev branch fails install:

Changing or removing completely the password field from .fogsettings does not appear to affect this at all.

Just a quick info on that. The installer not only looks for an existing password in .fogsettings but also in .../fog/lib/fog/config.class.php. This has been in the code for some time but had a smaller issue because of the password being defined in the PHP file over multiple lines. Which working on the password stuff I also fixed this. Please let us know if you think we should only ever read an existing password from .fogsettings?!

@Fernando-Gietz @george1421 Oh, well now I just feel dumb. That’s on me. Sorry guys. And thank you

@Sebastian-Roth said in Clear Primary User and Other Tag Fields:

actually clear those fields for ALL your hosts! If you don’t have a backup, there is no way back after running tho

Perfect, exactly what I needed. Thank you!

Hi!
Thanks for your recommendations. Finally I’ve solved the issue with ```

Thanks!!

@Redbob Great stuff we figured this out so quickly. Hope you can dig up what was actually causing the issue for this particular IP address.

Could you check PCAP of 172.24.12.65? It’s here: new PCAP, just to understand it

What exactly are we looking for this time? For this client IP I see the TFTP transfer (default.ipxe) and next is a HTTP POST request (/fog/service/ipxe/boot.php) and a HTTP GET request (/fog/service/ipxe/bg.png) which seems fine from my point of view. The only thing I wonder is one last FIN,PSH,ACK in the TCP session but that is quite common as many clients simply drop the connection without closing it nicely.

@Sebastian-Roth Yeah, I just added an edit section to my previous post. This thread popped up with no responses after 19 hours. I didn’t understand how I missed this for 19 hours that’s why my response was a bit random, I was starting at the beginning. Very strange.

Thanks that worked!

@Reagan said:

Are these commands something I need to run every time I upgrade the FOG server?

Well that’s a good question. No, from my point of view, if you don’t recreate the certificates (extra installer parameters - shouldn’t use if you don’t know exactly what you do anyway) or move to use your own custom certificates (from an official or internal certificate authority), there is no need to rerun the build script.

By the way, I opened an issue to include the build process to the installer, so this manual run won’t be needed anymore. This will be part of the next official release.

Super that did work… thanks guys

Okay, everyone, I found the reason why it wasn’t working. @george1421 and @Sebastian-Roth it was NOT because I used /image1. It was a complete dumb reason!

I set up the server, that every HTTP traffic gets redirected to HTTPS. My dumb mistake: I forgot to setup SSL on the NODE! So it looks like that because I used https://fog.xyz/fog it trys to reach the nodes via SSL as well! After setting up SSL on the node, Boom:

743cb9f1-d24b-43be-9b87-02b945e58a28-image.png

So sorry for directing you on a complete wrong path 🙈

@Critchleyb Did you come to a conclusion with this or got a little further with the commands and ideas provided?

ok that was it… My server is back online after the updates. thank you so much.
.fogsettings changed the package to libcurl4 because the install was not a fresh install.

got it now thank you so much for the fast response.
Bill

@Sebastian-Roth Well I feel silly, I should’ve done that to start. Apologies for the stupid question, thanks and once backups are done updates are next on the list.

Yes.
Tasked Successfully
Task Wake-Up Successfully created!
Created Tasks For
“hostname”

@Sebastian-Roth Ok, it sounds good that things are looking normal, and I can wait on doing an update. I see your reasoning and agree with that philosophy, on step at a time. I’m also three days away from the semester start so have limited time to troubleshoot and communicate here. I have run a few test images and may have figured something out, I need to complete my testing and will let you know. Thanks again, this has all been so helpful!

@Tom-Elliott said in db_root: cannot open: /etc/target:

@kboutelle There’s the problem.

You have /images and /images2 mounting to the same File system ID. I believe nfs will use the 1st instance (in your case it’s mounting /images rather than your new share /images2.

Edit the /etc/exports file.

For your /images and /images/dev lines, prepend them with a # symbol. This will comment those lines.

That, or change the fsid of the /images2 and /images2/dev to have 2 and 3 respectively.

Then restart the nfs service, systemctl restart nfsd

I can’t believe I missed that. Edited, going to try again.

Deployment is proceeding as it should.

Thank you all for taking the time to help.