@youzersef I can explain why its doing what its doing. It has to do with the boot file name, its still picking up the ipxe.efi from dhcp. So the filename bit we are stuffing into dhcp is not being passed on to the target boot loader or its querying dhcp and still seeing fog stuff.

Its also not helpful to blank out the private ip addresses. I can’t tell where you are in the world from 10.x.x.x that is a non-internet routable IP address. Masking it just makes things a little harder.

What I did find interesting from the error message is how did 10.x.x.1 get into the conversation? The error message surely said iVentoy so some bits of it has to be loading.

@inconnu Ok if you can move the files via ftp then you have the permissions right. Now the login information you used for FTP, go into the web ui and look at the storage node (probably master or default) make sure the ftp settings there are correct. If not correct them.

Make sure the /opt/fog/.fogsettings password match what you used for logging into ftp. If yes then rerun the installer.

I have not seen issues with the database, but its always possible. In the same .fogsettings file there should be a user name and password for mysql.

From the fog server’s linux command line key in mysql -u <fog_use_name_from_settings_file> -p <password_from_file> fog

Make sure you can login with the mysql passwords from the config file.

If you want to make sure it works you can key in the following from the mysql console.

use fog;
show tables;
exit;

It should show you more than just an error message. Especially the show tables command.

@youzersef Here is from another recent thread. I have not tested this code, but it is for chain loading to another pxe boot loader. There are two methods. I also have doubt with the second method because I find references to both ways to set the new boot file. If the code below doesn’t work for setting the file name try this. But the way I set it in the below section seems right. Its iPXE that is responsible for chain loading a new boot loader.

set filename ${newbootfile}

---

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

@youzersef The iso image appears to give you what you need. Looking in the grub.cfg file this menu entry really gives you the clues to what files you need from the iso.

menuentry 'Ventoy 1.0.97 LiveCD GUI' --id=LiveCD {
    echo downloading kernel ...
    linux  /EFI/boot/vmlinuz quiet first_run rdinit=/VTOY/init
    
    echo downloading initrd ...
    initrd /EFI/boot/initrd
    
    echo booting LiveCD ...
    boot
}

Using the link that Tom provided and the above info it looks like you have what you need. Specifically you need vmlinuz and initrd from the iso image.

@Cire3 said in Chainloading Simple Next Server ?:

server:ipv4 10.22.24.8
set newbootfile netboot.xyz.efi
set net0.dhcp/next-server ${newserver}

You are missing the word set in the first line.

So I looked at the autoexec.ipxe file and this is what is in it :

OK then it looks like netboot.xyz uses ipxe (because of your autoexec.ipxe script)

So you might not need all of those set commands. Because FOG used iPXE as its boot loader AND netboot.xyz also uses iPXE, AND iPXE is already running in memory, all you should need to do is call that autoexec.ipxe script.

This is all that should be needed in the parameter block of the fog menu.

chain tftp://192.168.1.1/autoexec.ipxe || goto Menu

Where 192.168.1.1 is the ip address of your netboot.xyz boot server. There is a 50/50% chance of this not working because if they compiled custom stuff in iPXE that might be dependent.

@jaapvdpol Well lets see if we can get a few things sorted out here.

Scale: I have not seen an install yet with 100 storage nodes. Each storage node will need to be managed at some point in time.

I kind of see this as a two phase project.

1. The initial push to move from windows to linux. Will you have boots on the ground at each location to do this? If yes they can bring a mobile deployment server with them (laptop kitted with what they need for imaging). If you are trying to do this all remote I can see it taking a while to complete.
2. Post upgrade to linux. From time to time you may need to image failed computers. How will you handle that? Have a fog server at each site? Will you train local folks to be able to do this? Or is a drop ship a new system and they return the failed one for repair a bit of a better solution? Now I’ve used a raspberry pi for a fog server to image low volume systems. But that is before the prices of those critters when crazy. You think about it, with a site of 20 computers, you might, and I say ‘might’ reimage 1 computer a year. Is there value in having 100 storage nodes? I’m not saying one way or the other is right, just think about what you are trying to achieve and how much management work you are willing to do.

Now in regards to dnsmasq, that is a service we can install on the FOG server. With our configuration it will send out pxe boot information to the local subnet its connected to. You don’t need to touch anything on the router or network. So when the mobile fog server arrives, so does the pxe boot information. When the mobile fog server leaves, so does the concept of pxe booting. In this design (mobile deployment server) the target computers are not designed to pxe boot through the fog server, but instead a tech sitting in front of the computer presses F10 or F12 during booting to get to the efi boot manager where the tech picks pxe boot.

Understand I’m just trying to tell you what’s possible. Since I don’t know 100% of your use case I can only give suggestions based on how FOG works.

@Thiago-Ryuiti said in Error generating image:

We did the entire procedure regarding changing the password and reinstalling fogproject,

Can you explain this? The reason why i ask is that there was some bad instructions on the internet that said to log into the fog server with the user fog and then install FOG. People were getting locked out of the fog account because the installer would reset the password. There was never an intent by the developers for admins to use the fog service account. So the developers changed the name of the service account to fogproject. So you saying “changing the password” is a bit suspect since you should never touch this account.

So what state is your install in at the moment? Can you ftp to the fog server using the account information in the .fogsettings file (ignoring the bit about sql server for the moment)?

@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

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