Storage ID 0 is not valid / A valid database connection could not be made
-
Also, either user should work given the grants in MySQL.
mysql> show grants for fog;
±---------------------------------------------------------------------------------------------------+
| Grants for fog@% |
±---------------------------------------------------------------------------------------------------+
| GRANT USAGE ON . TO ‘fog’@‘%’ IDENTIFIED BY PASSWORD ‘2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19’ |
| GRANT ALL PRIVILEGES ONfog
. TO ‘fog’@’%’ WITH GRANT OPTION |
±---------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)mysql> show grants for fogstorage;
±----------------------------------------------------------------------------------------------------------+
| Grants for fogstorage@% |
±----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON . TO ‘fogstorage’@‘%’ IDENTIFIED BY PASSWORD ‘2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19’ |
| GRANT ALL PRIVILEGES ONfog
. TO ‘fogstorage’@’%’ WITH GRANT OPTION |
±----------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)mysql>
-
@entr0py I confirmed the storage id 0 is not valid issue. Mind you, this was literally just a message. The node was indeed created and functional even though this message was there.
When you create a new node, the page redirects to the “edit” page. This edit page needs to have the id passed into it. I missed passing it the “edit” portion and had the id being incorrectly set.
While this was a very minor bug, I have republished as RC-20. Sorry for not noticing it sooner.
-
Any thoughts on why the storage node still doesn’t work? If I try to create a task it says the node doesn’t exist. If I try to create a task I get the following:
If I try to show the node on the dashboard it isn’t even listed:
If I try to image a computer using “Deploy Image” on GRUB menu:
-
It’s seems it’s connecting to the db now, but we can’t seem to connect to the other nodes.
This might be due to two things.
I modified a function to help ensure the nodes are available before getting data. The
()
on the nodes tells me the main server is unable to request the other nodes’ urls. This might simply be because the isAvailable is using a connection timeout of 500 ms. Maybe this is just too short to see those servers? It worked fine in my testing, but my nodes are admittedly within the same network I am. To test this theory, please open up the file:/var/www/fog/lib/fog/fogurlrequests.class.php
.At lines: 271 and 327.
Please make them read as:
$options[CURLOPT_CONNECTTIMEOUT_MS] = 2000;
I think maybe then you’ll start seeing data filling in these areas?
-
and I think that will fix for the unable to create the task issue for you too. (The changing the timeout to 2000 miliseconds).
-
That might be the problem considering I don’t even have that file…
root@FOG-Virtual-Machine:/var/www/fog/lib/fog# ls -lsa quests
ls: cannot access quests: No such file or directoryThose are supposed to be asterisks for anything quests anything. I only have one file in the whole lib/fog directory with a newer date than August 13 2014…
-
-
Upgraded to 6007 on both host and node, made the change you suggested and still nothing. Same routine.
I created another node with all the same settings, placed it in the same storage group, disabled the old node and enabled the new one and still nothing. If I select that storage group on the dashboard it shows 0/0/0 with and the node doesn’t show in the list either.
-
@entr0py your issue brought another partial issue for what I would call doubles. At one point the server only used /var/www/fog for ubuntu (this is usually set as a link now).
Please try running:
rm -rf /var/www/fog; ln -s /var/www/{html/,}fog
This should allow the server to see the files regardless of how you’re accessing the data (why you didn’t see fogurlrequests).
-
Remoted in and found that the server was in fairly funky state.
It is ubuntu 12.04, and while we typically recommend to update, this particular issue was simply due to ondrej attempting to install php 7, but the packages variable on fogsettings was pre-labelled as php 5. Removed the packages variable and php/apache on the node, updated the php version stored in the fogsettings, reinstalled ondrej, and re-ran installer .