@george1421 @Sebastian-Roth Hello guys! I’m here to say that I had no problems loading tasks, neither capture or deploy, since I’ve updated the init files.

I’m using bzImage at latest version, did extensive tests on Legacy BIOS systems that were presenting the “rcu_sched” warnings and so far I’ve never saw them again or any other hanging issues.

If I can help with any othe kind of tests, please let me know.
Thanks everyone, awesome work!

@j_d As well I may ask you to validate the certificate is matching the CA:

openssl verify -CAfile /var/www/html/fog/management/other/ca.cert.pem /var/www/html/fog/management/other/ssl/srvpublic.crt

Should tell you OK.

From the client log you posted it clearly states to be a certificate/CA issue:

Middleware::Authentication ERROR: Certificate is not from FOG CA

@RobTitian16

I realize this is a few month’s old. But you might want to check out and or contribute to the fog module I have in git and published in the powershellgallery, there’s a forum post with more info here https://forums.fogproject.org/post/120746
Also did you have a chance to try the code I posted back in september and see if that worked? Because it works for me.
And looking again at your code I would ask what the value of $useAD is, is it 1 it should be 1. And I would also try piping the object into convertto-json, I’ve had better luck with that, I think it parses it different i.e. $CreateHostJson = $HostJson | ConvertTo-Json I would also encapsulate everything in quotes on the splat.
The only other thing that might be an issue is the ADPass. When you get the password via the api it is returned in plain text (because you already authenticated with api keys, so it’s not like just anyone can grab it). When you input the password in the gui you put it in plaintext and it encrypts when you hit save, I don’t think the same thing happens if you set it through the api. My solution has been to always enable the default AD settings when adding a host via the gui or the pxe menu. But it sounds like you’re adding the host through the api. The “useAD”=“1” in the json should be causing the checkbox for the ‘join domain after deploy’ to be checked. Sadly when you check it from the api it doesn’t pull the default domain settings. You might try creating the host without the AD settings and then sending just the AD settings in an update/put command. If you copy paste the already encrypted password from a working host in the gui, that might do the trick as it seems to pass whatever you put in that field to be in plaintext.

So point is, try adding the domain stuff with an update api command after creating. And use the code I have in the example to help if needed.

Thanks Sebastian,

The fog server ia a quad core 3.4GHZ with 32GB ram and uses a 4 TB sata drive to store these images on. It’s normal images are stored on a SSD array, its just because these aren’t used that often that they’re stored on a sata.

The clients are all 32GB 4/6 Cores @3.4 GHZ, single SSD disk with a dedicated 1 GB network.

The machines are usually used for just their PC’s image in the training room.

Any suggestions?

Thanks

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