@bnorwood Then you can either try older iPXE binaries. Go to github and pick an earlier commit from this list: https://github.com/FOGProject/fogproject/commits/master/packages/tftp - use the < > button to browse the repository at that stage and grab the binaries from packages/tftp/…

If you can’t find a working binary you’ll probably need to get into debugging it as suggested in the topic mentioned in my last post.

@Jim-Holcomb Great to hear! Keep us posted. I won’t be online much in the next two days though…

@the_duke You are getting an rpc error that indicates the showmount command could not connect to the server on its loopback interface. So that tells me that nfs is not installed for some reason or the services needed for nfs are not running. I don’t know ubuntu so I can’t give you step by step checks. But if showmount -e 127.0.0.1 is giving an RPC error then its not talking.

You can also review the /etc/exports file but the shares are not the problem at the moment.

@JYost Oh well, I was too quick looking at this without noticing the first part of it being really old. Next try:

6/5/2020 2:42:30 PM HostnameChanger Checking Hostname 6/5/2020 2:42:30 PM HostnameChanger Renaming host to HE-L002107 6/5/2020 2:42:30 PM HostnameChanger Joining domain 6/5/2020 2:42:35 PM HostnameChanger Success, code = 0 6/5/2020 2:42:35 PM Power Creating shutdown command in 60 seconds

Looks pretty good to me so far. And from then on the rest of the log shows:

6/5/2020 2:46:22 PM HostnameChanger Checking Hostname 6/5/2020 2:46:22 PM HostnameChanger Hostname is correct 6/5/2020 2:46:22 PM HostnameChanger Attempting to join domain 6/5/2020 2:46:22 PM HostnameChanger Host already joined to target domain

So I can only guess on what you mean by “not entirely sure what the error messages should be telling me”. Guess you mean these log entries:

6/5/2020 2:38 PM Client-Info Version: 0.11.15 6/5/2020 2:38 PM Client-Info OS: Windows 6/5/2020 2:38 PM Middleware::Authentication Waiting for authentication timeout to pass 6/5/2020 2:40 PM Middleware::Communication Download: http://10.6.190.155/fog/management/other/ssl/srvpublic.crt 6/5/2020 2:40 PM Data::RSA FOG Server CA cert found 6/5/2020 2:40 PM Data::RSA ERROR: Certificate validation failed 6/5/2020 2:40 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid) 6/5/2020 2:40 PM Middleware::Authentication ERROR: Could not authenticate 6/5/2020 2:40 PM Middleware::Authentication ERROR: Certificate is not from FOG CA

The fog-client installed on this machine was pinned to a FOG server different to the one it is talking to right now. I suppose you switched your certificates or FOG server some time between installing this fog-client (0.11.15) and letting it talk to it now. Good news is that the fog-client figured there is an update (version 0.11.19 in the logs from then on), installed that and re-pinned to the current FOG server which essentially fixed the problem.

which brings to mind another question…why are there still fog.log entries from back in March and then appended with the log entries from Friday?

This means the fog-client on this machine (or your master??) has been running in March or the date/time of this machine was way off.

After digging through the logs Hanz found that mysql_upgrade needed to be called to fix this issue. It’s very interesting we have not had too many people running into this but I am sure this is valuable information for others seeing this.

@Taspharel Only when initially created yes. I don’t think it resets the permissions after.

@Sebastian-Roth I search for " realtek undi driver" for fog in google and i found a page in the forum with this link in the tftp in the 1.4.4 section.
It was missing in the 1.5.8. i just add it.

@Sebastian-Roth Perhaps not for the MBR issue; but certainly for the resize issue.

@kyokushin Please schedule a debug task and boot the machine again. Then when you get to the shell run the following commands:

ip a s dhclient -v -r enp0s1 ip a s

Now I see, this is just a copy&paste from an old topic… https://forums.fogproject.org/topic/988/fog_disable_chkdsk-setting

@Bienxanh Why do you waste our time I wonder?

@Sebastian-Roth said in API - Create Host Deploy Task "error": "Invalid tasking type passed":

@Jamaal From the error message I would imagine that this last call is failing because an earlier query also failed and variables are not being set correctly because of the earlier error. So you need to post the full error you see!

I am not a PowerShell wiz but from what I know the read-host stuff you added should work.

Thanks man, you pointed me in the right direction.
So I went back to your script again and ran it and noticed it kept giving an error message after the 1st throw command, like Powershell was skipping the 2nd and 3rd throw command.

What I had to do was do a read-host, but kept the $ (read-host “enter machine name”) for example:

[String] $MachineName = $( read-host “Provide the target machines Name”),
[String] $MacAddress = $(Read-Host “Provide the target machine Address”),
[String] $ImageName = $(read-host “Provide the Image Name to assign to the new target host”)
So I saw the task in the task list right away. I’m so so with powershell and starting to get better with it, you know. What I would like to do is maybe figure out powershell commands to add the snapins as a read-host so the tech can select which snapins to use instead of going to the Fog console to be more automatic.

And I would like Powershell to start the task once the hostname is added to Fog. I can start playing around that.

@george1421 I think I follow, I’ll give it a bash and let you know, thank you :).

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

Thank you for this information. I will have to come back to this at a later date though. I really do want to continue with this but our school district is in the middle of preparing machines and we’re relying on FOG heavily right now. I am not a Linux user so everything is new to me right now, so if we lose FOG, it will set us back a bit. Once projects are done I will come back to this. Thanks again.

@lebrun78 said in https, with home certificates and boot.php… No such file or directory (http://ipxe.org/2d0c613b):

./installfog.sh -C -K

I really hope you don’t use the fog-client software as re-generating the internal CA will break all communication to the fog-clients.

I modified /etc/httpd/conf.d/fog.conf with…

This will be overwritten as soon as you re-run the FOG installer. I know this part of FOG needs some more attention but I can’t find the time to get into all of this. So I lost track of the SSL stuff a few weeks ago. Will need to work on the wiki article about this again: https://wiki.fogproject.org/wiki/index.php?title=HTTPS (this is not ready-set-go yet)

I tried to generate a new ipxe configuration
cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh

You will need to specify your CA cert on the command line when building and manually copy the binaries over after that, e.g.:

cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/ ./buildipxe.sh /etc/httpd/cert/DigiCertCA.crt cd ../../packages/tftp/ find -type f -exec cp -Rfv {} /tftpboot/{} \;

@mhx Ok then lets extend a bit on what Sebastian suggested. Right now the main issue is PXE booting into FOG, and your firmware’s absence of a uefi network stack. So what we are going to attempt is to supplement your firmware by booting the iPXE boot loader directly from a uefi bootable memory stick using this process: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

typically the PXE rom in your network adapter reaches out via bootp and downloads the iPXE boot loader from the network, in this case we are going to load it directly from the USB flash drive. That flash drive can be tiny in todays standards. The iPXE boot loader can easily fit on a 512MB flash device. There is no need for anything bigger since it will be just a waste of empty space.

Finally added the simple route of HTTP redirect via index.php (99a407e and ad2813ab).

Perfect @george1421! I’ll give it a whirl, thank you.

@foggystarz You might want to look through this thread for ideas for pxe booting recovery media with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/3?_=1590418175520

@Derek-Newbold As a very first step I may ask you to post a picture of the error that you see on screen when an image does not properly deploy “due to image size being set to 0”.

While I can’t be absolutely sure (there have been many changes and fixes since FOG 1.5.4) I am not aware of the image size playing any role when deploying an image to a host! It’s true that in FOG 1.5.4 the image size on client field is being updated and set to 0 if it fails deploying and that is something strange we fixed lately. It will only ever do this on captures now.

Nevertheless I don’t think the image size should influence the deployment process in any way. Please provide error messages.