@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

@abolajioriola said in Keyboard on Dell 3440 does not work at registration prompt:

interestingly some of them had their internal keyboard work when fog asked you for a hostname, and some of the laptop’s internal keyboards do not work when fog asks you for a hostname

Ok just to be clear (i can read your statement a few different ways) On your Dell Latitude 3440s, you have some that the internal keyboard works, and some (of the same Dell model) that don’t work, but an external keyboard does?

If yes, lets compare the version of firmware (bios). IMO the same exact model should perform the same, either they all work, or they all won’t work. Not 50/50. So the question is what is the variable? Firmware version (bios) would be one, The second is that Dell used different hardware depending on when the device was made (rare but happens, a mid year engineering change).

@abolajioriola Ok that gives us a few more clues then, if an external keyboard works but onboard does not. Just to verify the onboard keyboard works within iPXE menu, such as when you go to image and iPXE asks for a user ID and password?

Just to be clear, before you pick any entry in the iPXE menu, iPXE kernel is managing the keyboard. When you pick an iPXE menu and bzImage is loaded, then the FOS Linux kernel is in charge of the keyboard. When inventory is running and asks you for a host name or other entries, that is FOS Linux.

So what I’m thinking here is that on the Dell 3440 computers, the keyboard is behind some bit of hardware it is not being configured by FOS Linux. Where as FOS Linux sees the external keyboard on the usb port and configures it. You mentioned other computers where the keyboard doesn’t work? Now is that 3440 the 2023 model or the 5-6 year old 3440 that is matched with the 7440 and 9440 laptops? If its the older series I have a 7440 that I can verify fos linux against.

@abolajioriola Does not work (any keys typed no update) or does not work with your local language set? (guess you are in france but ipxe only recognizes US character sets?

@PhilienTaylor I’m not sure what your question is here. Your end goal is not clear based on what you have posted.

1. FOG doesn’t support imaging over Torrent.
2. FOG doesn’t support Secure boot. There is a tutorial on how you can create your own keys and then sign the boot files. This will require you to upload the certificates into each hardware. Or to go to microsoft and go through the process to get microsoft signed signing keys for what you want to boot on the target hardware.
3. FOG doesn’t have any utlity for hypervisor environments. The FOG server can run as a vm client, but FOG has no relationship with virtualization.

Paragon Hard Disk Manager

Information kindly contributed by @Wolfbane8653

Configuration currently works for UEFI only. It appears the wim file is missing bootmgr.exe for the BIOS booting systems

It is highly recommended to use this on a machine that has 4GB+ RAM.

First we’ll create the required directories:

mkdir -p /var/www/fog/Tools/{iso folder name}
chmod -R 777 /var/www/fog/Tools/{iso folder name}

Now we’ll mount the WinPE iso over the loop directory. Then we’ll copy the contents of the DVD to the directory we built above.

mkdir -p /mnt/loop
mount -o loop /{full path where you have the iso stored}/{iso file} /mnt/loop

We are going to copy to /var/www/fog/Tools so we can use the http protocal already setup for fog management.

cp /mnt/loop/bootmgr /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/boot/bcd /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/boot/boot.sdi /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/sources/boot.wim /var/www/fog/Tools/{iso folder name}
cp /mnt/loop/efi /var/www/fog/Tools/{iso folder name}

umount /mnt/loop

Download and install the latest wimboot kernel and extract it from the zip file.

• https://github.com/ipxe/wimboot/blob/master/wimboot
  The issue was discussed in this post: https://forums.fogproject.org/post/144293
  We will use tftp protocal for this file in the fog menu.

cd /tmp
wget http://git.ipxe.org/releases/wimboot/wimboot-latest.zip
unzip wimboot-latest.zip

Copy the wimboot file from the archive directory to root of the os directory (we’ll need this for every windows boot media, so we’ll place it in a common spot).

mkdir -p /tftpboot/os
cp ./wimboot-2.6.0-signed/wimboot /tftpboot/os
chmod -R 777 tftpboot/os

The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields

Menu Item: os.{iso file name}
Description: {iso file you would like to boot from}
Parameters:
set tftp-path tftp://${fog-ip}
set http-path http://${fog-ip}/fog/Tools/HD_Manager
kernel ${tftp-path}/os/wimboot gui
imgfetch --name bootmgr ${http-path}/bootmgr bootmgr
imgfetch --name bootx64.efi ${http-path}/efi/boot/en_us/bootx64.efi bootx64.efi
imgfetch --name BCD ${http-path}/bcd BCD
imgfetch --name boot.sdi ${http-path}/boot.sdi boot.sdi
imgfetch --name boot.wim ${http-path}/boot.wim boot.wim
boot || goto MENU

That’s it, just pxe boot your target system and pick os.{iso file name} from the FOG iPXE boot menu.

@TectonicLeader Very good you are making progress. On the plus side dnsmasq and pxe booting is working perfectly.

I have to ask you did you change the IP address of the fog server since fog was installed. The default.ipxe file has a hard coded IP address in it. Your picture shows it picked up default.ipxe from .3, but then default.ipxe called a .2 IP address. If you did change the IP address of the fog server after the install you can fix the configuration by hand. I was sure I had a tutorial on this, but I can’t seem to find it right now.

1. In the FOG Web UI goto FOG Configuration->FOG Settings and press the expand all button. Search for the old IP address and replace it with the current IP address.
2. Still in the FOG Web UI goto Storage Management and pick the default node (it should be the master node). Change the IP address in there to the proper one.
3. Log into the fog server’s linux console, and switch user to the root user so you can edit a hidden file (if your fog server has a linux desktop you can use gedit from the linux desktop too). Edit a hidden file /opt/fog/.fogsettings note the dot at the beginning of a file makes it hidden in the linux world. Correct the IP address listed in the config file.
4. Lastly rerun the fog installer to fix all of the other bits where the IP address is hard coded.
5. Inspect the content of the /tftpboot/default.ipxe file to ensure the IP address has been corrected. (this is the point where your error exists).
6. If everything looks good, try pxe booting again.

On a side note, pxe booting from net3 might be a problem in some of the fog code (not specifically this issue). Typically the fog code only looks for the first two network interfaces to boot. But since you got as far as loading default.ipxe using net3 might be OK.

@TectonicLeader Many soho routers will point to themselves as the boot server, even if they have the facilities to set dhcp option 66 and 67.

If you have no option other than to use your netgear router as your dhcp server, then I recommend you install dnsmasq onto your fog server. It takes about 10 minutes to do and will solve your soho router issue. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@tlehrian Ok so you get a BSOD with windows and under linux you get a kernel panic (same but different). So that points to a hardware issue with this computer.

I would swap memory with a known good computer, even if the mem test comes back OK. By moving parts hopefully the problem will move with the hardware.

Move other pcie attached devices like GPUs (if external) or other add in riser cards.

Now that you updated the bios, go in and reset the firmware settings back to factory defaults. In case there was a firmware setting change with the new firmware that corrects a known issue.

Sorry I can only give random ideas, but since this seems to be a hardware issues I can only make logical guesses here.

@george1421 I did find this reference:

invalid opcode: 0000 [#1] PREEMPT SMP PTI

PTI(Page Table Isolation) is a Spectre/Meltdown correction at the bios and kernel level. Make sure they both are up to date.

ref: https://www.reddit.com/r/linuxquestions/comments/ajhw7e/what_can_cause_invalid_opcode_0000_1_preempt_smp/

So lets start with update the firmware.

@tlehrian It is surely a hardware issue. The error message is not detailed enough to point at one thing unfortunately.

So lets start with the basics:
What I can glean from the error message is that this computer is using firmware version 1.01. Firmware 01.08.08 Rev.A was released on 21-Nov-23. I would start by updating the firmware.

If that doesn’t solve it then, swap memory with the working computer.

If that doesn’t solve it then, remove all non-essential hardware cards.

If that doesn’t solve it then download the 5.15.x version of the linux kernel for FOG. Edit: I see now that you were at 5.15 and then upgraded. So this isn’t the issue.

@bkgoodman This can be set from the fog web ui. FOG has a concept of storage nodes and master nodes. Only master nodes can collect images, you can deploy images from both master nodes and storage nodes. Where storage nodes are deploy only.

While the following deals with synology nas devices the same info can reference other NFS aware devices. Your target system needs both nfs AND ftp enabled to be able to function as a FOG storage node.

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@bkgoodman said in NFS Config:

Is there a way I can configure out Fog (iPXE) clients to use our NFS server directly - instead of trying to mount image stores from the Fog server, itself?

There is a way, but if this is an active NFS server, using FOG imaging would make that nfs server insecure. The FOS engine, the software that runs on the target computer is a customized linux OS. The image capture process runs as the root user, so your nfs share would need to allow root access to the nfs volume. Typically NFS is configured to squash root access to the nfs share for security reasons.

If you really want to do this you can undo the security to allow root’s access. In our tutorial section we have guidance on how to setup a synology nas as a FOG capture server, so its possible to do, but it is an unsupported configuration by the devs so YMMV. The best solution is to capture to the fog server as the devs intended. But since its opensource, if you have the skills, then almost anything is possible.