@greg-plamondon Hint: When you get the http 500 errors, inspect your apache error log file so see if apache or php threw an error.

Just for clarity here (because I’m a little confused on what you are asking). The .EXE’s you deploy may or may not take arguments. In regards to FOG the arguments you want to send still go into the “Snapin Pack Arguments” field. The developer of the .EXE has all of the control on what command line arguments they will accept. FOG can only pass what is in the “Snapin Pack Arguments” field when invoking the snapin.

For example if you have just a simple .exe that take parameters it would look something like this (using no preconstructed template)

If I misunderstood what you are asking, please clarify.

@imagingmaster21 do you need your whole fog database or only the image information? If its only the image information, the quickest way is via the web gui. Go into the images on server A and export the image definitions, then log into the web gui on server B and import the image definitions. This will move over the image definitions without over writing (messing up) anything else in your server B FOG server.

If your end goal is actually migrating to a new server, then there is a wiki page that covers the migration: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@imagingmaster21 Ok so the target computer is saying it can’t reach your image store. All of the kernel parameters look good.

So we need to do some checking.

1. Did you disable the firewall on your fog server, as well as selinux set to permissive as in the prerequisites to install FOG?
2. Is there some kind of firewall between the target computer and the FOG server?
3. Execute this command on your FOG server, showmount -e 127.0.0.1 and post the output here. (Hint if you connect to your fog server using putty you can copy and paste the text without needing to do screen shots).
4. Also post the output of this command from your FOG server ls -la /images

@keith75140 Well if you can get linux console access, the fog password should be captured in /opt/fog/.fogsettings

But if you have admin access on this server, just create a new linux user like fogadm and give that sudoer rights. Then start using that account for system administration and leave the fog user alone.

[mod note] Marking as solve. I setup a teamviewer session with the OP and helped him fix this and a few other issues. At this point the OP is imaging as designed now.

I remoted in with teamviewer and helped the OP get things working correctly. We had to ensure that the dhcp server only bound to the imaging lan NIC adapter and not both. We also found a nuance with ubuntu where it only wanted one interface up at a time by default. Once we had both interfaces up, fog installed correctly and like the OP needed it. Solving this case.

I have to ask the question why no dhcp on this network? Is there a technical or regulation requirement for no dhcp? FOG needs dhcp server to send out the needed boot information. That is a requirement.

I found my notes on this. This one is for BIOS mode. I used the nfs protocol instead of tftp. Both will work. You just have to place the files in a different location based on the protocol.

kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootmgr.exe bootmgr.exe
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot

I have not tested this, but a quick file change and this should work for UEFI. Also for uefi booting, you must send the ipxe.efi iPXE boot kernel. You can not boot into uefi mode from undionly.kpxe boot kernel.

kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootx64.efi bootx64.efi
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot

Just be aware these instructions will NOT boot "Windows 10 ISO via UEFI" so you can install WIN10 as in the OP's question. The only way I found to boot the win10 ISO so you can install Win10 is by using the link I posted previously.

@fox134 Well lets hope you don’t have an ipxe.exe in there…

The client gets its booting information from (the) dhcp responsible for assigning an ip address to the target computer. So if you want the target computer to use a different boot file then you might update dhcp options 67.

Now with that said, from your OP you say that FOG is giving out the IP addresses on a dedicated imaging network. So if you want to change the boot file, you will need to edit the dhcp config file on your FOG server.

To see what you config file looks like, you can review this example: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

You will see for arch 7 and 9 it calls out ipxe.efi. You can replace that with maybe snponly.efi or any of the other efi files. Then you must restart your dns server. On ubuntu you would issue the command sudo systemctl restart isc-dhcp-server to restart the service.

@dahrell Sorry I’ve been looking at other issues.

I was able to get a generic USB ethernet adapter to work once FOS was booted. But that won’t help you since it will have another mac address. Using a down level kernel might work, you can assign that kernel to that specific bit of hardware via the host configuration page. I was just looking but I can’t seem to find old FOS kernels in the 4.10 era. I know they exist, I just can’t locate them at the moment. Plus there is no guaranty that they will include the driver for this bit-o-dock. The right solution is for the linux kernel developers to fix the code to support these things.

For you to use a third party network adapter to pxe boot, you may find no joy there either. The UEFI firmware has to have the drive built in to support pxe booting. I don’t suspect that M$ will include any drivers in the uefi firmware other than their own hardware.

Lastly you could always usb boot into FOS using the FOS USB stick. Its not an ideal situation, but it would bypass pxe booting by booting FOS off the usb stick (as I did in my testing). Then all you need to have is a FOS supported usb ethernet adapter to image.

@wayne-workman said in Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task:

That’d be the responsible thing to do on Microsoft’s part.

[snark on] But why, there is no profit in that. Fixing linux does not push their crappy windows 10 agenda at all. [snark off]

FWIW: You can get older FOG Project created kernels from this URL: https://fogproject.org/kernels/

slighly off point post, but recording for reference.

MBR 512n

Disk /dev/sda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00006e8c

GPT 512n

Disk /dev/sda: 36003.6 GB, 36003637100544 bytes, 70319603712 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 3DAC1844-EDDA-43CD-9334-E0F3515F0AC7

MBR 512e

Disk /dev/sda: 1098.4 GB, 1098437885952 bytes, 2145386496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000

4Kn

Disk /dev/sda: 999.0 GB, 998997229568 bytes, 243895808 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 4CD4D7DC-B85C-47B5-A8D0-BCFA2345A58D

I’m sure there is a better way…

fdisk -l /dev/sda|grep -e "Sector size"|awk '{print $4, $7}'

There is

fdisk -l /dev/sda|awk '/Sector size/{print $4, $7}'

OK lets start out with some basics.

1. What device is your dhcp server?
2. Is your fog server and target computer on the same subnet (vlan)?
3. Are you imaging computers on your business network or on an isolated imaging network?
4. When you say you can’t pxe boot, what is the error number/message displayed on the target computer?

@tesparza Well that is why, she no work. Its asking you a question on the hidden screen

@tesparza A suggestion I can give you is this. Use 7-zip to extract that direct-x .exe file. It is a self expanding archive file. Then you will need to change how you deploy it, you will need to deploy it as a fog snap-in pack and not a .exe

@awellis I have some sad news for you. I setup a clean 1.5.0 fog environment and multicasting works “as described on the tin”.

Is your fog server in a virutal environment?

With a quick teamviewer session this issue has been resolved. The issue was just the sequence of install and ensuring eth0 was up before installing FOG.

There is currently a bug in 1.5.0 that is causing this. The problem has been (will be) fixed in 1.5.1. Is this a show stopper for you? FOG 1.5.1 is expected to be released in the next week or so.