@noobfogger Well this is a bit different conditions than your original post. iPXE is being loaded now but when iPXE starts it issues a second dhcp query to pick up its IP address and loads dhcp option 66 once again to find the FOG server. If it fails to get dhcp option 66 it will prompt for the FOG server IP address.

This is still telling me there is a second dhcp server on this subnet. There is a way to find out. Take a third computer and load wirehark on it. Use this exact capture filter port 67 or port 68 Start wireshark and then pxe boot until you get the failure. Stop wireshark and then inspect the captured packets.

In the top section you should see a DISCOVER packet sent from the pxe booting computer. Then you should see one or more OFFER packets. These OFFER packets will be from each dhcp server that hears a DISCOVER packet. In your case you should only hear an OFFER from the FOG server’s IP address. I’m suspecting you will hear a second OFFER. The response sequence is DISCOVER, OFFER, REQUEST, ACK/NACK. If the target computer gets to the prompting for FOG server IP address question you should see two complete sequences of the DORA process. If you are getting the question that second sequence is failing. If you can’t figure out the pcap, upload it to a file share site and share it as you have the videos and I will take a look at it for you. But it should be obvious if you have a second OFFER in response to a DISCOVER something is not as we expect it to be.

@lebrun78 Thank you for the feedback . Your install is suffering from having the database engine for the tables in ISAM format instead of INNODB. We can fix this no problem.

OK now my needs. I want to use your mysql database with many fog clients to record how many queries take long than 1 second to complete. With your slow database it probably will be all of them. I want to do a before and after test to see the improvements and then once we get the improvements the after scan will give us hints how to make the database go even faster.

The following commands will turn on global query logging (note it might even make your database slower so we will only let it run for 30 minutes).

Log into mysql database as root and run these commands.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slowquery.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';
SET GLOBAL long_query_time = 1;
FLUSH LOGS;

Let this run for 30 minutes at the time of day where you would have the most computers on line and pinging the FOG server.

Then after 30 minutes log back into mysql and run this command to turn off logging.

SET GLOBAL slow_query_log = 'OFF';

The last part is to make a report of the log file and post it in this thread or via a file sharing site. From the linux command prompt run this command to make the report

mysqldumpslow -a /var/log/mysql/slowquery.log >/tmp/slowreport.txt

Download the /tmp/slowreport.txt from the FOG server and post it here, please.

@jra said in Securing FOG Boot Options?:

What is KILLING me though is I still get the same stupid thing; “Chainloading failed, hit ‘s’ for the iPXE shell”

You get this when the iPXE menu first comes up? When or what action causes the chain loading error?

@jra If you could post a screen shot of the error because the context of the error is almost as helpful as the error itself.

So the error is because of the rendering of the advanced menu? Since I have not worked with the advanced menu at all I don’t know exactly where to drive. BUT I can say if you point a browser at http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 That will send the programming language behind the iPXE menu. Lets start by posting that results here for the next steps.

undionly.kpxe vs ipxe.efi. This file needs to be sent correctly based on the target computer that is pxe booting. SO, let me ask you what device is your dhcp server (mfg and model)?

@jra said in Securing FOG Boot Options?:

Especially as it has persisted across two versions of Ubuntu and two versions of FOG also

My intent isn’t to be snarky here but stating fact. You are also persistent between the installs and menu fails. I’ve had this issue with other things in the past too. We can’t rule out that the web ui is letting you do something that causes the advanced menu to fail. I’ll see if I can duplicate this on my dev box later tonight. I have not needed the advanced menu so I don’t have any experience with it.

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