@byu13 It’s interesting it doesn’t print out more details when it fails on the sgdisk call. I though I had added some more debug output especially for this case as we get this every now and then… Maybe it’s just further up the screen. Anyhow.

Please schedule another deploy task for this machine but make sure you enable the checkbox for debug just before you hit the create task button. Boot the host, hit ENTER twice to get to the shell and start deploying using the command fog. Step through till you hit the error again which should bring you back to the command shell. Then run this manually: sgdisk -gl /images/Windows10_SysPrep/d1.mbr /dev/sda, take a picture of the screen and post here.

With that partition layout your destination disk needs to be at least 477 GB (last-lba: 1000215182 * 512 byte sector size / 1024 / 1024 / 1024)!

@dskinner Ok since it DOES work somewhere on your site there is also another possibility that an unexpected dhcp server or proxydhcp server is messing with booting on the same vlan as the fog server. So lets help your network engineers. Lets grab a pcap (packet capture) of the pxe booting process on the same vlan as the fog server. To do this we’ll use the fog server to run tcpdump (packet capture on). This program will capture the dhcp processes of the pxe booting computer as well as the file transfer of the boot loader (ipxe.efi/undionly.kpxe).

I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

You can review the output pcap with wireshark. You can take the pcap to your network engineers, review it your self, or post the pcap to a file share site and either pm me the link or post the link in the forum.

I’ll tell you what you should be seeing. The dhcp process is pretty simple. There is a DHCP DISCOVER packet from the target computer, there is an OFFER from one or more DHCP servers (this is where I would focus, ensure the responding dhcp servers are correct and have the correct settings in place in the dhcp options section), a DHCP REQUEST from the target computer and then finally an ACK from the dhcp server. So this part of the process should only take 4 network packets. If there are more or repeating requests or offers then I would look into that. Once the dhcp process is done then the pxe booting part starts. The target computer will take the name of the boot loader (option 67) and the boot server (option 66) given by the dhcp server and request that file via tftp from the boot server. You should see one initial request for just the file size from the pxe booting client to the tftp server then the client will ask for the boot loader file itself.

@george1421 said:

No/maybe. Replication will happen on all enabled images. If only one image is enabled in the image manager then only that image will be replicated. No. The fog image replicator will only replicate images and snapins between the master node and the storage node.

@eseelke You might want to setup your own replication for those using cron and rsync.

While I haven’t tested this, but if you have the location plugin installed and the target computer has been assigned to the remote location one might think that the variable ${fog-ip} would point to the proper server.

@eseelke Sorry but ${fog-ip} is always pointing to the main FOG server. But adding another variable for the storage node should not be too complicated. I am on the road right now and don’t have my working laptop with me so I can’t test. But take a look at the boot menu code in /var/www/html/fog/lib/fog/bootmenu.class.php - after line 388 add this code:

$Send['storageip'] = array("set storage-ip $StorageNode->get('ip')"); $this->_parseMe($Send);

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