Hi EduardoTSeoane,

Thank you! Restarting the FOGSnapinHash service with systemctl restart FOGSnapinHash worked! I did check if this service was running but never thought about restarting it. This gave me some more energy to search the forum.

I found this post also noting the FOGSnapinHash interval is 30 minutes. Then I found one can change that interval on the FOG server by:
FOG Configuration >> FOG Settings >> FOG Linux Service Sleep Times >> SNAPINHASHSLEEPTIME from 1800 seconds to …

I still think it’s very strange someone should have to wait for 30 minutes after creating a Snapin that reuses a file with a default FOG installation, as it seems to be a common thing to do because of the Snapin File (exists) drop down menu in the GUI, but I’m glad and thankful my problem is solved!

Best,
J den Hartog

@gpd187 said in Cannot PXE boot target capture device.:

Could not start download: Operation not supported

Please post a picture of that error on screen!

@chunter2 Leaving it won’t hurt anything. One might think, if its working now its good enough.

@george1421 said in Cant deploy images from master node and storage node at the same time.:

@paat said in Cant deploy images from master node and storage node at the same time.:

But do i get this right if you go this way you have no automatism?

Yes you won’t have unattended deployments if you don’t pxe boot through fog, BUT you won’t accidentally wipe the CEO’s laptop either if you force the IT tech to at least sit in front of the computer to start imaging process. The rest of this method is all no toch.

Hey I created a new image with a script which starts with the setupcomplete.cmd and this fixed the Uefi-Boot issues via bcdedit.
I didn’t use the dell cctk tool yet because I have still a few Fujitsu machines left but maybe i’ll switch to it because it seems very powerful (firmware deployment, bios managment etc.)

The actual problem seems to solve by itself. I don’t know what happened exactly but I deployed the image to 50 machines and both servers (master and node) deployed the images. Maybe I was to impatient.
If I’m right the master server checks if there are open slots on each server and distributes and controls the image process
I think the thread can marked as solved for the moment.

Thank you for your help George!

had the option to remove encryption in the console, already solved! thanks anyways.

This question is a bit vague on details, so the answer is it depends.

If you sysprep the image and you are using windows 10 then the answer is probably. The 9020 is pretty old now so windows 10 probably has all of the native drivers for for the 9020 built in. You will probably want to ensure the firmware is updated on the 9020 to the latest and set the firmware to uefi mode to match the configuration of the 7760. The difference in generation of computers are quite large so there is a risk that it won’t work because the technoliogy between the two platforms are quite different. You will also need to make sure you have enough ram in the 9020 too. Finally on the 9020 you will need to swap out the spinning HDD for a SSD drive or running windows 10 on the 9020 will give an unhappy experience.

@foguser2018 Please start a new thread with pictures of how you have it setup. I understand your situation may be similar but your configuration may not be exact. To avoid confusing future readers we like to keep issues isolated if possible unless your conditions match exactly.

OK, well, as an update, It looks like I was banging my head against a bad repo for the php stuff
I walked through the logs of a successful install (by a colleague) and compared them.

All is good now.

Thanks

@george1421
It was worse than i thought.

Ubuntu wouldn’t start so it looks like a complete refresh 😞

They do occasionally have different or old BIOS versions, which I update after Windows is finished loading. But they all have the same settings.

@Wayne-Workman Thanks. This is very helpful

FINALLY!! I figured out the problem. It would always fail the PXE boot in legacy and for some reason I used EFI PXE boot and it now works on this laptop.

@Sebastian-Roth

Yes found this Wiki when I was migrating, thank you

@Sebastian-Roth

Thank you for your help!

@Quazz

You are absolutely right. I always struggle to keep the copying behavior between Linux and robocopy. Sure enough there was a snapin folder inside of the snapin folder. I thought that I had checked that but probably just saw that files were there and did not pay attention to the path. The hashes now exist and I saw that in the logs that it was generated and deploying of those snapins now work as expected.

I appreciate everyone’s help and willingness 🙂

Got it! Thanks.

@David-Raymond said in Cannot find disk on a new Dell Latitude 7400 2-in-1 using FOG:

I have for testing using the dock that came with them.

Just an additional comment. The WD19 docks that come with the 7400 give marginal support for PXE booting. Sometimes they show up and sometimes (most) of the times pxe booting isn’t an option. The older WD15s and the usb-c dongles work 100% of the time.

You may be limited in running FOG inside virtualbox on the 6430. FOG running on bare metal on the 6430 would be just fine for a deployment only system. I would swap out those 6430 delivered hard drives (which are slug speed slow) with an SSD drive. That SSD under windows will make the 6430 fell like a new computer (even at twice the weight of a 7280). Good luck with your deployment. FOG should perform well for you.

We’ll keep track of this on github:
https://github.com/FOGProject/fogproject/issues/328
https://github.com/FOGProject/fos/issues/28

Would you share a screen shot of the error you see on the Dells?
Also what model of Dells do you have issues with and lastly what version of FOG are you using?

Sebastian, thank you. That was it exactly.

@mkeane What do you see in the fog-client log now??