@coxm said in Image Replication Across Storage Groups:

should i image a pc in that remote site which is made part of that remote site storage group it will pull the image from that node, not the master Fog server on my local site.

Not necessarily. Without the location plugin, fog just picks whatever server that has empty slots.

You should look at the location plugin (link posted earlier), I think that’s what you need. The location plugin allows you to assign storage groups and storage nodes a physical location, and allows you to set physical location on hosts. If host A is assigned location A, and a storage node is assigned location A, then all imaging on host A would only use node A.

@lebrun78 said in Manage scheduled task:

May be examples are lacking in the documentation ?

Help us write examples? Post them here.

@marcolefo Ok, thanks for letting us know. Marking this solved now. If you have issues again, just let us know.

@sebastian-roth Yeah, my supervisor is satisfied with the process. It is working. Thanks so much for your help guys!

@quinniedid OK in my test lab I’m running the build listed in my post. That is with 6.5u1 and the Oct 2017 patch. Point being if I can get a few minutes of time I want to see if I can duplicate what you are seeing to see if VMWare addressed/changed/fixed the issue with a vSphere update. I don’t know one way or the other, but this sounds like a uefi firmware issue to me.

@NateCCC Do you have any custom scripts, post-init or post-deploy?

To me it seems you have a similar but still different issue. Better open a new thread and describe your setup in detail: FOG version, picture of any messages on screen at the end of deploy on the client, even better take a video of pre and post imaging screens…

@sjensen said in Issues with disk in an unsafe state:

I got the update installed and i am uploading an image from the Samsung laptop now.

Great to see that you’re up and running. I’ll mark this solved then. Please open new threads (yes several if you like) in case you hit another problem. It’s best to not mix up a dozen or so questions in one thread.

Cheers,

Yes that work around worked.

Cheers!

@Tywyn Great to hear you could make it work again. I have no idea what was wrong before. I have looked through the code many times and don’t know what could have gone wrong. Marking this solved now. Let us know if you see this again.

@BardWood Bump… 🙂 Any news on this?

@wayne-workman I think the FTP password was the issue - thanks so much for the help!

@wayne-workman said in Problems creating an image:

Bitlocker?

Could be just as well.

@sjensen You might want to try setting this image to Single Disk - All partitions (non-resizable), just to see if that works out of the box.

Well I was just going to do the DHCP method but I may fix or create a script to just insert the host name

@scott-lynch said in EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081:

So zstd is the preferred compression method for the images?

Yes it is much faster at decompression. There is a small performance hit on compression speeds, but for that initial capture penalty you get a much faster decompression rate.

If I remember correctly the gzip engine is (now) only use for image capture. Zstd is used as the default decompresser because it can accept both gzip and zstd images. You only get the performance increase with a zstd native image.

BTW: Wonderful that you are now capturing an image with FOS. So that tells us the issue isn’t with the FOS kernel (bzImage) but with the hand off between Firmware, iPXE and the FOS linux kernel.

OK I will check that out first before marking as solved… just incase someone else wants to do the same thing. This company is to damn cheap to get new 100 dollar machines to replace the 30 thin clients… BAUGH… yes I agree its not the norm but I know Fog can do it… It can do anything 🙂

@chrispy I think you’ve mixed up UEFI and BIOS. This machine really looks like it’s a UEFI machine, and your DHCP server is telling it to use a BIOS boot file. You’ll probably want to go over this document and that should put you on track: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

Install the FOG Server with the DHCP option while online, then take it offline and it should work for you.

@davidjor I think things are being a bit mixed up here. Let’s step back and take the whole picture. In your initial post you said you wanted a FOG standalone setup and you thing dnsmasq could cause the issue. Let me ask, why do you use dnsmasq at all. What is providing DHCP in this scenario? Looks like an external server is doing this. What is it? Why can’t you add PXE boot options to that DHCP server?

If you can’t modify that DHCP server then dnsmasq is the right way to go. But as it can be a little tricky I first wanted to check if we really need to go that way.

Looking at the config you initially posted I see a line pxe-service=X86PC, "Boot from network", pxelinux which could be causing that we see pxelinux in the pcap file. Please make sure you only use Georges config (not a combined one) and put in your IP addresses where needed.

@sebastian-roth Can you confirm where in version Running Version 1.5.0-RC-10
SVN Revision: 6080 This might be? @Tom-Elliott

Got it, this is the syntax from Powershell

$HostJson = @{
“name”= $vmname
“description”= $Description
“macs” = @($MacAddress)
“imageID”= $Image.id
“imagename” = $ImageName
}
$CreateHostJson = ConvertTo-Json($HostJson)
$createHostURL = $baseUri +“/host/create”
$createHostResult = Invoke-RestMethod -Uri $createHostURL -Method POST -body $CreateHostJson -Headers $headers -ContentType “application/json”