@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”

@sebastian-roth

Hello,

that works 🙂
But i had to put the iso in /var/www/html/iso/
And then i had to know the name of the iso file. (No directory listing)

Thank you very much.

RESOLVED !

@sebastian-roth said in Migrated Server - Clients Cannot Connect:

@Scott-B So things are fixed for you now, I understand?

Yes good to go! Now to perform the migration on the production server.

@sebastian-roth and @Wayne-Workman, solved! I just had to update storage management password for DefaultMember. After that, I got successfully uploaded captured image. Thanks!
0_1512643251788_Seleção_208.png

@scott-b Yes i’me sure (“control userpasswords2” tells me it). I’m using the local admin acount.

@wayne-workman Hey Wayne, thanks for your help. You can close this. We are migrating to a new image anyways and I don’t have a ton that are deployed out, so I’m just going to start from scratch. Thank you very much. : )

@benc Good to hear that you could make it work. I still suggest you should read up more about UEFI and think about moving all your systems that direction.

@gabbas Ok, thanks for letting us know. I talked to the fog-client main developer about this and we both were kind of puzzled by this. I’ll mark this solved then. Please open a new thread and post fresh new logs if you have an issue again.

I think the hostname policy of our company is the problem. We use year numbers and consecutive numbering as names for the hosts. And exactly in the query with one of the consecutive numbers results in several results of the query. Just there.
If I enter the entire name, it will only display that one host.
The case can be marked as solved.
Thank you for your cooperation.

@jjsplitter said in PXE / TFTP booting is slow:

I find it hard to believe that it is a network issue. Even after I know a computer is imaging slowly, I can start another one simultaneously and it will be imaging at a normal speed.

The issue is probably not the network itself but a combination of network driver on the client and your setup. The only way we can figure this out is by looking at the network packets. You’d first have to figure out which network interface is used in the FOG server (sudo ip addr show).

On the other hand it might be a very hard thing to nail down and fix anyway. So I do understand if you don’t want to spend more time on this. I’ll mark this thread solved for now. Feel free to open a new one and post a reference here if you want to keep debugging this.

@andreiv I moved your last post to here since it’s a separate issue that you found: https://forums.fogproject.org/topic/11157/checking-schedule-shutdown-after-task-completion-causes-the-running-task-to-hang/2 Please follow it there.