In replacing net 0 by net4 in “param mac0 ${net0/mac}” Fog is not bugging.
But I don’t find how to inhibit the linking-up of net0, net1, net2 and net3 to directly link-up to net4…

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain

@oz-agoston said in Need help with new FOG server installation and setup (PXE, image creation):

Unfortunately our bosses wouldn’t want us to use the windows DHCP server for the FOG server to avoid possible network problems.

We have solutions you can use where you don’t or can’t update your primary dhcp server. You don’t necessarily need to setup an isolated network. Depending on your deployment your target computers may need access to AD during deployment, where an isolated network might cause a problem.

In cases where you can’t/don’t want to update your primary dhcp server you can install dnsmasq onto your fog server to provide pxe boot information only to the target computers. It takes about 10 minutes to install dnsmasq using this configuration: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

Now just be aware that dnsmasq (as well as dhcp) only works on local vlan/subnet because dnsmaq as well as dhcp uses broadcast messaging. So right there dnsmasq pxe boot information will be localized to the current subnet where the fog server is installed. If you want to pxe boot on another subnet where the FOG server is not, you will need to update your network’s router and add the FOG server’s IP address to the list of dhcp servers in the dhcp-helper/dhcp-relay service. This will allow dnsmasq to hear pxe booting from other subnets. One of the many advantages of dnsmasq running on the FOG server is that if the fog server is off-line no pxe boot information will be sent to the network.

@gabrielchun said in Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0):

@george1421 Fiz isso e não deu certo.
Instalei esses 2 que estão expandidos, pois são os que contém o “bzImage”.
MicrosoftTeams-image (2).png

Tentei com a seguinte configuração no Host, tentei também limpo sem nada na descrição para testar, sem esse “bzImage” e sem o “noapci=1”
MicrosoftTeams-image (3).png

Como está dentro do meu fog:
MicrosoftTeams-image (4).png

Agora carrega o bzImage mas ainda da o erro:
MicrosoftTeams-image (5).png

@Cire3 said in Not a Fog problem, but solution ?:

Carbon X1 Gen 7 just returns to boot menu after Downloading NBP file

Check secure boot is off and if the proper boot loader is being sent to the target computer.

You might use a witness computer on same subnet as the pxe booting computer. Use a capture mask of port 67 or port 68 or display filter of bootp Start the capture, pxe boot to error and then stop the capture. You will see the DORA process (discover, offer, request, ack/nack). Look at the offer packet this is coming from the dhcp server to the target computer. Look to see if both the ethernet header (bootp part) has next-server of IP address of fog server and boot-file as the proper boot loader name. Now confirm that dhcp options 66 and 67 are set properly. Its up to the pxe boot firmware vendor to decide to use bootp fields or dhcp option fields to locate the boot information. If you grab the pcap I can look at it for you if you get lost or not sure.

Looks like you are having issue with TFTP. With recent firewalld, you have to have some mechanism for inter-zone traffic. I’m not sure if the one on CentOS 7 is covered. Also, you missed to show the zones of your interfaces.

I have these on my setup where the storage server has 3 interfaces serving diskless clients via iscsi:

For my external zone:

[root@san ~]# ip -4 addr ls xenbr0 6: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 192.168.0.33/27 brd 192.168.0.63 scope global dynamic noprefixroute xenbr0 valid_lft 3181sec preferred_lft 3181sec [root@san ~]# [root@san ~]# firewall-cmd --get-zone-of-interface=xenbr0 external [root@san ~]# firewall-cmd --zone=external --list-services dhcp http https iscsi-target samba ssh tftp

And this is my internal zone

[root@san ~]# ip -4 addr ls xenbr10 7: xenbr10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000 inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute xenbr10 valid_lft forever preferred_lft forever [root@san ~]# [root@san ~]# firewall-cmd --get-zone-of-interface=xenbr10 internal [root@san ~]# firewall-cmd --zone=internal --list-services dhcp http https iscsi-target postgresql samba ssh tftp

I have these firewalld rule to enable the inter-zone traffic:

[root@san ~]# cat firewalld.txt firewall-cmd --new-policy NAT_int_to_ext --permanent firewall-cmd --permanent --policy NAT_int_to_ext --add-ingress-zone internal firewall-cmd --permanent --policy NAT_int_to_ext --add-egress-zone external firewall-cmd --permanent --policy NAT_int_to_ext --set-target ACCEPT

Finally, I test things out from one of my vms and tried to can grab a file over tftp

user@debian:~$ ip -4 addr ls virbr0 5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000 inet 192.168.10.15/24 brd 192.168.10.255 scope global dynamic virbr0 valid_lft 2111sec preferred_lft 2111sec user@debian:~$ user@debian:~$ tftp 192.168.10.1 -vc get ipxe.d/roms/undionly.kpxe Connected to 192.168.10.1 (192.168.10.1), port 69 getting from 192.168.10.1:ipxe.d/roms/undionly.kpxe to undionly.kpxe [netascii] Received 75436 bytes in 0.6 seconds [928658 bit/s] user@debian:~$ ls -lh undionly.kpxe -rw-r--r-- 1 user user 74K Dec 12 10:25 undionly.kpxe

@george1421 Thank you for the response and the pointer to previous thread on examples of how to branch the iPXE menu with the platform option. With this info, I am thinking along the lines of customizing the default.ipxe to present different menu based on the platform field. I will explore this method and see how far I can take it on presenting separate menu for legacy vs UEFI clients.

@SOSF2 OK I update this exports file with the 2 new location and it’s working ! Thanks. I thinking that this file was not updated with a new ./installfog.sh but it was…

I believe a reinstall would do the same no ?

@cornycopia Hi!
Are you familiar with powershell at all? If not, it’s too hard to learn,
I have made a powershell module to help with managing these things (see my signature for more links)

For example there’s a command to make a new fog host https://fogapi.readthedocs.io/en/latest/commands/New-FogHost/
I would recommend giving that a go.

That said, let’s take a look at why this isn’t working

The first issue I see with your body is the macs need to be an array
You might also have to have the modules param defined in the body.
In my PowerShell function I have a function to get all the modules and I filter it to the default ones so that the behavior is the same as when you add a host in the gui instead of creating a host with nothing in it.
https://fogapi.readthedocs.io/en/latest/commands/Get-FogModules/

Here’s a simplified table of that output, I think the ids are always the same in all installs, but they could be unique to your install

id name -- ---- 1 Directory Cleaner 2 User Cleanup 3 Display Manager 4 Auto Log Out 5 Green FOG 6 Snapins 7 Client Updater 8 Host Registration 9 Hostname Changer 10 Printer Manager 11 Task Reboot 12 User Tracker 13 Power Management

Anyway, here’s an example of a json body for creating a host with the default service modules enabled (these are my defaults, you may have different ones configured)

{ "macs": [ "A4:BF:01:6E:E4:F2" ], "name": "demo", "modules": [ "7", "9", "13", "6", "11", "2", "12" ] }

@cicero We didn’t change your password, unsure what those credentials would have been, but if you need to reset the password there are instuctions on how to do so. I would highly recommend resetting once you’re in though as it’s just the base default we define:

username: fog
password: password

https://wiki.fogproject.org/wiki/index.php?title=Reset_WebUI_FOG_password

Hi, we’re running the latest FOG 1.5.10, trying to deploy to a Optiplex 3080.
FOG boots PXE, and I can deploy a image.

Yes these PCs come with NVME drives.

Issue is the deployment speed, it changes from below 1gb to over 8gb, same deployment to same machines, no other changes.

Done every firmware update / fog update, still various deployment speeds.

Got similar Dell UEFI only 3000 units on a flat test network & they all behave the same.

I understand. I thought that with 2 network cards it would be possible to do this.

What I tried was to do the following and change the default.ipx file with the following line:

chain http://192.168.10.1/fog/service/ipxe/boot.php##params || chain http://192.168.0.1/fog/service/ipxe/boot.php##params || goto bootme

WhatsApp Image 2023-12-06 at 09.34.02.jpeg
And I managed to boot on the other network. This way, it is possible to boot from the 2 network cards in different VLANs.

The problem is that, as @george1421 said, Fog doesn’t provide this type of support. (I believe that if the developers created an ID to identify the network and separated the files it would be possible to do this configuration, but I don’t know the feasibility of that.)

As @baovipboy156 suggested, I’ll try to do a forward port to the fogserver in pfSense, and let you know if it works.

Thanks for the help guys.

@nrey said in i fail to install FOG Fnaf:

I fail to install FOG due to this problem. Can someone help!!!
)

It looks like you’re losing connection. Please make sure you are using a trusted Proxy ID!

@DBCountMan From my memory, yes, that is correct.

Another thing to consider which I have observed in my environment is network congestion. If you are imaging on your production network, especially if the subnets aren’t segmented, you may experience slower than normal imaging speed. If your FOG server is connected to the network at 1Gbps, keep in mind that if you are trying to image 10 workstations connected at 1Gbps, the server will only be able to send/receive at 1Gbps. The more imaging that happens at once, the slower they will all be. That is why I have been looking into getting my FOG server connected at 10Gbps so that it can handle at least 10x1Gbps connections without slowing down.

@mark29 said in PXE-E32: TFTP open timeout:

it screens PXE-E32: TFTP open timeout.

This can be (most commonly) caused by either

DHCP options for that subnet have dhcp options 66 set incorrectly. You have two or more dhcp servers on that subnet and both don’t have all of the setting needed to pxe boot. The tftp service is not running on your fog server.

I would setup a witness computer on the same subnet as the pxe booting computer that witness computer will run wireshark, with a capture filter of port 67 or port 68 or use a display filter of BOOTP. Start wireshark and then pxe boot the target computer until you get the error, then stop the wireshark capture.

Now review in wireshark the OFFER packet. This comes from the dhcp server to the client.

Look to see if you only have one OFFER packet. You should because the pxe error is “Open timeout”. Look at the OFFER packet in the ethernet header verify that both the {next-server} field has the IP address of the FOG server, and the {boot-file} has the proper FOG boot loader. Now look at the DHCP options under option 66 and 67 they should match whats in the ethernet header.

FWIW: I’ve seen soho routers that eventhough you properly configure them, they set themselves (the routers) as the pxe boot server and not what you put in dhcp option 66.

@cul3r0 The https redirect is actually only working for me if I go to the fqdn on http, i.e. http://fog-server.domain.tld will redirect to https but http://fog-server will not redirect.
I’m pretty sure it’s possible to adjust the rules to redirect everything to the fqdn on https. You can probably mess with the rules to make it rewrite anything to go the the fqdn on https

@r00s7a This is most likely an issue with your network infrastructure and not fog. The DHCP offers come from your primary dhcp server. If that DHCP server is not FOG Server then its not something you can solve on the fog server.

Where we have seen sometimes they pxe boot and sometimes not is if you have two dhcp servers on your network. Possibly in a primary / secondary configuration. Confirm that all dhcp servers have dhcp options 66 and 67 set because these settings are not replicated between windows dhcp servers.

@AlleneBrick @alexamore90
Lets clarify further first.

What DHCP server are you using and what is its ip?
What do you want the fog server ip to be?

@El-Fogito said in PXE Boot issue on second FOG-Server:

VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.

The first question is that is 10.20.88.0 fully routable to 10.20.10.38? i.e. can you ping 10.20.10.38 from the 10.20.88.0 subnet?

Do have any firewalls or screening routers that might stop udp port 67 and 68 from reaching 10.20.10.38? You can test this by using a computer on the remote subnet and trying to tftp one of the boot files from the fog server.

You are saying that you can change dhcp option 66 from 10.10.10.38 to 10.20.10.38 and the remote system can’t pxe boot. This eliminates dhcp server and possibly any router dhcp helper/relay settings from the problem.

If you have a witness computer (third computer on the remote subnet running wireshark) on the 10.20.88.0 you might setup a pcap to see what the remote pxe booting computers are being told what to load. This would ensure that the remote pxe booting computer was being told the proper values. If true then you can eliminate dhcp infrastructure issues and then deal with IP routing as the problem.

Is there any WAN links between 10.20.10.38 and 10.20.88.0/24 subnets? I have see WAN links that have a smaller MTU than the tftp block size cause a problem. I think the default block size for tftp is 1468 so if the link MTU is below that value it will case the tftp packet to fragment and then fail to download. From your error message it doesn’t sound like this is the issue, but its always good to ask.