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.
@Fog_Newb It seems I introduced a bug on the init’s specifically surrounding a request to fail out if the Host Primary Drive is defined but not found to error out.
Effectively I tried to make a function more robust (normalize output data) but it only works on direct input rather than piped input. I’ve made a correction to fix this miss, but it will take about 2 hours to build.
Maybe I can get you to help?
I am currently building a new set of init’s under experimental: https://github.com/FOGProject/fos/tags
When it completes it will show up as EXP_20250731 (I think?) but if you can download the init and test it on your machine, this should fix the issue you found so thank you for reporting it.
@Fog_Newb For this host in question, are you indicating a serial number or wwn identifier for the drive? On this machine, it seems you have entered 21297930000130911023 on the Host Primary Disk field within the UI. Just trying to understand.
@Greg-Plamondon and @Clebboli are the Storage nodes associated to the same storage group?
For example:
Site 1 -> Default Group
Site 2 -> Default Group
Or are each storage node associated to their own Storage Groups?
The idea of storage groups is to spread the load of imaging. So if all storage nodes are part of the same storage group, then it makes sense the “jumping to different storage nodes within the group”.
While seemingly unexpected, the idea of jumping to other nodes within the same storage group is intended to balance the workload around as best it can. Sure this can probably be better handled, though I don’t know when I might get around to refactoring it. Just saying what I suspect might be happening.