Best posts made by george1421

@lgwapnitsky The advanced menu is something that you have to create by hand. Its creation is a bit more prehistoric than the rest of FOG. You create your Advanced menu via a text file and then paste the contents into a field in the FOG Settings page. I’d really like to see the Advanced menu integrated into the standard iPXE menu maker to make things easier for the FOG Admins. Maybe in time…

@jmvela2x Well this thread has been going on for 5 days now and I’m not sure I’ve done a good job explaining how FOG works.

With DHCP Profiles setup with the same computer.

BIOS Computer -> BIOS PXE Boot -> undionly.kpxe will be sent to target computer -> the global value of FOG Settings value contained in [BOOT EXIT TYPE] will be used -> SANBOOT for its Exit mode

UEFI Computer -> UEFI PXE Boot -> ipxe.efi will be sent to target computer -> the global value of FOG Settings value contained in [EFI BOOT EXIT TYPE] will be used -> REFIND_EFI for its Exit mode

This process works 99.9% of the time. The oneoffs that you might find would be UEFI based computers with quirky firmware or hardware.

@wt_101 said in Fail to mount during image deployment:

We have read up the post you share but we never turn on firewall at FOG server

Previously client system (175.168.10.20) at Site B not even able to PXE boot to site A FOG Server (192.168.10.1) until we ask our IT team to whitelist the below port BI Direction between Site A & Site B.

The context was these are the ports that need to be open [on the fog server] so that you can apply the same rules to your network.

If you look at the iptables entry in the url I referenced.

echo "IPTABLES_MODULES=\"nf_conntract_tftp nf_conntrack_ftp nf_conntrack_netbios_ns\"" >> /etc/sysconfig/iptables-config
for port in 80 443 21 3306 2049 20048 111 138 139 445; do iptables -I INPUT 1 -p tcp --dport $port -j ACCEPT; done
for port in 69 111 4011 137; do iptables -I INPUT 1 -p udp --dport $port -j ACCEPT; done
service iptables save

It says you need to open these tcp ports {80 443 21 3306 2049 20048 111 138 139 445}

And you need to open these udp ports {69 111 4011 137}

FOG NFSv3 does use tcp for its data channels and not udp.

@reggiep9000 A quick fix is to just copy the files:

cp /var/www/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe
cp /var/www/fog/service/ipxe/bzImage32 /var/www/html/fog/service/ipxe

Then we can figure out why the link is broken.

You must have debian variant because /var/www is the debian doc root and /var/www/html is the rhel doc root. There “should be” a soft link that maps /var/www/html/fog back to /var/www/fog That links must be broken or non-existent for some reason.

@rude26 I have seen this before but I can’t remember the exact case.

Lets get past the first part in that you have the right boot loader because if you try to load ipxe.efi on a bios computer it won’t load. So you have the right bits there.

What I don’t understand is why it did not transfer init.xz before it tried to start bzImage.

Did you create a custom ipxe menu or something?

The error message is basically saying that bzImage is not an executable file. What do you get when (on the FOG server) you run this command file /var/www/html/fog/service/ipxe/bzImage

@sebastian-roth said in could not boot: exec format error:

https://github.com/FOGProject/fos/releases/latest/download/bzImage

I just reversed engineering this answer…

@rude26 There are actually a series of files that gets downloaded here.

Are you sure your company isn’t using a transparent proxy for internet filtering? HTTP inspect might cause https to fail. See if you can pull the file with http.

@wt_101 said in Decoupling FOG Database from FOG Server:

may i know why moving images off the fog server will lose multicast ability

The service that runs the multicast is only (normally) run from a master node in a storage group. The fog server will use the udpsend command utility on the fog server against local media (or perceived local media).

What is your end goal here? The big question is why, what do you hope to achieve or remediate with this architecture change?

@rude26 This is a YOU problem. What happened is that you used “shutdown” to power off the windows computer. This does not close all of the open windows files because fast startup is turned on.

There are a few ways to shut it down in preparation for cloning.

1. Let sysprep do it.
2. Use the command prompt and use shutdown -s -t 0
3. Turn off fast startup.

For more information google windows dirty bit

Well done on the internet bypass to get FOG installed.

@phips Well this one was my fault, long day and quickly reading the post == misunderstanding. Plugin != Snapins.

For the plugins is actually a two step process. You pick them out of the big list. Then you go to the list of selected plugins. You pick each plugin and at the bottom of the list you pick the install button, then the plugins should show up on the installed plugins list. I just spun up a new FOG server and ran into this confusion. It seemed a little wonky to me how the plugin system worked vs how I thought it should work.

@jra said in "Please Enter TFTP Server" Message:

Options 66 and 67 seem to be fine, and entering the IP of the FOG server dutifully boots it, but I can’t get it to just “get on with it” without typing that IP in.

This is typically a condition of having 2 dhcp servers answering the pxe boot request. One dhcp server having options 66 and 67 set and the other one not.

I would also check to ensure the WDS server is powered off because it can be messing with pxe boot. WDS will typically use ProxyDHCP OFFER packet, this OFFER will override any settings you have defined in dhcp options 66 and 67. How WDS gets hooked into other subnets is by your main subnet router. You would add the IP address of the WDS server as the last server listed in the dhcp helper/relay service. This is so the WDS server hears the clients DISCOVER packet.

“So how do you figure out what is going on here?” Take/make a witness computer (computer on the same subnet as the pxe booting computer) and load wireshark on it. Use this exact capture filter port 67 or port 68 Start wireshark then immediately pxe boot the target computer to the error then stop wireshark.

In the middle section you should see the DORA dhcp process (DISCOVER, OFFER, REQUEST, ACK/NACK). The target computer sends out a DISCOVER packet. Any (Proxy)DHCP server that hears the DISCOVER packet will answer with an OFFER packet. The OFFER packets is where you want to look. If you only have one OFFER packet then we will need to dig deeper. If you have more than one OFFER packet (what I suspect) Look in the ethernet header for {next-server} and {boot-file} those settings should match dhcp options 66 and 67 (found lower on the list). Your troubled DHCP server will have these values missing.

Now if there is a ProxyDHCP server (i.e. WDS server response) dhcp option 60 will be set to identify the packet is a ProxyDHCP answer.

Happy hunting…

@fog_newb Yes FOG default has always been 5%. The devs may need to revisit this decision for FOG 1.5.10 since it appears that current MS OS’ needs a bit more space than previous versions.

@jra I think there are a few concepts that we need to go over because you have a mixed environment.

BIOS based computers will only boot a bios based boot loader (undionly.kpxe). The default and 99% working BIOS Exit mode is SANBOOT.

UEFI based computers will only boot uefi based boot loaders (ipxe.efi). The default and working most of the time is rEFInd.

This causes a problem if you have a static dhcp server where you manually set dhcp option 67 to a static value. If you want to boot a bios based computer you need to set dhcp option 67 to undionly.kpxe and if you want to boot UEFI you set it to ipxe.efi. If you have a windows based dhcp server you can use dhcp policies as outlined here to create a dynamic dhcp pxe boot options: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy If you have a linux dhcp server then the options are also available for dynamic dhcp booting. If you have a soho router or an ISP managed dhcp server then you can load dnsmasq on your FOG server to supply the pxe boot info only to your clients.

Where you can run into a problem, with FOG its totally allowed to pxe boot into BIOS mode and deploy a UEFI image to the target computer. This works as long as the firmware and image on the hard drive match. Where you run into an issue is if you pxe boot through the iPXE menu in this mixed mode and want to boot to the hard drive and not do any imaging with FOG. If you pxe boot a UEFI computer using CSM in bios mode into the iPXE menu, iPXE can’t tell you did this. It thinks you have a bios computer and will try to use SANBOOT to load the OS. Since the disk structure is UEFI SANBOOT will fail (your error in the original post makes me think this is the case). The same is true for a UEFI boot into iPXE with a bios based image, rEFInd will not be able to chain to a bios boot image.

Now for a new deployment (until FOG 1.5.10 comes out later this spring) I would recommend you do the following.

1. Upgrade your FOG 1.5.9 install to the dev branch, this will bring your FOG install to 1.5.9.110 or later. This has the fixes in for Win10 20H1 and later.
2. Update your iPXE version to the latest to get support for the current new hardware: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe/2
3. Update your FOS Linux kernel to 5.15.x using Web UI -> FOG Configuration -> Kernel update. This updated kernel is needed for new hardware that has the realtek ethernet nic adapter installed.

On my campus I require the techs to sit in front of the computer and intentionally pxe boot into FOG Imaging. I don’t have the target computers pxe booting through the ipxe menu every time. We reimage a computer maybe 2-3 times during the life cycle of a computer. There is no need to add the delay of pxe booting through iPXE menu. Plus windows has a nasty habit of changing the boot order to itself when OOBE/WinSetup finishes. Its just easier to have the techs press F12 during booting and select pxe boot when its time to reimage the computer. Plus this way we know we won’t reimage the wrong computer by accident.

@forcom5 The first thing I would do is upgrade the FOS Linux kernel to 5.15.x. The error is an issue between FOS Linux (the engine that does the imaging) and the hardware. So first step is to update the version of the FOS Linux kernel (FOG Web UI->FOG Configuration->Kernel update)

Also make sure the firmware is up to date on the hardware.

If there is still an error after that add the noacpi kernel parameter in the FOG settings page. Understand this is a global setting, but will help you get past registration. Once the device is registered you can set the kernel parameter field in the host definition page.

@forcom5 Well we typically see this with older hardware. It looks like thise 280 G1 systems have a 4 gen processor in them, so that makes me think they are on the older side. BUT if you have a working solution, run with it.

@bnstv said in Boot Device not found:

CLI info
NBP filename is undionly.kkpxe
NBP filesize is 98899 Bytes
Downloading NPB file …
NBP file downloaded successfully

EIther you double posted here or you are the second person to do this in the last 24 hours. NBP indicates UEFI, but you are sending a BIOS boot loader to the target computer. You need to send ipxe.efi if you want to boot into FOG on this uefi computer.

You might also want to look into this article about setting up dynamic dhcp policies on your network. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@jyost Ok two things here.

If that is a Windows 10 20H2 or later target computer you are going to need to do a few things. M$ changed the disk structure on 20H1 or 20H2 (sorry I can’t remember at the moment) but that 4th partition is now marked as unmovable. The developers have addressed this issue on the dev branch 1.5.9.111 The other thing is you probably need to update the FOS Linux kernel (FOG Web UI -> Fog Configuration -> Kernel update. Update to 5.10.55 or later for both x64 and x32 bit versions.

@markg When we are talking about ipxe its important to know a few use cases.

ipxe.kpxe (bios) and ipxe.efi (uefi) they are in a way kind of akin to the linux kernel. They have all of the known network drivers built into the bootloader (kernel). If new hardware comes out and has slighly different requirements than legacy hardware it may take the iPXE developer some time to create/import the drivers into a new release of iPXE. Since this version of iPXE has all of the known drivers on board the boot loader is quite large (in early 2000 standards).

realtek.kpxe/realtek.efi or intel.kpxe/intel.efi. These are slimmed down versions of the larger ipxe.efi in that they only contain realtek or intel drivers with a few tweaks. Other than the few tweaks they are basically the same as ipxe.kpxe and ipxe.efi.

The interesting ones are undionly.kpxe and snponly.efi. These bootloaders only contain either the generic undi (bios) or snp (efi) network drivers. Both of these use the network adapters built in firmware network interface to communicate on the network. For bios the ndi protocol has been around for 30 years and is very stable. For fog the recommended boot loader for bios is undionly.kpxe. Since undionly.kpxe only contains one network driver, its very small and fast (since it only has to test and setup one network interface). As for the snp protocol that has been around only for a few years 8 or so, and only really has become a stable protocol in the last few years. Up until last year the recommended uefi boot loader was ipxe.efi (because the snp protocol wasn’t stable FOG recommended the built in network drivers, because they basically worked). Within the last year or so the developers have been thinking that snp has matured enough and to start recommended snponly.efi as the default uefi boot loader. The network adapters support for snp protocol comes from the network adapter’s firmware creator so it will most likely be current with newly released hardware, where ipxe.efi may take several months to include drivers for newly released hardware.

So the white elephant is, what is the difference between snp.efi and snponly.efi since they both use the snp protocol? The answer is simple and a bit complex. The short answer is snponly.efi will only init the network adapter that was used to download snponly.efi. snp.efi will initialize all snp network interfaces and not just the one that transferred snp.efi to the target computer. So with snp.efi, you could PXE boot from one network adapter and then image from a second network adapter. Its not likely to happen, but from a hardware standpoint its possible.

@robertkwild All I can say is same, I walked away from Centos, disliked the direction Ubuntu was taking so I picked Debian and have been happy since (Its like ubuntu without the BS since its based on debian anyway).

@editor FWIW If you are having issues with dnsmasq not doing what you want you can review this post: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

The reason why I mentioned it is because a 3 second count down is not part of the standard dnsmasq settings. If you are missing those you might be missing others listed in the above post.

If your dnsmasq configuration is working perfectly there is no need to review the post.