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

@mttpr1 Thanks, that was basically it - apparently the Surface dock itself has a MAC address, so that’s what was causing the issue. No way around it really, but at least I know what the problem was. Thanks for pointing me in the right direction!

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

@alexamore90 There is a test function in fog, yes.

But it’s not a “passthrough test” that I think you’re imagining.

It’s literally there as a task to test the disk, as some times a disk can show no issues, but have a bad sector or the head cannot move to that position. With some things testdisk is extremely helpful, but there’s not a “combined effort” of testdisk, currently, that would provide that functionality and I would not suggest it being used unless you know the drives are spinners.

In the case of SSD disks, there’s no real moving parts, and while it might have a test mechanism on its own, this task type should not be used for them.

@george1421 Thank you for the information. It makes sense it would be the OS of the server. I just wanted to make sure that was the case. I spaced on the web UI as I have not been in that for quite some time. I think this answers all of my questions. You can Solve the case (I don’t see where I can do this if I do have that as an option).

@Tom-Elliott
Thanks, The URL is correct! My issue has been resolved.

@Tom-Elliott I’ve done that. I’ll try swapping the drive but I am fairly confident that’s not the issue.

@iljared98 There is a way. The CSV will contain more information than just the Motherboard Product Name, but that is easy to clean.
On FOG, go to the Reports tab and select Inventory Report from the left side menu. Don’t change anything there, just click on Search. Download the CSV from the page using the excel sheet icon. When you open the CSV, column R should be mbproductname which is what you are looking for.

@youzersef It looks like that is for HDD I am using an SSD. I followed the steps anyway and it has changed the error but its freezing up in the same spot still. New Error

@george1421 That did the trick. Now I need to dig into why its failing to capture an image. I’ll make a different post for that though if I need to.

I had to make a correction. I meant to say pre-1Gbit internet not 10Gbit internet. We have 10G backbones (intranet) but not to the internet.

@mikael1909

Hello,
try this.

https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#example-1

After many try&error runs, I managed to sign the files and to boot into the FOG menu with secure boot enabled. And I can deploy an image, register the host and do all the other things except boot from hard disk. Whenever I choose this option in the FOG menu he just goes back into the menu.
When I boot directly from the hard disk it works and also if I disable the secure boot option the FOG menu can boot from hard disk.

What could be the problem here? Oh and while I was troubeshooting I updated Ubuntu from 20.04 to 22.04 and FOG to 1.5.10

@Tom-Elliott That did not have an impact. still seeing ${serial} on the host list. If it helps I am also seeing at the bottom of my host management page

${pingstatus} ${host_name} ${deployed} ${image_name} ${serial}