@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)
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:
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.
@Fog_Newb Yes, though maybe I can get the master release updated and it take hold for anyone from that point forward who gets 1771, but that’s not great practice, that we fall into better waiting the monthly release I think.
@Fog_Newb Did you update the init to the one you downlaoded after updating to 1771?
The init that it is pulling by default has the bad data.
@Fog_Newb I’m going to close this as it’s a duplicate to the Bug one. Thanks!
@Fog_Newb No.
You shouldn’t have to touch your fog install (overall) to test the latest init files.
Just download the init.xz file from the EXP_20250731 tag and either replace your existing /var/www/fog/service/ipxe/init.xz with it, or put the filename you want to use (init_20250731.xz for example) in the same folder and set the Host’s Host Init field to the filename you created.
Once that’s known to be working, you are welcome to update to the latest version of fog, but you would still have to do the same work for the new experimental init files. We could potentially work to make these working fos files the latest “release” which might fix the issue for you, but first would like to know it’s working.
Luckily init’s are released as a separate funciton so it wasn’t FOGProject 1.5.10.1771 directly, but just the init’s having issues.