Best posts made by george1421

@george1421 for reference: https://forums.fogproject.org/topic/12339/help-with-advanced-menu-with-login

I’ll fill in a bit more detail later this AM. But I got the same error as you did. I looked into the code and didn’t understand what the fog devs were doing. I found the above link and now understand. The advanced menu doesn’t work the way one might think.

lets use this example based page to create the advanced page.

#!ipxe
set fog-ip 192.168.112.116
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.112.116/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
item fog.advanced Advanced Menu
item os.Debian.10.7L Debian 10.7 Live
item fog.keyenroll FOG Secure Boot Enrollment
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.112.116/fog/ consoleblank=0 rootfstype=ext4 NFSv4=1 NFSTLS=1 storage=192.168.112.116:/images/ storageip=192.168.112.116 nvme_core.default_ps_max_latency_us=0 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.112.116/fog/ consoleblank=0 rootfstype=ext4 NFSv4=1 NFSTLS=1 storage=192.168.112.116:/images/ storageip=192.168.112.116 nvme_core.default_ps_max_latency_us=0 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.112.116/fog/ consoleblank=0 rootfstype=ext4 NFSv4=1 NFSTLS=1 storage=192.168.112.116:/images/ storageip=192.168.112.116 nvme_core.default_ps_max_latency_us=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:fog.advanced
chain -ar http://192.168.112.116/fog/service/ipxe/advanced.php || goto MENU
:os.Debian.10.7L
kernel tftp://${fog-ip}/debian/10.7L/vmlinuz
initrd tftp://${fog-ip}/debian/10.7L/initrd
imgargs vmlinuz dhcp boot=live components fetch=http://${fog-ip}/os/debian/10.7L/filesystem.squashfs
boot || goto MENU
param sysuuid ${uuid}
:fog.keyenroll
chain tftp:/${fog-ip}/EnrollKeys.efi
echo Rebooting the system in 8 seconds
sleep 5
reboot
param sysuuid ${uuid}
:bootme
chain -ar http://192.168.112.116/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

The other option would be to not use the advanced menu, but just apply a login requirement on each standard ipxe menu item.

@jra Now that I’ve had my second cup of coffee this morning I can explain it a bit more.

What the advanced menu and advanced.php does is insert a menu you create when advanced.php is called. You have to hand code the advanced menu and insert the text into a field in FOG Configuration->FOG Settings PXE Advanced Menu field. That field is then inserted after the #ipxe you saw when you called advanced.php directly (like I had you do).

I don’t have the skills to do this, but it would be great if you could construct the advanced menu like you do the standard iPXE menus by just changing the Menu Show with field, to “Show on Advanced menu”. Then you could move standard menu item behind the advanced menu right from the gui. That sounds like a logical feature to have, but right now the FOG Project doesn’t have the developer time to add that feature.

@gbarron Did you try what Sebastian posted in the thread you linked?

"Please check in FOG Configuration -> FOG Settings -> General Settings -> CAPTURERESIZEPCT. From the help text:

Default is adding 5 % and you can increase that as much as you like (up to 99 % which would not make sense)."

See if FOG leaving more reserve space allows the capture to complete. This is not a true fix for the disk, but it may let you capture the image by telling the compacter program to not squeeze so much out of the disk before capture.

@wayne-workman said in Install FOG on Ubuntu Server 21.10 issues:

Every time I turn around, a new linux distro is released.

I have a concern about supporting these non-LTS releases since they have a 6 month support cycle by the vendor. It seems like we are constantly chasing our tails here with the rapid release cycle plus supporting 5 or 6 different distros. Not to mention maintaining support for old LTS releases towards the end of their life. You are already validating 20 discrete OS’ now.

@robertkwild Since you didn’t reference a step I can only guess at the answer.

But the dbx.esl is created on this post Preparing the FOG server with the prerequisites

More specifically is a copy of the dbx file you exported out of hardware in this section

sudo efi-readvar -v dbx -o /opt/fog/secureboot/hwkeys/hw_dbx.esl 

dbx.esl is also created when you run these commands

cd /opt/fog/secureboot/efitools
make

This is when you first compile the efitools programs
Then we rename the first compiled version with this command because we don’t need it in the finished product. We’ll use the hw one that was downloaded from the firmware.

mv dbx.esl dbx-fog.esl

And then finally we take the firmware hw_dbx.esl file and copy it over to the dbx.esl file name.

cat hw_dbx.esl > dbx.esl

Depending on where you are getting the error I think you missed a step. The dbx.esl file contains any certificates that have been revoked. When you compile the file signing keys the default microsoft dbx.esl file is good enough.

@robertkwild said in secure boot - dbx.esl no such file to move:

I can’t mv dbx.esl as it’s not there to move

So if after you compile efitools and the dbx.esl doesn’t exist that is OK since you will be replacing it with the exported hw_dbx.esl key. So its all good

@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.