Git 8147 Enabling Plugins Breaks the Menu

[Tom Elliott]

@Wayne-Workman Any word on this?

[Wayne Workman]

@Tom-Elliott I didn’t enable or disable any plugins. I think one of the updates cleared the values for the boot menu like the OP shows, thats what mine looks like at work.

Things are still working though.

It’s been a busy two weeks, this has been on the back burner.

Most likely I just need to plug in the values again.

[Tom Elliott]

Menu Background File is:

bg.png

Main Colors defaults are:

colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||

Valid Host Colors are:

colour --rgb 0x00567a 0 ||

Invalid Host Colors:

colour --rgb 0xff0000 0 ||

Main Pairings:

cpair --foreground 7 --background 2 2 ||

Main fallback pairings:

cpair --background 0 1 ||
cpair --background 1 2 ||

Host pairings:

cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||

Exit to Hard Drive Type:

SANBOOT

Exit to Hard Drive Type(EFI):

EXIT

[A Former User]

@Tom-Elliott said in Git 8147 Enabling Plugins Breaks the Menu:

Menu Background File is:

Ah, I didn’t test re-inputting the menu after enabling plugins to see if it would hold. I’ll do that now and let you know what I find.

[A Former User]

@Tom-Elliott said in Git 8147 Enabling Plugins Breaks the Menu:

Menu Background File is:

bg.png

Main Colors defaults are:

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.

[Tom Elliott]

I still cannot replicate for the life of me, can you get a dump of your DB so maybe I can replicate and more directly see what’s going on?

[A Former User]

@Tom-Elliott
Strange. Here’s the database. This one is new so there’s not a lot going on yet though it is the one I’m having the issue with. 0_1467239575603_fog_backup_20160629_222957.sql
The same thing also happens whenever I change the web UI password.

[Wayne Workman]

Just updated from 8215 to 8359 and the boot menu settings stayed this time.

[A Former User]

@Wayne-Workman said in Git 8147 Enabling Plugins Breaks the Menu:

Just updated from 8215 to 8359 and the boot menu settings stayed this time.

Great! Thank you both!

[maxcarpone]

Hey guys!

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.

Cheers!

[Sebastian Roth]

@Developers Is anyone able to replicate this issue?

[Tom Elliott]

@Sebastian-Roth Unfortunately I’m not.

[Tom Elliott]

Can somebody give me exact details on what I can try to do to replicate this?

Also, please try deleting the /var/www/fog and /var/www/html/fog directories and reinstalling FOG. This issue you are reporting might be old information impeding functionality of the main system.

If you have custom data you may need, please backup the appropriate files as necessary.

[A Former User]

@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.

[Tom Elliott]

@Cavender what about on the most current? If you update the fields back to the default values and retry what broke it before, does it still clear the values out.

[maxcarpone]

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!

I know it’s not much but I hope it will help you.

Cheers!

[Wayne Workman]

@Tom-Elliott This isn’t yet resolved, it happened here.

I only just now realized that our boot menu configuration on our big fog server had been completely cleared, we went from a not-too-old trunk version to 1.3.0 RC1.

I’m manually setting them back with what you posted as the defaults a while back.

[Tom Elliott]

@Wayne-Workman I need exact steps to replicate. I have not had ANY success following anything anybody has stated to replicate this.

For all I know, somebody actually did clear all the fields. I’m not saying there isn’t a problem, all I am saying is I need a way to replicate exactly how to reproduce.

[Wayne Workman]

@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.

[Tom Elliott]

@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.

[root@mastaweb fog]# grep -rl 'setSetting' .
./lib/fog/plugin.class.php
./lib/fog/group.class.php
./lib/fog/fogbase.class.php
./lib/fog/host.class.php
./lib/fog/service.class.php
./lib/pages/imagemanagementpage.class.php
./lib/pages/pluginmanagementpage.class.php
./lib/reg-task/registration.class.php

These are all the files that actually us the setSetting method. This updates the global settings (FOG Settings on config page).

[root@mastaweb fog]# grep -rl "getClass('Service" .
./lib/fog/hookmanager.class.php
./lib/fog/fogbase.class.php
./lib/pages/fogconfigurationpage.class.php
./lib/pages/serviceconfigurationpage.class.php
./lib/pages/groupmanagementpage.class.php
./lib/pages/hostmanagementpage.class.php
./lib/plugins/capone/class/caponemanager.class.php
./service/donate.php
./service/servicemodule-active.php

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).