@AngryITGuy The iPXE file likely needs the boot shim or whatever to allow things to work correctly and with upgrades this isnt’ really feasible as every newly built ipxe file (snp.efi, snponly.efi, etc…) would need that shim configured and installed in place.

It’s possible there was a step in the original installer from your collegue that may have moved the ipxe files from a backup where these were shimmed appropriately?

I don’t know exactly just spitballing.

Ultimately, yes, I’m glad you got this working by disabling secure boot.

Technically, it’s possible to do this with secure boot, but not in an easily scalable way that we can include as part of the install script. Nor, in reality, do I think we want to do such a thing. While it’d be nice to do it as an installer, I am hoping we can get a document that more clearly details what steps to do. This is mainly due to the constantly changing nature of fog, so if we have an easily repeatable knowledgebase on what steps to do in a well documented sort of way, it’d be a lot better than trying to have us maintain some installer that could easily have some issue on a new iteration and continually have to maintain yet more blocks of potentially os dependent code.

@darbizzle The /images/dev/<mac> is the image, so as long as you are certain that’s the one it should be, you can move it from /images/dev to /images as the image path name as defined, likely /images/PDMDTRuggedWIN11DB9-2-25

I think that’s a good starting point, I was just pointing out (due to having not seen the ‘image store error message in plain print - if i’m being a slight bit honest’, but the update to 1.5.9.114 vs 1.5.10.1673 is odd to me. 1.5.9 is very very old. Updating to the latest may not have fixed the problem, but it’s always better to at least be up to date so what we’re seeing is all in line.

@darbizzle Why did you update to 1.5.9.114? We’re at 1.5.10.1673 on the stable branch

That said, I don’t think this is that, as it’s failing to actually prepare the partition.

I suspect its because the init you’re using is MUCH newer than the version of FOG you’re using. So maybe variables and tests are missing.

@dejv 1.5.10 is quite old, though is the master I suppose.

We have bene doing stable branch releases more autonomously with likely newer versions of the kernel.

With that said, however, this appears to be kernel related.

Of course first question just to ensure all is right:

UEFI Secure boot is temporarily disabled correct?

Please attempt to update your kernel to a newer version.

You can do this in the UI from FOG Configuration Page -> Kernel Updater

Find the latest version and try that, and work back if necessary for older versions. I suspect one of these will work better for your needs.

@chunter2 This domain does not exist or dcouldn’t be contacted seems to be indicative of the problem. Simply put, from the message you show, it seems the DNS isnt’ able to reach the domain controller.

I highly doubt this is due to the version of FOG based on this, but my perspective is obviously very limited at this point.

@Fog_Newb I don’t know how to replicate the problem you had unfortunately, but I believe I made a fix for the issue you were having. The function is expecting the parameter to be a string, and we were sending a null. I’m now going to have it send in an empty string instead which should prevent that problem moving forward.

Thank you.

I still wish I could get you to look at 1.6 but I understand the hesitation

@Fog_Newb Can you provide your http/php error logs?

See my signature for locations (or very similarly close to)

@plegrand

I don’t know if it will work or not.

We had one person try it, and I just got around to adding what they suggested as found here:
https://github.com/FOGProject/fogproject/pull/733

I think it will work just fine, but we won’t know for sure until someone tries. What works for one may or may not work for another, so your mileage may vary.

@janez3k said in Fog iPXE Menu no input:

https://pastebin.com/xWhJkDX1

Thank you for this, I have copied and pasted what you have. The only part i noticed (though I left it for now) is the missing building of ncm--ecm-axge

I don’t know that this file is particularly in use so I think it’s safe to keep out but If I’m wrong I’m sure we’ll learn about it quickly enough.

I have pushed this version of the IPXE building script to both working-1.6 and dev-branch.

This won’t become part of the release until the 15th of September (at this point), but is available for testing on the bleeding-edge/beta channels.

@ProfessorFow There is the ability to replicate images across groups. You can set which “groups” images need to replate to by associating images to multiple storage groups. You can even define which storage group is the primary.

@ProfessorFow If you create storage nodes, and this is the worry, separate them by Storage Groups.

My guess is all your storage nodes, right now, Remote/local/etc… are all part of the same storage group.

It doesn’t know your latency situations or that any specific node is “Remote” vs. local.

All it knows is “I have x nubmer of nodes in my group, I’m going to use the one with most resources available to run to perform the task at hand.” if no nodes are busy at the time, it’s whatever is the first to return.

If you have “local” nodes, keep them in a group, and if you have remote nodes, keep those remote nodes localized by their own storage group.

Storage groups can be any method you choose, though I’d recommend keeping subnets as different storage groups.

@RAThomas If the value is empty it shoudl think it’s false, and since it seemed to be random that’s where I got confused. But I’m glad this is working for you.

Thank you!

So once tasks get created it will have 'taskDebug`

set to 1 I believe:

so Maybe;

select * from tasks WHERE taskDebug=1;

It may help point us to why you’re seeing them go into debug. Theres a few other options though may need a remote session (if and when you’re able and I’m able as well I suppose?) to try to troubleshoot a bit further.

@RAThomas I’m concerned that it’s randomly entering debug. If it were all machines, all the time.

That said, when you create the image you can define the task type to also include debug mode.

can you walk us through the exact steps?

If it were all, you’d look at fog settings.

The UI probably shows it as just Kernel Args, or something similary:

The DB side would be:

select * from globalSettings where settingKey = 'FOG_KERNEL_ARGS'\G

Sorry for not having a clean direct answer right away, but working through it is all we can do right?

@RAThomas If you’re comfortable with mysql, I might suggest taking a look at the database:
You’ll have to get your fogmaster password from the /opt/fog/.fogsettings file. snmysqlpass

sudo mysql -u fogmaster fog -p

select hostID,hostName,hostKernelArgs where hostKernelArgs LIKE '%debug%';

This might not be the best way but since I don’t know where the debug will show up in the hostKernelArgs, this is the best method I can give right now.

Most likely, I believe, you’re going to see your hosts with these.

If that doesn’t yeild anything, are the hosts part of a group? in which case the group likely has the kernel arg also, so check with:

select groupID,groupName,groupKernelArgs where groupKernelArgs LIKE '%debug%';

I’m suspecting one if not both of these will yield you back the results to help you fix the affected items?

@mrowand We’ve been trying to figure out exactly what to do using the MB Raid methods to detect a disk.

While there are seemingly some configs that will take motherboard RAID in a format that is detectable to kernels, there’s not one option I’ve been able to find (as of yet) that will do this natively.

Unfortunately, the solution is your secondary option (at this point) -> Set SATA mode to AHCI and either reinstall Windows 11 on the AHCI mode, or perform your Registry hacks.

Believe me, I’d much prefer to have the kernels just detect the MB raid modes.

@Clebboii These warnings are safe to ignore. While the REQUEST_METHOD issue you’re seeing has already been fixed in dev-branch, the dashboard page issue you’re seeing is just because sometimes the values are set, sometimes they’re not. Unfortunately there’s no real way to validate cleanly. (at least right away or easily at this point in time. But it’s not causing issues.)

I’m not seeing there being issues with the files syncing? It seems, to me, the location it’s sending the file to (192.168.140.39) isn’t accepting ftp?

@Fog_Newb probaly just typoed it and i went with it too lol.

@Fog_Newb Yeah, we did release the experimental as the “release” version so it should be the same init you get for 1667 or 1771 now.

@Fog_Newb The fos release has been officially updated so if you were to do a full fresh update, it should pull the version you just tested automatically.

Thanks for the testing.