@Julien-asv I’m glad you have a working path. Yes you will need to get in contact with your network admins to enable port-fast on every network port that you need to pxe boot from. This is a common error when people leave the default settings enabled on their network switches. So we have seen it before that is why I had you try the “time fixed it” path for debugging.

I didn’t have time to test the rEFInd downgrade yet but found a workaround for the issue with the missing boot entry in the BIOS.

Rebuilding the BCD obviously solves the “problem” (which only HP BIOSes have).

Recovery process in short:

Boot to recovery console Assign drive letter to EFI partition rename old BCD (\EFI\Microsoft\boot\BCD) bcdboot c:\Windows /l en-us /s [Assigned letter]: /f ALL

Still I’m wondering why this is an HP only issue.

Edit: I’m almost sure that “bcdboot C:\Windows /addlast” will also do it but currently do not have a victim to test upon.

@Chad said in Not able to capture Image:

My biggest pain point was letting my Check Point firewall handle DHCP. All options were set properly, however the TFTP file name was never passed to the host, so it got an IP, but didn’t know what to do next.

This is what I’m thinking about the sonicwall, or its not configured correctly for dhcp options 66 and 67. Also what we find in most firewalls is that they only support static dhcp options. So with static dhcp options you have to pick either bios or uefi support.

I solved this by creating a separate subnet and then letting FOG handle DHCP on that network.

This is not necessary if you install dnsmasq on your FOG server. DNSMASQ only supplies pxe boot info overriding anything the dhcp server tells the client. We find most soho routers will always send the lan interface as the boot server instead of the FOG server. DNSMASQ will fix this broken behavior.

If the OP has the sonicwall configured correctly and the target computer still isn’t pxe booting we have a tutorial on configuring the FOG server to capture the pxe booting process so we can see what is going wrong.

Sonicwall help shows how to configure the sonicwall for pxe booting: http://help.sonicwall.com/help/sw/eng/published/1334883822_5.8.1/PANEL_dhcpStatProps.html Relevant steps are 18 == ipxe.efi and 19 == fog server IP (I know it says dns name, use the ip address here). Note you may also need to configure the generic options in step 20 for dhcp options 66 and 67. Some dhcp implementation steps 18 and 19 are configuration for bootp and step 20 is for dhcp booting. They are two different protocols.

@ricardomartins So you are using the FOG server for dhcp services? If so then its already configured for dynamic pxe booting between uefi and bios. There is nothing else you need to do then.

@george1421 said in Change FTP on fog server to SFTP??:

So that means FOG would need to compile lftp for the FOG host server during install. I have not checked the lftp from FOS Linux but we would also need to ensure that lftp in FOS supports ssl too. We have a bit more control of FOS Linux support of ssl than the FOG Host server.

From my point of view FTPS (FTP with SSL) is no better than FTP from a firewall/network/security point of view and I wouldn’t spend a second on trying to make this work.

If we really think about making this part more secure I would want to push this down the SSH/SCP/rsyncOverSSH way instead! I have not looked into this yet but I could imagine we can make this work for 1.6.x some weeks down the road.

I think he’s asking for a default role via the access control plugin. @Fernando-Gietz any thoughts on that?

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!