Posts made by george1421

@tom Those errors are warning, and not a problem. The system should image fine.

@dpotesta50 said in Fresh Install of Fog - Setup PXE Boot:

The IP it has right now is 127.0.0.1

This is A or THE problem. 127.0.0.1 is a loop back address for a pseudo network adapter. You must give the FOG server a real IP address for your imaging network then reinstall FOG. The FOG services don’t like it when you change the IP address of the FOG server after FOG is installed.

As a side note, you can setup the fog server with 2 network interfaces. One will be for remote system management and the other one will be for a dedicated imaging network. Either way 127.0.0.1 is the wrong answer.

@kafluke So can you show me the node configuration of a remote storage node and the host configuration of a host that should image from that remote storage node?

Lets get a bit more information here.

1. What version of FOG are you using?
2. What device is providing your dhcp services?
3. From your fog server, please run and post the output of this command. ip addr show

Tell me this, do you have the location plugin installed on the master node? I kind of get the idea as yes, but I want to confirm.

@flipwalker As long as its not Win10 OEM then setupcomplete.cmd should execute as long as if its in the right location and you sysprep’d the image.

@george1421 rom-o-matic build image url for ipxe with

#undefine DOWNLOAD_PROTO_HTTPS
#undefine IMAGE_TRUST_CMD
#undefine CERT_CMD

https://rom-o-matic.eu/build.fcgi?BINARY=ipxe.efi&BINDIR=bin-x86_64-efi&REVISION=master&DEBUG=&EMBED.00script.ipxe=%23%21ipxe%0Aisset%20%24%7Bnet0/mac%7D%20%26%26%20ifopen%20net0%20%26%26%20dhcp%20net0%20%7C%7C%20goto%20dhcpnet1%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net0%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet1%0Aisset%20%24%7Bnet1/mac%7D%20%26%26%20ifopen%20net1%20%26%26%20dhcp%20net1%20%7C%7C%20goto%20dhcpnet2%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net1%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet2%0Aisset%20%24%7Bnet2/mac%7D%20%26%26%20ifopen%20net2%20%26%26%20dhcp%20net2%20%7C%7C%20goto%20dhcpall%0Aecho%20Received%20DHCP%20anser%20on%20infterface%20net2%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpall%0Adhcp%20%26%26%20goto%20proxycheck%20%7C%7C%20goto%20dhcperror%0A%0A%3Adhcperror%0Aprompt%20--key%20s%20--timeout%2010000%20DHCP%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot%0A%0A%3Aproxycheck%0Aisset%20%24%7Bproxydhcp/next-server%7D%20%26%26%20set%20next-server%20%24%7Bproxydhcp/next-server%7D%20%7C%7C%20goto%20nextservercheck%0A%0A%3Anextservercheck%0Aisset%20%24%7Bnext-server%7D%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Asetserv%0Aecho%20-n%20Please%20enter%20tftp%20server%3A%20%26%26%20read%20next-server%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Anetboot%0Achain%20tftp%3A//%24%7Bnext-server%7D/default.ipxe%20%7C%7C%0Aprompt%20--key%20s%20--timeout%2010000%20Chainloading%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot%0A&general.h/IMAGE_SCRIPT:=1&general.h/IMAGE_EFI:=1&general.h/IWMGMT_CMD:=0&general.h/NSLOOKUP_CMD:=1&general.h/TIME_CMD:=1&general.h/DIGEST_CMD:=1&general.h/LOTEST_CMD:=1&general.h/VLAN_CMD:=1&general.h/REBOOT_CMD:=1&general.h/POWEROFF_CMD:=1&general.h/PCI_CMD:=1&general.h/PARAM_CMD:=1&general.h/NEIGHBOUR_CMD:=1&general.h/PING_CMD:=1&general.h/CONSOLE_CMD:=1&general.h/NTP_CMD:=1&console.h/CONSOLE_FRAMEBUFFER:=1&general.h/ROM_BANNER_TIMEOUT=40%20&branding.h/PRODUCT_NAME=FOG%20Project&branding.h/PRODUCT_SHORT_NAME=FOG%20iPXE&

@flipwalker said in Windows Image Hangs on Boot:

So hypothetically speaking, if the reference image got joined to a domain by FOG(bad FOG, you should read my mind and only do that when I want you to), do I need to scrap it and start over?

Sorry to tell you this, but yes you must scrap that image. Because connecting your reference image to AD before sysprep will tattoo that machine in AD. Plus you may have GPO policies (that would be applied) that may interact with your system during OOBE. So its better off not to connect the reference image to AD then unconnect it before sysprep. It never ends well.

Now when you install the FOG client in the reference image, you need to set the service to disabled before your computer is rebooted (for any reason). This will keep the service from running and doing not so helpful things to your reference image. And you are right for the setupcomplete.cmd, use the sc command in there to set the FOG service to auto, and start it if you need. Here is a wiki article on the fog client with sysprep: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

I wonder if this is related to something that is currently affecting Hyper-V. https://forums.fogproject.org/topic/11348/hyper-v-and-pxe-boot-to-fog-problems

With that said, I was able to boot into iPXE on a vm in uefi mode using my uefi secure boot hack. Which kind of makes me think it could be related to the hyper-v certificate thing. I would be interesting to see if the FOG developers could create a test iPXE kernel with the mentioned modules missing to see if that would address the iPXE booting in VMWare uefi. If I have time this weekend I can/will create one by hand using the rom-o-matic site and test it.

@Sebastian just for your fyi.

The error tells you exactly what is wrong but not in clear terms. The issue is that windows was not shutdown correctly. Use either sysprep to power off the computer or turn off fast start mode. The issue is described here: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

DRBL is like (is) a diskless netboot server. This allows user computers to boot from the network without a local hard drive. The FOG Project does not supports. The FOG Project purpose is to capture and deploy disk images between the FOG server and target computers hard drive.

I can tell you that the FOG Project uses many of the same resources and DRBL. You can make FOG server act like a DRBL server. I wrote an article on how to make something similar to DRBL. Understand that the FOG Project developers do not support changing the function of FOG. But I can tell you it works. You will need a Linux Live OS that supports network booting and this tutorial: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Lets get some background information here.

1. What version of FOG are you using?
2. What is the output of this command executed from the console of your fog server. df -h
3. What is the manufacturer and model of the target computer
4. I’m guessing but this is your first upload to a new fog server?

The reasons the error message is so messed up is that it appears that partclone aborted the upload at 100%, which is a bit strange.

@uwpviolator Is this a virtual machine? If so what are the configuration (vCPU and memory)? What constructs the disk subsystem?

Now that you are running php-fpm, what is the top CPU hog? Is it mysql?

(my intuition is telling me this) I wonder if mysql needs to be optimized here or there is an underlying performance issue (like disk subsystem) that is being taxed causing the high CPU load. I did some benchmarking a while ago comparing different setups. I’m not saying that any of this is relevant to the case at hand, just trying to connect more data points Ref: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

@flipwalker Sorry working on a work project after hours.

Yes the firstlogon section is for activities you need to do that requires a command shell.

The setupcomplete.cmd file we do stuff like create admin user accounts (I know you can do that in the unattend.xml but we don’t) also we start the fog client in the setupcomplete.cmd so that the fog client doesn’t kick in too soon and botch OOBE (review the requirements for the FOG client in the wiki).

Connecting to a WAP and setting the preferred settings are easily done by GPO and is the preferred method.

Another point, don’t connect the reference image to AD before you sysprep it. If you need to execute things that need AD, do that in the setupcomplete.cmd or the first run.

[mod note] Marking as solve. I setup a teamviewer session with the OP and helped him fix this and a few other issues. At this point the OP is imaging as designed now.

@flipwalker said in Windows Image Hangs on Boot:

<ComputerName>%SerialNumber%</ComputerName>

I’m not sure that will work outside of MDT/WDS/SCCM. The %SerialNumber% is a MDT variable. Anyway, what ever you name it in the unattend.xml file, the FOG client will change it to what matches in the fog database. In my unattend.xml I think I have something like DEFAULT64 or something like that, again it doesn’t matter since the FOG client can and will change the host name to match how you have the system registered in FOG.

In my unattend.xml file I also have the windows system log in as a local admin and run a few commands and then reboot. This is all done in a hands off or also called lite touch method.

I remember now. I get the same as you… Nothing in uefi mode. Also remember what we did to capture the image.

We created a uefi image with MDT (our standard process). Then when we went to capture with FOG, we ran into this issue. So we switched to bios mode to capture the image. Then when we deployed to a physical machine in uefi mode it worked perfectly. So only capture from VM in bios mode was the trick (not the answer but the trick to keep moving). I have to go to a few meetings now. But I think I was working on something because I was able to uefi pxe boot into grub because that is what came up when I started the vm. I’ll look into that in a bit.

I can test this in my lab. I have esxi 6.5, but FOG 1.4.4 in our production environment. Let me setup a test to see if I can pxe boot a uefi system. I’m sure that I’ve done that before because we have a uefi image we captured.

I can tell you that you should to use the E1000 or E1000e network adapter to be safe.

In the end it wasn’t what FOG was doing, but the OP ran out of disk space on the root partition, and that caused mysql to not start. Flushing some failed uploads provided enough disks space to restart mysql and fog.

@keith75140 Well if you can get linux console access, the fog password should be captured in /opt/fog/.fogsettings

But if you have admin access on this server, just create a new linux user like fogadm and give that sudoer rights. Then start using that account for system administration and leave the fog user alone.