This is interesting, I can see how it could be useful, though understand it would take valuable developer cycles for a thing that perhaps could be achieved in another way using existing features, without development efforts. @Nicolas-Bricet have you considered the following? setting an image for hosts in a particular site via groups, such that when imaging happens, the host’s image which is already set is used.

@george1421 To be honest, I would rather not go with a custom n12 image as I want this to be as easy as possible for anyone to use this… The plugin/snapin method seems like it would be the cleanest way to handle things. I am currently looking for such a plugin to allow me to add “boot to PE” as an option on the same level as deploy and capture. the people using this most are already familiar with that process and if I could just throw this in, the same way then I feel like this would be the more sensible outcome.

@Sebastian-Roth Please help me to delete it. Thanks!

@Wayne-Workman
Can you give me a path to insert this code? Many Thanks!

@ZrytyADHD said in Booting accros networks:

You have a number of problems here.

FOG doesn’t like it when you change the fog server’s IP address after FOG is installed. There are several steps that you must do if you decide to change the FOG server IP address after fog is installed.

Why are you mixing WDS and FOG in your booting process? You can do manage it but I would go about it a bit differently.

Your section of the isc dhcp server is just wrong in my opinion.

if exists user-class and option user-class = "iPXE" { filename "http://10.0.0.68/boot.php"; } else { if option arch = 00:00 { filename "undionly-mj2.kpxe"; } else { #UEFI Bootujemy z WDS UEFI next-server 10.249.4.20; filename "boot\\x64\\wdsmgfw.efi" } }

a. I’m not aware of a user class in the dhcp discover packet. There is a vendor class
Vendor class identifier: PXEClient:Arch:00007:UNDI:003016

b. The following line is wrong for several reasons

filename "http://10.0.0.68/boot.php";

b.1 you are telling the PXE rom to load a http protocol. Almost all PXE roms use tftp not http.
b.2 The path to the boot.php is wrong if you are trying to call the boot.php on the fog server the path is <fog_server_ip>/fog/service/ipxe/boot.php

For this I would just use filename "default.ipxe"; but that still will not work because you don’t mention the boot loader (undionly.kpxe or ipxe.efu)

c. You are saying if the option is bios then load undionly-mj2.kpxe (not a fog supplied boot loader) but if everything else call WDS. But only do this if user-class == “iPXE”

d. uefi pxe booting into FOG is not supported

There are ways to fix this, dhcp booting, but please explain why you are mixing FOG and WDS. What is your goal of doing this? Will it be a for ever solution?

@jdmiller323 @jmvela2x Is this still causing you trouble or were you able to set it up?

Thank you so much

@beardedfool said:

Need to check how to do reinstall (can I just ./installfog.sh -A over the existing installation as per new build

Yes you should be able to do just that!

@george1421

Thank you so much for your reply. I didn’t think the solution would be so easy. Especially that with other versions of the system the problem did not appear. Thank you very much!

Thank you!

@Fog_Newb I am still not convinced you need the acpi=off kernel parameter as you said that it does register properly. Both registration and deploy use the same Linux environment…

The error messages were in the links to the others posts.

This is not of much help. Often error messages seem to be “the same as” but actually are not if you look closely. To be able to help we need a picture of the error on the screen of your machines!

It would appear that centos 7.5 with tftp server 5.2.22 (or later or post Feb 2018) has the RFC7440 patch applied. https://rpmfind.net/linux/RPM/centos/7.7.1908/x86_64/Packages/tftp-server-5.2-22.el7.x86_64.html

My fog server that runs on centos 7 appears to have the required version of in.tfpd

tftp-server-5.2-22.el7.x86_64 : The server for the Trivial File Transfer Protocol (TFTP) Repo : base Matched from: Filename : /usr/sbin/in.tftpd

@george1421 ok, could be a way to solve the problem! Thank you!

@ddo Fortunately I have just tried doing something like that using the Windows task planer and it worked:

schtasks /create /tn "MyTask" /sc once /st 23:00 /tr "C:\path\to\program.exe parameters" /ru "domain\username" schtasks /run /tn "MyTask" schtasks /delete /tn "MyTask" /f

Though you might need to come up with some more scripting to find out the user being logged on to the machine at the moment. Should be possible to do but I haven’t figured it out myself yet.

The short answer is no FOG can not decrypt or encrypt any form of hard disk protection. FOG can clone encrypted hard drives in RAW (read slow) mode. FOG will not be able to resize images created in RAW mode. So RAW mode is a sector by sector copy so your target drive needs to be exactly the same size as the source or larger than the source. You do have to be careful of encryption that use the TPM chip. These types of disks created with these encryption tools can’t be moved between computers with the drives encrypted. The FOG server can surely clone them, but the target system won’t boot if the TPM chips don’t match.

Typically you wouldn’t encrypt the source disk, and then launch the drive encryption on the deployed image via a GPO policy. At least that is how we did it using Symantec HDE.

Can you provide a clear screen shot of the problem taken with a mobile phone?

Also if you can follow the steps in this tutorial we can find out exactly what the target computer is being told to do. It really helps if the FOG server and target computer are on the same subnet to collect this pcap. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@alansopro If you don’t get anything in the apache error logs you need to check PHP-FPM log or even try syslog/messages as you will get the error on those on some systems. If we don’t know the error, we can’t fix it unfortunately.

Just found this as well:
https://forums.fogproject.org/topic/3227/fog-api
https://github.com/cuckoosandbox/cuckoo/issues/1258

I finally solved this using the WOL broadcast plugin. Steps:

Created WOL broadcast with the public ip of the site where those computers are On the router from the second site added static arp for private ip 10.148.17.254 to mac ff:ff:ff:ff:ff:ff (broadcast) On the same router forwarded port 9 udp to 10.148.17.254

You can mark this as solved. Thank you!

For others: The remote site has computers with activated and working wake on lan and the router configured for DHCP with next server the IP of the FOG server and filename undionly.kpxe (for legacy BIOS boot).

@kevinnew22 In the scripts we use curl which does work out of the box! I am sure this is a spanning tree issue. I won’t repeat this anymore.