@x23piracy Let me see if I can explain it. I’ll explain the easy part first.

As you know with FOG, it has 2 exit modes. One is for bios type computers and one is for uefi mode computers. These exit modes actually tell iPXE how to leave the PXE boot menu. They really don’t come into play for imaging at all. Once imaging starts then FOS takes over rebooting the system. So in our case we can only instruct iPXE how to react.

So for bios systems they will only use the bios exit mode field. The same for uefi systems they will only use the uefi exit modes. Understand because of the way fog is setup, you can technically assign a uefi exit mode to the bios field. That would cause the system to not reboot correctly. So anyway to the point if you have a uefi system changing the bios exit modes for that host will not have any impact on the computers ability to reboot since it only looks at the uefi exit mode field.

Now the second part. What that refind error is saying is that you have a parameter in the scanfor line of the refind.conf file that says if it can’t find any uefi boot loaders, to look for bios boot loader in the firmware. The CSMD support error basically means that your firmware doesn’t contain any legacy mode boot loaders. In Dell terms this means that you don’t have the legacy roms enabled in uefi mode (which is only provided for backwards compatibility). So to fix this (unfortunate with refind and the way its currently setup is either all or nothing, we can’t have system unique refind.conf files) 1. Remove the parameter in the scanfor line in refind.conf to tell it to not look for CSMD firmware. 2. Enable legacy roms support in the target computer’s uefi firmware.

can you provide a clear screen shot of the error? helping to context of the error will give us an idea what part of the process fell down.

@ipxefoguser said in IPXE boot to fog cloud server:

I made the ipxe usb drive boot from the ipxe site. Maybe there is a different version but i certainly didnt see anything else.

while I know there was some additional discussions in this thread that I haven’t got to just yet, but this is the problem. You need to use the FOG iPXE files from the fog server, your ipxe files are missing the fog configuration scripts that are embedded into the fog delivered ipxe files.

@orioliz [Moderator’s note]: I forked this topic, we like to keep issues isolated so that when others find threads they don’t get confused because the subject doesn’t match the discussion.

The short answer here is that you need to install dnsmasq on your fog server to supplement the information you are getting from your dhcp server.

As long as the version of dnsmasq is 2.76 or later then you can use this configuration file for dnsmasq, and once updated will work perfectly.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_ip>,proxy

Update <fog_server_ip> with the IP address of your FOG server and you will be all set. dnsmasq will run along side your dhcp server but not change what it issues. If you turn off dnsmasq then pxe booting will be disabled again on your network.

@orioliz ok, we have two things we need to do to debug this.

1. what is the output of this command ls -la /tftpboot/undionly.* ?
2. If the above worked then we will need to capture a pcap of the dhcp dialog that is going on between the pxe booting computer and the dhcp and dnsmasq servers.

I’n not seeing anything wrong with your dnsmasq config file. (well one small minor things) the config file goes in /etc/dnsmasq.d/ltsp.conf The file you overwrote tells dnsmasq to look in /etc/dnsmasq.d. But no harm no foul.

Something just hit me. What is the output of this command dnsmasq -v I want to know what version of dnsmasq is installed. The below pxe boot message could be because you have an older version of dnsmasq installed.

Can we get a bit more details on the target computer?

Who made it and what model number?
Is this in uefi or bois (legacy mode)?
From the FOG iPXE menu did you see if the hardware was compatible with FOG? Did both network and disk pass?

@geardog I’ve seen this similar error when in uefi mode and the disk controller is set to raid-on mode.

Can you schedule another capture or deployment to this target computer, but before you submit the job, tick the debug check box then pxe boot the target computer. After a few enter key-presses on the target computer you will be dropped to a linux command prompt. At the command prompt please key in the following command.
lsblk and post the results here.

with centos 7 booted, can you post the output of this command
lsblk ? I’m suspecting that LVM is your disk format.

Also it would be helpful to know what version of FOG you are using.

@irfan4701 I’m going to suspect that with the ubuntu systems its using standard disk partitions. I know that at one time FOG couldn’t resize LVM disks so non-resizable was the only option. I thought the developers were working on that option, but maybe LVM resizing was on the roadmap and not actively being worked on.

@kagashe Reading between the lines here, If you have a storage node at each remote location, then that becomes your pxe boot server at the remote location. The location plugin, when configured, will direct the clients assigned to that storage node to image from that storage node.

Here is my POC tutorial to setup a synology nas as a FOG storage node: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

You need to watch directory permission on the synology NAS as well as nfs share permissions.

This appears to be an interesting issue. I might suspect that either the target computer either doesn’t have an IP network or something else is going on here.

Is 149.166.139.13 the IP address of your fog server?
If so then on your fog server key in the following command:
showmount -e 127.0.0.1

I see that you are using the https protocol? The ip address [149.166.139.13] points to in-info-fog.soic.iupui.edu?

Is the target (pxe booting host) on the same subnet (vlan) as the fog server?

I just saw something, you are booting this target computer with a FOS USB drive [boottype=usb]?

@kagashe Lets get some terms clear. FOG has two install modes. One is the normal FOG install. This creates a master node. The other install mode is a storage node. In a typically FOG configuration you will always have at least a (normal) FOG server install. This shall be your master node. You can have as many storage nodes as your organization needs. (hang in there I’m almost to the point of your question) You would typically place the master node at your HQ and storage nodes at remote sites.

At your HQ you would set dhcp options 66 and 67 to point to the master node. At each remote site you set your dhcp options 66 and 67 to point to your local storage node. That way you are not pulling any boot files over your site to site WAN connections.

@hammett131 ok I see why it doesn’t boot.

The device is saying its a uefi system (EF-BC type 7) but 10.0.2.1 is sending undionly.kpxe as the boot file name. The target computer promptly downloads the file and chokes on it. Its saying the next server is 10.0.2.122, which is your fog server?

@hammett131 If you can’t get your sonicwall to cooperate you can install dnsmasq on the FOG server to dynamically supply the boot information while you still use the sonicwall for dhcp services. There are a number of ways to get things working in your environment.

@ldiorio Interesting the scan delay setting was added intentionally to give the uefi firmware a chance to fully boot up before attempting to exit via refind. We may need to reconsider switching that back if it continues to cause an issue. It was turned on by default to solve a problem, but then it appears to have caused another.

Thank you for all of your fine detective work on this. Without the actual hardware in our hands, it hard to debug issues like this.

@chris-whiteley Why not just put a fog storage node on the other side of the link. Then you wouldn’t run the risk of over committing your WAN. You can define a specific replication bandwidth. That IS something that fog can manage. You could even use an older dual core desktop computer as a FOG storage node. FOG Servers don’t need a lot of resources.

Are you using fog’s linux service account called fog perchance? That linux user is managed and owned by the FOG application. If you change/reset this account you will have imaging issues.

@hammett131 said in UEFI Initializing devices.:

HP 4300

Is it just with the above model?
Just for confirmation we are talking about this model? https://support.hp.com/us-en/document/c03403843

Have you ensured you have the latest firmware installed on this device?

How many of these devices do you have on your campus?

What version of FOG are you running?

Where its getting hung up is booting the iPXE kernel, its hanging up on initializing the hardware. We have seen this with some crappy uefi firmware implementations. Usually a firmware update fixes the issue.