@Gamienator I am not sure if the Location Plugin will exactly match your needs. I was asking about this because it’s definitely worth looking into this for your kind of setup and on the other hand it might make a difference when we talk about adding ${storage-ip}.

I have not had the time to think this all through and work on the code though. I will try to do so over the weekend but won’t promise anything.

@Tom-Elliott Thanks again, I am by no means a Linux expert, I wouldn’t even be considered a novice.

Michael

@Sebastian-Roth That makes sense, to be honest, just didn’t think it would make a big difference. I actually followed those exact instructions to get UEFI working. All machines were able to boot to UEFI before. But now it’s just the one. The only thing that I changed was I reverted the changes I made for the driver injection that george1421 made. Now as I said only one machine that can boot with UEFI. It’s weird though, I can image the other machines with a UEFI format through the legacy Onboard NIC.

@george1421, @Sebastian-Roth

Thank you both VERY much! I just went and updated to 1.55 instead of doing the kernel update manually, figured it would probably be better in the long run. Now it appears to be working normally. Sorry I didn’t notice earlier the kernel wasn’t what I thought it was!

Solution my problem:

tips of Sebastian Roth: mkdir /home/fogbackup/ chown fogbackup:fogbackup /home/fogbackup/ change config file /etc/vsftpd/vsftpd.conf vsftpd_log_file=/var/log/vsftpd.log log_ftp_protocol=YES allow_writeable_chroot=YES chroot_local_user=YES chroot_list_enable=YES chroot_list_file=/etc/vsftpd.chroot_list rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem ssl_enable=YES force_local_data_ssl=NO force_local_logins_ssl=NO

@apollo40 Or you can use a postinit script to set the password: https://forums.fogproject.org/post/88286

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

reboot=pci

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 🙈