Posts made by george1421

@tigervince30 Well as I see it you have 2 problems. The first one is the files are not being copied over to the target computer the second is that the pnputil is not setup to run.

I would use the
. ${postdownpath}/fog.custominstall
over the
/images/postdownloadscripts/fog.custominstall
Just to keep the postdownload script portable between fog installs. Not all imaging directories are /images path. There is nothing wrong with calling out the full path, but the standard is to use the . ${postdownpath}

(Oh!!) I just saw something, you enter /images/postdownloadscripts/fog.custominstall you missed the leading dot-space (. ) . /images/postdownloadscripts/fog.custominstall That would impact the execution of the install.

So to debug the first problem, FOG has a specific debug mode that can be used to debug post install scripts. When you schedule a deployment you would tick the debug checkbox before you hit the Schedule Task button. Then pxe boot the target computer. That will place the target computer into debug mode. After a few screens of text that you need to clear with the enter key you will be dropped to a FOS Linux command prompt. At the command prompt key in fog and press enter to start the imaging. In debug mode the FOG install will stop at each breakpoint (debugPause) in the deployment process. This way you can watch and read error message that might happen during image deployment.

Now you might want to add an echo statement at the beginning of the fog.custominstall script and modify it such as this.

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
echo "Starting post install scirpt"
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"

Also looking at the code, if the $postdownpath path variable is not set the entire postinstall script will abort. Its possible that the missing dot calling the script would do this (not populate that variable). That is some magic missing dot ( . ).

During debugging you can exit out of the imaging script by pressing Ctrl-C. You can restart the imaging process without having to reboot by just keying in fog again. Your post install script should execute right after the last partition is imaged with PartClone.

@tigervince30 This is the most current tutorial on this: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Did you remember this part to hook all of those scripts into the postdown process?

fog.postdownload

The last bit of magic we need to do is update the FOG supplied script called fog.postdownload to call our custom script fog.custominstall

1.Insert at the bottom of the fog.postdownload script this line.

. ${postdownpath}/fog.custominstall

2.Save and exit your text editor.

If its hooked in correctly, after partclone finishes it should display “Identifying hardware” if the postinstall script is running.

If it runs there should be other error message related to the hardware being found or not.

@lebrun78 I can’t see from the config how/why its sending out the wrong router address unless something in include "/etc/dhcp/vip.conf"; is doing it.

Wait, there is something strange going on here. Look at the base address and the subnet mask as defined.

subnet 148.60.10.0 netmask 255.255.255.0 {
##########################################
option domain-name-servers 148.60.15.109,148.60.15.106 ;
option domain-name "istic.univ-rennes1.fr" ;
option routers 148.60.10.254 ;
option subnet-mask 255.255.255.0 ;
default-lease-time 600 ;
max-lease-time 1200 ;

group {
# On commente les deux lignes suivantes pour éviter le menu de Fog
        next-server 148.60.4.1;

But look at the pcap what the client is being told.

As you see in the picture the client is being told that its subnet mask is 255.255.248.0, but your config files says 255.255.255.0. The client is being told the router is 148.60.7.254 but your config file says 148.60.10.254.

So I’ll ask you the same question again in a different way. Is dhcp server 148.60.10.252 and 148.60.4.3 the same computer? If it is do you have 2 different instances of isc-dhcp server running, where each instance is bound to a different network interface? Something is strange with the 148.60.10.252 dhcp server.

@lebrun78 I’m going to have to look into this, but I have to ask the question why does the dhcp servers have two different IP addresses? Those each are listed in the pcaps.

Just to be clear, in the subject line of this post you have “do not copy drivers…” I can read this 2 different ways.

1. The drivers are not being copied from the FOG server to the target computer during the FOG deploy phase.
2. The drivers are copied to the hard drive of the target computer but not being copied into MS Windows during the WinSetup/OOBE phase.

Which is it?

pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install

This code should still inject the drivers. I’m using it with 1903 today. There is also a DISM similar command, but pnputil works for now. Its up to M$ to make or break stuff here. We can only try to find workaround for the stuff they do.

So to debug this a bit. On a system where the drivers are not deployed correctly.

1. Confirm that the drivers in their INF format is in the location that you defined.
2. From an elevated command prompt key in the pnputil command as you have it defined in your setupcomplete.cmd file. Do they install when you run the command interactively?

If it does, but doesn’t work during WinSetup/OOBE then are you sure the setupcomplete.cmd file is being called?

@lebrun78 said in UEFI pxe boot problem from a network:

I don’t understand the boot dhcp response on vlan 10.

Looking at the dhcp packet from your main dhcp server its giving out the wrong default router address for this subnet. So any computer that uses dhcp should not be able to connect to any device beyond its local subnet. Its impossible since the router its being told to use to leave the local subnet, is on a different subnet to start with.

You should contact your infrastructure staff and ask they to confirm the dhcp settings are correct for this subnet. If I had to guess, I would think they just copied the settings from the subnet where your FOG server is and pasted them into the vlan 10 subnet configuration and missed the router value. But that is only a guess made from 6600km away.

@lebrun78 Well I’m not sure how to explain this situation but @Sebastian-Roth is spot on.

First the easy part, it appears there are 2 dhcp servers (or configurations) involved here. The reason why I say that is that they are giving different responses to the pxe boot request. If you look at the pcap on the working subnet it responds with dhcp option 12, the not working pcap does not include dhcp option 12. This is only important to show there are different settings for these two pcaps.

Now to the hard part to explain.

On the working subnet
Client IP: 148.60.3.152
Subnet Mask: 255.255.248.0
Gateway: 148.60.7.254
Subnet Range: 148.60.0.1-148.60.7.254

On the not working subnet.
Client IP: 148.60.10.193
Subnet Mask: 255.255.248.0
Gateway: 148.60.7.254
Subnet Range: 148.60.8.1-148.60.15.254

So now to identify the problem. If you look at the not working subnet you will see the gateway IP address is outside of the usable range of the client’s IP address. The gateway address is 148.60.7.254 but the subnet base address is 148.60.8.0. So its not possible for the client to reach the router to get outside of the subnet to connect to the FOG server at 148.60.4.1. At this time the problem is infrastructure related and not FOG.

@Sebastian-Roth I agree, also in the pcap it has the bootp pxe boot information (in the header) but not the dhcp pxe boot options (66 & 67). Some target systems look at the ethernet header and others look at the dhcp options to boot.

I didn’t try to figure out the funky subnet mask (255.255.248.0) to make sure all of the subnets defined were in range. I figured everything was close enough it should work.

The short answer is no FOG can not decrypt or encrypt any form of hard disk protection. FOG can clone encrypted hard drives in RAW (read slow) mode. FOG will not be able to resize images created in RAW mode. So RAW mode is a sector by sector copy so your target drive needs to be exactly the same size as the source or larger than the source. You do have to be careful of encryption that use the TPM chip. These types of disks created with these encryption tools can’t be moved between computers with the drives encrypted. The FOG server can surely clone them, but the target system won’t boot if the TPM chips don’t match.

Typically you wouldn’t encrypt the source disk, and then launch the drive encryption on the deployed image via a GPO policy. At least that is how we did it using Symantec HDE.

Can you provide a clear screen shot of the problem taken with a mobile phone?

Also if you can follow the steps in this tutorial we can find out exactly what the target computer is being told to do. It really helps if the FOG server and target computer are on the same subnet to collect this pcap. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@ArmyHack said in Imaging a domain controller:

Could you explain how to capture a save state system?

This is my words for using FOG to backup your target system and restore it at some future time. FOG is not really intended to be a backup system. It can do it but its not the focus of FOG. If you don’t want fog changing bits in the target system don’t install the fog client on the target computer. Also Sebastian also mentioned to me that there is a setting in FOG Configuration -> FOG Settings -> General Settings called CHANGE HOSTNAME EARLY will also rename the target system during imaging.

If you want to leave the fog client installed on your target computer (for reasons like pushing out applications post OSD), under the Client Settings menu you can configure what the FOG Client software can and can’t do.

If the root password for mysql is lost then you will need to go through the password recovery process for mysql: https://support.rackspace.com/how-to/mysql-resetting-a-lost-mysql-root-password/

Make sure the password is set to a value. The developers were having issues with ubuntu getting cranky with no password for mysql and breaking the FOG install so with the later builds the root password is set by the FOG Admin and not recorded anywhere for security reasons. Its up to the FOG Admin to document the password elsewhere to ensure it doesn’t get lost.

@lebrun78 Please look at the forum chat (chat bubble at the top of the forum window) for a few questions based on the pcap.

@lebrun78 would you upload the entire pcap. I need to see the raw data and not just the packet headers.

@ArmyHack said in Imaging a domain controller:

Another question is it ok to use a single computer to capture all the images? I have a laptop that I am using to switch out hard drives and capture each image from

Yes you can do this, you will need to manage the host image definitions and change them up for each system you want to deploy. Really the action is not much different than sharing a usb network adapter between multiple computers. That ethernet adapter and mac address is what FOG uses to identify the target system. In your case you are sharing the same hardware among several hard disks. Its possible you will just have to manage the image associations manually.

@ArmyHack said in Imaging a domain controller:

am trying to capture an image of a Redhat Linux 6.9 computer and I have tried single disk resizeable and multiple partition image and both create and image but when restoring after it is complete it will not boot. It just goes to a black screen and blinks

As Sebastian posted if the disk is LVM based then FOG can only image the entire lvm volume and can’t compress it. You really have 2 choices that won’t impact the target system.

1. Rebuild your centos 6.9 system and use traditional partitions and not LVM volumes.
2. Keep your current build and use single disk non-resizable capture format.

@ArmyHack said in Imaging a domain controller:

I think what happened was for some reason the domain controller was getting renamed, does FOG rename the computer automatically to the name of the image that I capture.

This was my initial reaction when I first read your post, and why I asked how you were using FOG. My thought was if the computer was connected to AD (as a DC might be) and the system name was changed during imaging I could understand why its saying the system doesn’t have an account on the domain.

Now to your question: IF the fog client is installed AND the feature is enabled in FOG, AND the system name was changed (as in coming from a vm and going to a phy machine) then that would cause the issue.

That would also possibly explain why rebuilding the FOG server, things would magically start working. The previously captured images with the fog client installed would be tattooed to the previous FOG server’s certificate. Rebuilding the FOG server would create a new certificate making the fog client and server not agree to talk. This would cause the fog client to ignore the system rename instructions from the FOG server.

If you are creating a save state system, I would recommend that your client systems not use the FOG client so any fog server actions wouldn’t change the state of the machine post imaging. The fog client is only needed for post install management of the target computers. It has nothing to do with imaging with FOG.

@abulhol While this is a bit off point, I just rebuilt an intel NUC NUC5i5 with MDT. It built fine with MDT rebooting many times. I just ran sysprep powered it off and then back on and it sits at the NUC logo. I bounced through the bios setup exited and then it booted into the spinning marbles of Windows 10 setup.

@lebrun78 So let me see if I understand the issue.

On one vlan you can not pxe boot a uefi system, but on the same vlan you can pxe boot a bios based computer?

On a second vlan you can pxe boot both a uefi system and a bios based system no problem?

If that is the case I’d like to see a wireshark pcap of a uefi failed boot on the bad vlan. Use wireshark installed on a witness (extra) computer with a wireshark capture filter of port 67 or port 68

When you capture the power on and pxe boot of the target computer start wireshark, power on the computer and pxe boot to the error. Then stop wireshark and save the pcap. In the pcap you will see a dhcp discover from the target computer, then a dhcp offer from your main dhcp server. We need to look into that offer packet to see what the target computer is being told to boot. Upload the pcap here so we can look at it.