@tesparza Well we need to get a few things straight here.

I assume you are building a uefi golden image? When deploying it to a target computer (vm) is that VM in uefi mode? For the uefi firmware, if it detects a uefi boot disk it will add that boot disk into the boot manager. If it can’t locate a valid uefi boot disk, it will only display uefi pxe booting options. Remember that you can only deploy a uefi source image to a uefi target computer, the same holds true for a bios source image, it can only go to a bios based target computer.

I would start out by making sure your source and target VMs are setup the same way, bios, memory, disk and such. If they are then you can start to debug this issue by scheduling another deploy task to the target VM but before you tick the schedule task button, check the debug checkbox. Now pxe boot the target computer. After a few screens of text on the target computer you should be dropped to a fos linux command prompt. Understand where you should be is on the target computer where you just previously deployed the image, but now you are in debug mode. Key in the following command, lets see what the existing disk structure looks like lsblk

Once we know that we can debug this issue a bit more.

@sebastian-roth
That’s true, but every time I upgraded either fog or the OS, something would break. I used to have the advantage of Tom Elliott being available to assist in these cases, but he never returns emails or phone calls from me in like nearly 2 years.

@Trev-lchs Have you played with the mentioned refind.conf yet? Search the forum for more hints in this topic.

Which versions of rEFInd have you tried? All of them?

@Wayne-Workman I am pretty sure I did a plain test install with 1.5.9 on CentOS 8 and it worked. Will try again.

@rodluz said in Very slow boot.php and bzImage during pxe boot:

(gc64d)

OK that’s definitely the current iPXE version I pushed to dev-branch not long ago.

Thought that you might have different DHCP options set that might explain the issue. But doesn’t look like it.

Hmm, you can try updating to dev-branch but I can’t think of a change we pushed since 1.5.9 that would explain what you describe. Anyhow, give it a go.

@robertkwild yes, it can.

@lps The location plugin is not quite that sophisticated. You assign storage nodes to the location and then the registered hosts to a location (the location field is added when the plugin is installed). That way a pxe booting target computer knows how to find its storage node.

For bulk setting the location on a group of computers, create a FOG (set) group. Assign the hosts to that FOG (set) group then use the group to assign the location to the target computers in that group.

(FWIW FOG Groups don’t work the way you might think a group works. They are more for setting a number of computers one or more values at one time. They are not persistent groups).

@sebastian-roth Hi Sebastian,
Sorry the original bzImage is 4.19 and when I return to it, i get the original report that the drivers for the card aren’t loaded. I’ve just tried bzImage5.6, and it freezes in the same place. However if I run dmesg I get a ton of nfsd error where it is shutting down the socket.
Jul 28 14:00:06 fogdep in.tftpd[3689]: Client 192.168.101.86 finished snp.efi
Jul 28 14:00:26 fogdep in.tftpd[3714]: Client 192.168.101.86 finished default.ipxe
Jul 28 14:01:12 fogdep rpc.mountd[1432]: authenticated mount request from 192.168.101.86:795 for /images (/images)
Jul 28 14:01:14 fogdep rpc.mountd[1432]: authenticated mount request from 192.168.101.86:947 for /images (/images)
Jul 28 14:01:55 fogdep kernel: rpc-srv/tcp: nfsd: sent 5556 when sending 32896 bytes - shutting down socket

@jherron

I was able to resolve my own issue. ID10T error.

After reinstalling the storage servers at the respective sites and reassigning them to their groups, i had forgotten to set the locations plugin. After i set the servers in the location plugin everything resumed working as normal.

Hi,

It was my firewall, I have rebooting a rule and now all is fine.

Thank u

@dustindizzle11 Nice! Let us know what you find.

We have new FOS Linux kernel version released since then. Though it’s only just minor update you might give it a try. Also try out older kernels (e.g. 4.x) just in case.

Also you might test Live Linux ISOs with different kernel versions. If you find a more recent kernel (newer than 5.10.53) is fixed, then let us know.

@kaylax08 I also turned SSM off.

@austinjt01 said in Lenovo P52 - Stuck on iPXE 1.20.1:

Yes still stuck at the handoff to FOS.

One option you can try is to compile the latest version of iPXE. There has been some updates to iPXE since 1.5.9 has been released. There may be some value in trying the process outlined by Sebastian here: https://forums.fogproject.org/post/141618

You will need the github version of the fog installer to follow these steps.

@sebastian-roth I have a holiday this August, I’m going to make the translation and I’m going to try it out in my organization, we have several FOGs. When I see it well, we talk about it

ah, Congratulations to everyone on the project

@Tom-Elliott can you get me curl command or minimal list json params to create image in fog ?
Thanks

@george1421 great! by habit we turn secure boot off. i have someone looking into attempting to capture in a while to see what we get. thanks for all of your help so far.

For anyone else coming across this thread, we had the same problem. The iPXE from the latest version of FOG (1.5.9) did not work, but building the latest iPXE binaries using the instructions on this post worked fine:

https://forums.fogproject.org/post/141618

After that, the Linux kernel we were using also worked fine.

@jasonnaughton said in Resize CentOS7 fails e2fsck:

read image_hdr error=0

On first sight I would think the image file is corrupted.

Can you try the other files as well?

@wkratky said in FOG Update IPXE Issues:

I have been attempting from the fogproject-1.5.9 folder. Does it matter or does it have to be ‘fogproject’?

Folder name doesn’t matter.