I set up a new virtual machine using Microsoft’s new scripts.

Then I captured an image from the virtual machine with FOG and multicast it to four computers, and they all UEFI booted fine.

The new CreatePartitions-UEFI.txt puts the system partition first, instead of the recovery tools partition. This supports @george1421’s theory that FOG was confused when it found the recovery tools in the first partition, instead of the EFI (“System”) partition.

Thank you for your help!

rem == CreatePartitions-UEFI.txt == rem == These commands are used with DiskPart to rem create four partitions rem for a UEFI/GPT-based PC. rem Adjust the partition sizes to fill the drive rem as necessary. == select disk 0 clean convert gpt rem == 1. System partition ========================= create partition efi size=100 rem ** NOTE: For Advanced Format 4Kn drives, rem change this value to size = 260 ** format quick fs=fat32 label="System" assign letter="S" rem == 2. Microsoft Reserved (MSR) partition ======= create partition msr size=16 rem == 3. Windows partition ======================== rem == a. Create the Windows partition ========== create partition primary rem == b. Create space for the recovery tools === rem ** Update this size to match the size of rem the recovery tools (winre.wim) rem plus some free space. shrink minimum=500 rem == c. Prepare the Windows partition ========= format quick fs=ntfs label="Windows" assign letter="W" rem === 4. Recovery partition ====================== create partition primary format quick fs=ntfs label="Recovery" assign letter="R" set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" gpt attributes=0x8000000000000001 list volume exit

@El_Pagrxn27 I guess I’m doing a terrible job explaining what I see.

If we refer to the picture you provided. You see /dev/sda is exactly as you say the 1TB hard drive connected to sata5. Also you see that /dev/sdb is exactly as you say the 256GB drive. Now what I’m saying is the partition layout for both the 256GB and 1TB drive are exactly the same. So something happened here. I would expect /dev/sda3 to be ~900GB in size, not 256GB unless this is how its configured on the source computer. I would say the layout that is on /dev/sdb is a typical windows boot image format.

disksize.png

I’m suspecting some how the image for disk /dev/sdb was overwritten onto /dev/sda. This is why the target computer will not boot.

While I understand this is how your fleet of computers are currently setup, the configuration is a bit uncommon. The more common approach is that the boot/OS disk to be on /dev/sda (i.e. lowest sata port number) and the storage disk to be on some sata port number higher than /dev/sda (5 in this case). Now understand that it is possible to have the OS disk setup like you have it and work, but FOG may be making an assumption that you have a default design. I don’t know this bit yet. Right now I’m having a hard time understanding why both disks have exactly the same partition layout.

@hancocza Ah sorry, I thought you’d know how to do that.

Go to the directory where you usually run the installer from, I’ll just use /root/fogproject her in the example but make sure you use what you have on your system extracted already.

cd /root/fogproject/utils/FOGiPXE/ ./buildipxe.sh /etc/ssl/certs/Certs/gd_bundle-g2-g1.crt cd ../../packages/tftp/ find -type f -exec cp -Rfv {} /tftpboot/{} \;

This is partly outlined in the wiki but still needs more consideration: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

@Tom-Elliott
Ok, thank you for you answer.

@george1421 Thanks again

@UWPVIOLATOR said in Error trying to restore GPT partition tables. Exit returned code 4:

CentOS Linux 7.7.1908
FOG 1.5.6

Close this. I am pretty sure it was my connection where I was uploading and testing. It was having issues thus giving me errors.

I find the service that wasn’t lauched. “service de la passerelle de la couche application”
Fog Service is ok and computer joined domain

Thanks

Here are dependency
fog service.PNG fog service2.PNG
3043296f-e3a2-439d-8198-92ad5cae185b-image.png
5e4a3899-aa40-4c67-a1c8-b4719653fd6e-image.png

Ok, many thanks, I will continue with 1.5.9rc2

@Wayne-Workman What has happened is mariadb starting at version 10 (?? I think) added some default values to mysql startup that are causing an issue with some of FOG’s default values (such as 0’s in date fields) I think we need to update the schema to use a invalid, but valid date of something like 1/1/1900 instead of 0/0/0000 as an unset date.

Again its not a problem with the renumber script, but the default startup values used for the sql server that was introduced with the later releases of mariadb.

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