My goal is to re-enable the Capone plugin because everyone misses it. To be safe, I’ve enabled plugins, installed Capone and set associations just to see if the menu would go back to good and it doesn’t.

@Wayne-Workman I suspect all is already fixed in the working area. You can create the log, and if you can see when/where/how the change happened, it certainly will help. I’m 98% sure it’s a specific set of actions necessary though, which is why I can’t seem to replicate it.

I’m certain it has nothing to do with the location plugin, just in case you were going to try with and without the plugin installed.

@Wayne-Workman Then I’d have still been able to replicate. There’s nothing in the bootmenu file that’s updating the global settings. (Either by use of setSetting method or updating the Service class).

In plugin class there’s the setSetting to update the plugin location (to always ensure it’s looking at …/lib/plugins) but it is only impacting a single field. Nothing to service at all.

In the plugin page There’s two new entries created/updated but this is only relevant to the Capone plugin. The insert of the new items is handled directly within the CaponeManager class, and the updating is handled only to the dmi and image association.

These are all the files that modify the “setSetting” by means of the Service class. This particular output just displays if the class is called.

lib/fog/hookmanager.class.php: This is definitely not the issue.
array_map($specTabs,(array)self::getClass(‘ServiceManager’)->getSettingCats());

lib/fog/fogbase.class.php: This is definitely not the issue.
Line 259: $serviceEn = self::getSubObjectIDs('Service',array('name'=>array_values($services)),'value',false,'AND','name',false,false); This is not updating any values.

Line 543: Whole method is getSetting. This is just getting the setting information. No writing.

Line 547: Whole method is setSetting. This actually writes data. Only based on the key that’s sent and the value. If either key or value are blank, the whole method will cause a Fatal Error. No update is performed on fatal error.

lib/pages/fogconfigurationpage.class.php: Most likely where things are going awry.
Line 139: Gets the list of services to see. No writing. – This is definitely not the issue.

Line 208: Saves new info to the DB, only impacts the keys as defined in $ServicesToEdit. – This is definitely not the issue.

Line 507: Just gets the setting categories (no writing). – This is definitely not the issue.
Line 510: Gets the fields under the category listing for that iteration. No writing. – This is definitely not the issue.

Line 752: Loops through all the Services to write later on. This is most likely the issue. The problem, though, is the way it updates the data. There are numerous checks. First one is it checks that the item it’s working on actually needs to be updated in the first place. If it needs an update (which ultimately means something changed previously) it will perform the next level of checks. For the next RC I’ve changed the updater from “update” to “set” so it should only impact the item it’s working on to begin with. – Most likely the issue, and hopefully is completely fixed in RC update channel. (Not RC 1).

lib/pages/serviceconfigurationpage.class.php: Unlikely the issue | Fairly certain this is not
Line 265: Updates if the module selected is to be on or off and updates defaults. Only interacts with the specific item. Updated to use a single call rather than an array shift in RC.

lib/pages/groupmanagementpage.class.php: Definitely not the issue
Line 399, it’s used to get the information of the service and print it to screen. No update/write there.
Line 419, used to get info of the service and print to screen. No update/write there.
Line 587, used to get the values of the global setting in case it’s not defined in the group during edit. Info is then passed to the host where it’s updated directly to the main item. Yes a write, but not updating multiple fields accidentally. Only impacts its particular element to all hosts. At this point, however, it’s only for lookup, as writing goes to a totally separate table.

lib/pages/hostmanagementpage.class.php: Definitely not the issue
Line 484, same as line 399 of groupmanagementpage.class.php No write/update.
Line 504, same as line 419 of groupmanagementpage.class.php No write/update.
Modules/services are passed to a separate table.

lib/plugins/capone/class/caponemanager.class.php: Definitely not the issue
Line 16: Inserts FOG_PLUGIN_CAPONE_DMI (not a multi update write)
Line 22: Inserts FOG_PLUGIN_CAPONE_REGEX (not a multi update write)
Line 28: Inserts FOG_PLUGIN_CAPONE_SHUTDOWN (not a multi update write)
Line 41: Deletes the entries created in 16, 22, and 28.

service/donate.php: Definitely not the issue.
Line 9, used to find setting, no write.

service/servicemodule-active.php: Definitely not the issue.
Line 3, Passed to a Module (not the Service itself) and only used to ensure services are enabled (usually at host AND global levels).

@Tom-Elliott We have the location plugin setup and configured, I didn’t do anything special.

In fact, the only time I even visit this settings area is to correct this problem, which has been twice now I think.

All I did was update the main, and then update the storage nodes after that. We’re not removing any plugins, we’re not adding any plugins. Things are setup just the way we want.

It’s just a gut feeling, but I don’t think the update is breaking it. I tend to think that something in FOG Settings somewhere is writing values to the boot menu settings when it shouldn’t - just a guess.

I updated a few days ago to Git 8450 and it works as expected now so I can’t reproduce the problem I encounter before.

I can add details about my installation : was a fresh install of Git 8xxx on june 20th, I don’t remember which version it was exactly (if someone tells me where to look for to find the previous version?). Then I imported hosts, groups and images from csv files and I’ve just set my common parameters like they were on my old server.
A bit later, I booted a computer from PXE and saw the blue screen so I checked my installation and saw the “PXE Boot Menu” was empty so I filled it up. Then I rebooted my computer and it was ok except for the keyboard layout. I changed it in “general settings” and once I came back to the “PXE Boot Menu”, everything had disappear!

@Tom-Elliott I saw this on a clean install of 14.04, fresh git of 8147 (latest at the time of install) and a fresh database:
Everything is up and running great -> enable plugins and save -> the menu config is cleared and everything still works though the boot menu is now classic blue background, white text and red selection bar.

I registered to add more informations to this bug. I recently build a new fog server and I encountered this bug. I didn’t know what to do to make the background image back to what it was with my previous server and I found this thread!

I upgraded this morning to version 8405 and this bug is still there.

What it does is wiping out all the informations in “iPXE Boot Menu”. I added all the details in this menu after seeing this thread and as my keymap wasn’t working, I decided to try the fr-latin1 instead of fr-latin9. As soon as I saved the general setting, it cleared the “iPXE Boot Menu” informations.

By the way, my keymap still doesn’t work! I can’t swap the keyboard to the French language.

So enabling plugins clears both the menu background file and the advanced menu. Manually replacing these after plugins are enabled and saving does maintain both menus with plugins enabled. If I look to verify that plugins are still enabled (and they are), and just for giggles click “save changes” at “Plugin System” the menus are cleared again.