@sebastian-roth This fixed my issue as well…set permissions to 777 🙂 I’ll tighten here in a minute.

@rrtern Just wondering, did you create a route between the two subnets? The firewall(s) may also need rules to allow pxe, http, and tftp traffic between those subnets. I didn’t see anything mentioned about routes so that’s why I asked. For instance in pfsense, by default different VLANs can communicate with each other. But at my job’s network environment they have to create routes so that vlans and subnets can communicate.

@rlair23 I’ll raise your tutorial with one of my own: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The next step is indeed to get a pcap of the pxe booting process. You can either use wireshark on a witness computer or for a bit more information since the pxe booting computer and fog server is on the same subnet use tcpdump on the fog server. This will collect both the broadcast and unicast messages between the fog server and target computer.

You can either look at the pcap or post it to a file share site and DM me the link in the fog project chat. If you want to look at it I can give you where to look, though it would be quicker if I looked at it because there are a few exceptions.

@rogalskij FOG uses the distribution’s tftp server. This is to ensure the services used by FOG is supported by your linux distribution vendor.

Hi there
I created a fresh VM with Ubuntu 20.04 and was able to get FOG up and running. Thanks for all your help! 🙂

@geekyjm If your old fog server was on a version pre-ssl then it may have been pretty dated. There was an older update_unattend script where you would have to put the domain join password in plain-text. Now you can use the $adpass variable that pulls from the foghost’s settings. Then the domain password isn’t passed in plaintext in any script files. So you may need to update how that password is stored on your hosts under ad settings (I believe there’s a global method in the fog settings GUI) and then try again.

I just started using the update_unattend postdownload script myself and was successful without having to have the password in plain text anywhere and the machines joined the domain.

As @george1421 mentioned there may be more going on here, as there may be some new steps needed for your fog install, but we can get this working the way you’re expecting again none the less.

I have found it, you cant see the advanced tasks from the task menu, but if you go into hosts, list all host, select the PC you want, then click Basic Tasks, then advanced, the options are all there. Thanks everyone. I just needed to ask the right question. @Wayne-Workman @george1421

@george1421 Okay, I did the three commands you listed, but I think it failed on the second command. I would send you a log but I don’t know how to generate one from the terminal other than to copy and paste, and when I do that it doesn’t catch all the lines completely.

@lacugo If you switch over to the FOG 1.5.9 dev branch (a.k.a FOG 1.5.9.115) it will install cleanly on Debian 11. But sadly not ubuntu 22.04 or centos 8 where php8 is the default install. AS of now FOG only supports PHP7.x until some code refactoring is done.

@george1421
An other screen
03.JPG

@wayne-workman That worked. Could there be a change to the wiki in this case? I swear I spent far too long troubleshooting that.

Thank you Wayne, for your assistance. I can get to the webpage now. I’m excited to use this tool!

@wayne-workman Thanks for the response. I just decided to start from scratch since I had a earlier snapshot.

@wt_101 Well juggling three with running chainsaws doesn’t make it a bad idea, does it?

The 15 character limit is a windows NT thing. Since the majority of the folks that use fog for image deployment the developers have set it to 15 characters. If you have a use case where you need more than 15, I don’t see the harm in expanding it to more than 15 characters. That is the beauty of opensource. If it doesn’t work for you out of the box, if you have the skills you can change it.

You just need to be mindful if you have to interact with windows that the computer name might get truncated 15 characters when the computer name is set.

But also be aware that I don’t know of anyone who has tried to set computer names long that the MS defined standards either. Other things in FOG may break (thinking fog client if its hard coded at 15 characters).

@nickw Check if the real time clock is set correctly.

@sourceminer said in Capture Image partclone fail.:

Suggestion: would it be a good idea to test these dirty flags prior to running the lengthy imaging process

I know there is a check for the dirty bit before imaging starts, but that might only be on the OS partition. Looking in the code I see a resetFlags function that actually runs the “ntfsfix -d” command. I’m not sure how its applied. I know if your drive contains the windows dirty bit the imager will stop before it starts deploying anything. So its not clear why it didn’t catch the issue on the 4th partition. But I do have to say its rare that the recovery partition would have been shut down uncleanly.

But in the end I’m glad you have it worked out.

great thanks @george1421 i understand now, basically to do this right, you need to sysprep using an unattended xml file which i dont do, so best case scenario is i can just leave the drivers there and install once im on the desktop,

thanks again george

@riry Yes and no. Lets follow this tutorial https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Also look at the FOG Forum chat bubble for a few more hints.