@Cire3 The short answer is that it’s possible, but it depends on how nextboot.xyz handles dhcp information.

The simples form is to add this to the fog ipxe menu builder parameter block.

chain tftp://192.168.1.12/nextboot.xyz || goto Menu

If nextboot.xyz uses dhcp information (which will point to the fog server unless we alter it.

set newserver:ipv4 192.168.1.12
set newbootfile nextboot.xyz

set net0.dhcp/next-server ${newserver}
set net0.dhcp/filename ${newbootfile}
set proxydhcp/filename ${newbootfile}

chain tftp://${newserver}/${newbootfile} || goto Menu

@Thiago-Ryuiti The error is saying that the service account fogproject doesn’t have rights to the /images directory.

This typically happens for two reasons.

1. Someone changed the password to the fogproject linux user account on the fog server. This password is managed by the FOG installer script. If someone intentionally changed this password you will need to fix it. The complex password is saved in a hidden file in /opt/fog/.fogsettings file. You will need to be root or su to root to be able to view this file. If you need to keep this changed password for some reason there is a process to resync the password with what FOG thinks.
2. Someone has changed the permissions on the /images directory after FOG was installed.

@jaapvdpol In theory its possible to do with FOG. The concept in FOG terminology is master node at HQ and storage nodes at the remote locations. The master node will replicate the images created at HQ to all remote storage nodes. One caveat is that the remote locations must be in constant and routable contact with HQ 100% of the time. PXE booting computers at the remote site will contact the FOG master node (at HQ) to find its local storage node. Once identified it will image directly from that local storage node. Only status update packets are sent between the imaging remote computer and the FOG server at HQ. So by design it will work, I’m just not so sure about the scale you propose.

I wonder about your update frequency of these computers and if the proposed design is the right one based on how often you think you will reimage a remote computer. Will it be a one time imaging and then only reimage when the system fails? Would a mobile FOG deployment server work better for your deployment plan? In this design you would have a laptop running linux with FOG installed. You would also include dnsmasq with this mobile deployment server to provide pxe boot information to the pxe booting computers. You won’t need to adjust your remote sites networking to support pxe booting, you just drop the mobile deployment server on the network. Once booted you can pxe boot into the FOG iPXE menu and pick deploy image (system builder load and go methodology). You wouldn’t have post imaging management with the load and go method, but is that in your plan or only to migrate operating systems?

@boros There is no RHEL/CentOS since they are both dead to me now that IBM had its way…

BUT, someone with the proper motivation can probably make it work. I would start with my post here: https://forums.fogproject.org/post/103324 That will give you the basic layout. Now lets mix it with these instructions. https://docs.centos.org/en-US/8-docs/advanced-install/assembly_preparing-for-a-network-install/

The most useful section is from the syslinux boot menu.

label linux
  menu label ^Install system
  menu default
  kernel images/CentOS-8/vmlinuz
  append initrd=images/CentOS-8/initrd.img ip=dhcp inst.repo=http://10.32.5.1/CentOS-8/x86_64/iso-contents-root/

While FOG uses iPXE its possible to translate between the two formats. From the first link this is what I used to call centos 7 installer.

kernel tftp://${fog-ip}/os/centos/7/vmlinuz
initrd tftp://${fog-ip}/os/centos/7/initrd.img
imgargs vmlinuz initrd=initrd.img root=live:nfs://${fog-ip}:/images/os/centos/7/LiveOS/squashfs.img ip=dhcp inst.repo=nfs:${fog-ip}:/images/os/centos/7 splash quiet
boot || goto MENU

So to update the syslinux format to iPXE

kernel tftp://${fog-ip}/os/centos/8/vmlinuz
initrd tftp://${fog-ip}/os/centos/8/initrd.img
imgargs vmlinuz initrd=initrd.img ip=dhcp inst.repo=http://${fog-ip}/centos8/ splash quiet
boot || goto MENU

So you will need to copy vmlinuz and initrd.img from the iso to the fog server into /tftpboot/os/centos/8 directory. This places the boot files in scope of the tftp server. The next is to place the contents of the iso (extracted) into the scope of the web server in /var/www/html/centos8 directory. So the target computer will load linux and the initrd from the tftp server and then access the rest of the centos files from the contents uploaded to the web server.

@catselbow said in Current instructions for creating a bootable USB drive for imaging via FOG?:

with nothing else on the drive, and where all names seem to be case-sensitive (I couldn’t get it to work with bootx64.efi or BOOTX64.efi).

In the easy way link I did mention that I did not test if case is important. I think its dependant on the uefi firmware. But you did find a working pattern so that’s good.

The documentation at the 2nd link above says that after booting I should be prompted for the IP address of the FOG server.

The ipxe.efi is non fog server specific. The fog delivered ipxe version has been modified from the developers configuration because it includes an ipxe script built in. Think of it as what autoexec.bat is to DO, default.ipxe is to iPXE. The script is here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/ipxescript You see from the script that it locates the FOG server from the dhcp query. From either dhcp option 66 or the next-server field. That is how it finds the fog server to load the default.ipxe file from the FOG server to continue the boot.

That doesn’t happen for me. Instead, ipxe tries to connect to the server from which I copied ipxe.efi (which is on the other side of a firewall) and fails.

The only way for iPXE to try to find the server where ipxe came from is that your dhcp server on this isolated subnet is filling out dhcp option 66 or the bootp next-server field. And because iPXE is getting this direction its not asking for the boot server.

Either not give the target computer the dhcp option 66 value or give it the right answer.

So you might ask how can I really tell what the target computer is being told to do? A: Use a witness computer (3rd computer not part of the pxe booting process) with wireshark loaded. You can either use a capture filter of port 67 or port 68 or port 4011 or a display filter of bootp. In a normal dhcp process there should be at least 4 packets DISCOVER (from the client) OFFER (from one or more dhcp server), REQUEST (from client), ACK/NACK (from server). Look at the OFFER packet. In the ethernet header there will be the bootp fields of {next-server} and {boot-file}, and dhcp options 66 (ip address of FOG server) dhcp option 67 (file to boot). Either these need to be blank so iPXE will prompt, or correctly populated for your isolated network.

@catselbow Those instructions are still valid and should work.

What part are you having an issue with? making the usb drive, or getting your computer to boot from it?

If its booting from it, do you get to the grub boot menu with the options or won’t the computer simply boot (after you turn secure boot off)?

@ShiraiKasumi said in How much editable is the boot menu?:

can I use html files to configure the boot menu

The quick answer is no…

The boot menu is managed by the boot loader called iPXE. iPXE uses a batch/cmd/bash script like macro commands to build the FOG iPXE boot menu. Its not a html or other mark up language. If you have a fog server already running, go to your browser and key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=0 To actually view the iPXE script behind the FOG iPXE menu.

Now with that said, that boot.php page referenced in the URL is responsible for creating the FOG iPXE menu. FOG is opensourced so you can do what ever you want to modify the FOG iPXE menu in that php page.

Lastly FOG has a built in iPXE menu maker where you can add custom iPXE menu items to boot unique tasks. I have a tutorial on how to add menu items into FOG’'s boot menu to load installers for different operating systems over PXE boot https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
That page will give you examples on how to add entries to the boot menu.

@fhhowdy said in Dell XR11 No Bootable Media:

For FOG imaging having uefi secure boot disabled is a requirement.

I’m wondering if sending a different image to the machine might be possible. Where does FOG select the image that is selected? Where are these images stored?

This explaination will take a little setup. In fog you create image definitions in the webui. Then you register a computer with FOG. This lets fog capture the target computers hardware info and stores it in the database. Part of the registration process it asks what image do you want to connect this computer to. Now when you configured a FOG image capture task and pxe boot the target computer the target computer will know what image location to store the captured image into. For this example lets say your target computer had a debian image so you just captured that and stored the image in the debian image definition. Now you go and create a rocky linux image definition. You can now update your target computer’s image definition to point to the rocky linux image definition from debian. The debian image is still there, but now we are going to capture the rocky linux image into FOG. So lets say we repeat that process for Windows 2019 and 2020. So now you have 4 captured images and 1 target computer defined in FOG.

Lets say you pxe boot a new computer, and boot into the FOG iPXE menu. From the fog ipxe menu you can pick Deploy Image and then deploy any of those 4 captured images to this new computer. System builders use this method, that I call “Load and Go” You can deploy an image to a target computer without registering it with FOG. You lose FOG’s management capabilities, but for system builders once they load the OS they will never see the computer again. But in your case you should register all of your computers with FOG for post deployment management capabilities. Don’t misunderstand, you can still use the pxe boot -> deploy image route with registered computers too.

@fhhowdy This error looks similar to what I might expect when secure boot is enabled. Check the firmware settings to ensure that secure boot is disabled, which will allow the FOG boot manager (iPXE) to load.

Something else to keep in mind is that FOG’s imaging operating system (FOS), is really targeted towards laptop/desktop computers and not servers. Servers often use hardware not commonly found on workstation class computers. I’m not saying it won’t work, we will just need to be mindful if things act abnormally. Machine class isn’t the issue here, because your server is not booting into the boot manager. The problem I mentioned may come when you pick an action from the boot menu.

For relies on the underlying host OS to provide package support. FOG will work with PHP8. The issue is that CentOS 7 doesn’t have packages available to support newer versions of PHP. Or to say it a different way, the issue is with your FOG Server’s OS, not FOG Project Imaging programming.

Now how can you tell what version of fog are you running? The fog web gui will display the version. FWIW: The latest version of v1.5.10