@misterjroc First let me start out by shaming you. Masking a private IP address range doesn’t help us help you. There is no way if I was a hacker to know how to reach a 192.168.x.x subnet from the internet. If you were debugging using a public IP address (as in an internet address then I would suggest masking the address).

Since you mentioned the tftp address is your router/isp router I can make a few guesses.

SoHo routers are broken in that they almost aways give our their IP address as the dhcp next-server address even if they let you define a next-server value (the exceptions I’ve seen are ddwrt/openwrt and pfsense those work correctly). You have 2 dhcp servers on your subnet. One is your isp router and the second one is your 2019 server.

Two routers would explain this condition you explained. You are getting into the iPXE boot loader so your main dhcp server (Windows 2019) IS working because the iPXE boot loader is running, Inside of iPXE it once again issues a dhcp request to find the IP address of what it thinks is the FOG server. In this case your ISP router is returning the query faster than 2019 server. So your router is winning and iPXE tries to connect to your router instead of your fog server.

OK so prove me right or wrong, here is what I want you to do. On a third computer (witness computer) install wireshark. Its probably best of this witness computer is on the same wired network. Use the following capture filter inside wireshark port 67 or port 68. Start wireshark capture, then pxe boot the target computer. You will see a complete DORA cycle (DISCOVER, OFFER, REQUEST, ACK) This will be the pxe rom on the target computer getting the info to load iPXE, then when iPXE starts you will see the DORA sequence again. PXE boot to the error above. Now stop wireshark. If you have one or more OFFER packets those packets come from DHCP servers that heard the DISCOVER packet. If you only have one OFFER packet then we need to dig deeper. I’m thinking you will see two or more OFFER packets. The sending IP address will be listed in the OFFER packet.

@littleman1234 Well that’s one way to create a golden image. There are a few things I probably would do differently to make things go smoother and repeatable every time the golden image needs to be recreated (as each new windows 10 release is released).

How about building your image using a VM? That way you get a hardware agnostic mother image. How about using MDT to automate the Golden Image creation. Use the light touch method of image deployment or if you are old enough the Ron Popeil “set it and forget it” method. In this approach you automate the windows 10 image build, install windows updates, install any global applications, make any windows settings (understand that windows 10 will reset anything to do with user profiles in sysprep) and prepare the system for sysprepping. Just a few dos and don’ts
3.1 DO NOT let the computer connect to the internet, also set windows update to only talk to wsus server and not get updates from other windows 10 computers (i.e. turn off delivery optimization).
3.2 DO NOT connect the computer to AD (ever before sysprepping)
3.3 DO NOT install programs that are unique guid based before image capture. This would be programs like enterprise antivirus or serialized applications. Use the setupcomplete.cmd batch file to do any post image deployment customizations. This is the only way to undo some of the things microsoft reset when sysprep is run. Run sysprep with a customer answer file and power off the computer. Capture with FOG Deploy with FOG If you want hardware specific drivers pushed out you can do that with a fog post install script. And then have the setupcomplete.cmd file run the pnputil command to load them into windows during OOBE/WinSetup.

Using the above process I can build a new windows 10 image from dvd in about 50 minutes. Actual hands on time is about 7 minutes from powering on the computer to manually running the sysprep image and powering off the vm at the end. The 50 minutes includes installing 8 common company wide applications as well as windows updates in an automated manner.

Now with that said it did take me about 3 days when I first started working with MDT to get what I wanted as in a solid golden image. So its not just turn MDT on and it spits out an image. There is real work involved with setting it up the first time.

BUT I have to say what ever method works for you is OK. The double sysprep is not necessary in my opinion. Also I’ve never had a good image if I let the computer connect to AD. Doing so tattoos the golden image with AD settings, so I would avoid it until you have the golden image deployed to the target computer.

@migsterzs Can you please post your fog-client log here so we see the actually calls and might be able to help.

@markg said in SSH login while imaging:

I’ve no problem with them all having the same password so that was really easy

Just understand that the password you set will not be persistent in that once FOS Linux reboots it will go back to its default password since FOS Linux itself is not persistent or has any persistent storage. You can surely do what you need with a post init script. We also use post init scripts to setup specific hardware/software combinations like software raid solutions and such before imaging can begin.

@Fogger2021 Sure this is an issue caused by FOG? Please take a picture of the error on screen and post that here in case the answer to my question is a yes.

@kayotte said in Lenovo Thinkpad E14 Gen 2 Issues:

I noticed that now deploying old images on old laptops is also having this same problem not joining the domain. Is it possible that the fog update I ran could’ve changed something?

It’s probably best you open a new topic for this as it doesn’t seem to be related to the issue you had before. Please grab the fog-client log file (C:\fog.log) and post that (upload to a file share). I am pretty sure we’ll find why it doesn’t join in there. As well you might also add more information on details like sysprep or what else you do to prepare your image.

@blu3h4t I see a lot of references here, but I’m not sure what your problem is.

I can tell you from the start that FOG doesn’t support secure booting (generally). To image with FOG you need to have secure boot disabled.

So if you are having a secure boot processing issue inside windows that isn’t a FOG thing.

@jclumbo33 said in Can't get UEFI to PXE boot:

You are correct, the VLAN that it works on uses a /16 subnet. That’s interesting, so we could potentially be screwed without redoing our network then?

I am not saying your network is at fault. I might be partly causing what you see but in fact it would be a firmware issue. Before you even think about redoing your network I suggest you setup a test VLAN where you can try out if non-default subnet masks are actually causing this problem.

Here’s an idea of maybe a workaround? Our fog server is running in Hyper-V. If I add a NIC to the VM and put it on each VLAN we need, then point the DHCP options to the new IP address on the same VLAN, would that potentially act as a work around? And is that even possible to configure fog with multiple NICs like that? Just a thought.

Not a good idea. FOG needs a specific network interface and IP to be able to properly work.

@gooses ok a couple of things here.

WDS uses proxydhcp requests. The is only relevent if your wds server is sending this boot information to your fog environment. This would be managed by your dhcp-helper service on your subnet router. If you are pxe booting into FOG OK then you can ignore this bit, I’m only posting it because I have seen conflicts with wds/sccm/fog in the same environment. This is because proxydhcp overrides dhcp option 66 and 67.

Now to pxe boot bios based computers you would setup dhcp option 67 to be undionly.kpxe. For uefi systems you would setup dhcp option 67 to be ipxe.efi or snponly.efi. You can not boot a bios based computer with a uefi boot loader, the same is true for booting a uefi based computer with a bios boot loader (which i’m guessing is the root of your issue).

The FOG Project also has a wiki page that describes how to configure a windows 2012 or later dhcp server to support dynamic pxe booting of both uefi and bios based computers. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

The other option is to install dnsmasq on your fog server and let the fog server send out pxe boot info (only) on your imaging network. In this role your main dhcp server still issues IP addresses, just the pxe boot info comes from the fog server: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server One possible use case for dnsmasq is if you have a dhcp server that can’t be modified or one that doesn’t support dhcp dynamic pxe booting.

@sebastian-roth Hi there
we’ve done some testing and found that non resizeable seems to move between different size disks and puts the partition size back to 200gb

i think this should do the trick

@it-walrus said in Window 10 will not boot after image:

The computer restarted unexpectedly or encountered an unexpected error.

I have seen this quite a while ago if the installation of a driver or something else causes widows to reboot out of order. I can tell you this can be a PAIN to try to debug. The problem typically had nothing to do with FOG, but something I did to the image, fog just faithfully duplicated the image.

There are logs you can look at to see exactly where imaging has failed. When you are at the screen that says windows unexpectedly restarted you can hit a hot key combination to get a command window (maybe alt-f10 but check because its been about 6 years since I caused that issue). From the command window you can open notepad and then look at the imaging log files (google the location of these files too).

@hsikkema said in newbie: imaging:

Are you saying that I should NOT run sysprep at all once I have the system setup

No you should run sysprep if you want to deploy one mother image to many target systems. What I’m saying is that sysprep and windows 10 work a bit differently then sysprep and win7. Where in windows 7 you could setup the system exactly like you wanted it and clone it to many systems. With win10 M$ says, <snark> they know better than you </snark>. Where OOBE will reset somethings that you setup during the creation of the golden image. So if you set the system one way in the golden image and then once deployed the values are reset blame it on Microsoft. To get around this system reset you can fix it again using the setupcomplete.cmd file (google it) and setting in the unattend.xml file. You need sysprep to reset the system guid and some other settings used by management programs. Also to prepare the system for deploying to different hardware platforms.

I say this with some hesitation because I understand the meanings, but if you have a golden image on a Dell 9410 and you will clone that image to other 9410s you really don’t “need” to sysprep the image. This is because all of the hardware drivers needed for the target system are already on the computer. But lets say you wanted to deploy that Dell 9410 image to a Lenovo thinkpad? In this case you MUST sysprep the system.

Imaging is a ballancing act between what microsoft things you need, plus settings in the unattend.xml file and then finally corrections you might need to make in the setupcomplete.cmd file or the firstrun commands in the unattend.xml file. Imaging Windows computers is a bit of a black art and this is all before you get FOG imaging in the picture.

Thanks, you can mark this as solved. Updated client worked beautifully. Thank you all so much!!

@amher17 said in Windows 10 iso:

Im trying to deploy windows 10 OOBE with fog. I have been having problems with sysprepped images. It wont enable bitlocker in the microsoft Intune OOBE.

This sounds like you have been successful booting windows 10 with FOG how are you doing this right now? Is the target computer in uefi mode?

@kevinnew22 said in Error trying to restore GPT partition tables (restorePartition TablesAndBootLoaders):

understood, the release of the new version will be when more or less? I can help with something?

Can’t give you a date as we don’t have a fixed plan for new releases. Not great but that’s the way it is right now. Hardly anyone has time to work much on FOG and so things are going very slowly. You are more than welcome to join in an help us push this forward. See my post in the forums. Please send me a private message if you are keen to get involved and I am sure we have something for you! Looking forward to hear from you.

@louvet-christophe Can you please take a picture of the error on screen and post that here in the forums?

I forgot to isntall the client it’s working now sorry !

@tom-elliott J’essaie d’avoir un espace de stockage supplémentaire pour FOG, en créant un nouveau nœud de stockage.

Est-ce possible de stocker des images sur un poste Windows 10 pro dans un dossier partagé?
Est-ce obligatoire d’utiliser Windows Serveur pour stocker des images?
Doit on utiliser un NAS?
Si vous avez des procédures?

Merci pour votre réponse.

@librarymark I came accross the same error here with a different software that does the same. Couldn’t fix it but I see you managed to fix it and I don’t mind to use RRRx instead of Radix.

Can you walk me through this please? My FOG server is set to undionly.kpxe as far as I know (last time I checked this was long ago). Do I need to change it in /etc/dnsmasq.d/ltsp.conf

@george1421 great! by habit we turn secure boot off. i have someone looking into attempting to capture in a while to see what we get. thanks for all of your help so far.