Unable to create new image
-
You could try enabling mysql full logging and see what is going on when you try to add a new image definition:
# mysql --user=root -p ... mysql> SHOW VARIABLES LIKE "general_log%"; +------------------+-------------------------+ | Variable_name | Value | +------------------+-------------------------+ | general_log | OFF | | general_log_file | /var/lib/mysql/x220.log | +------------------+-------------------------+ 2 rows in set (0.00 sec) mysql> SET GLOBAL general_log = 'ON'; Query OK, 0 rows affected (0.00 sec) mysql> EXIT Bye # tail -f /var/lib/mysql/x220.log
Don’t forget to disable logging later on again or your disk will be filled up with the log file very soon!
-
Here’s the results of the logging. I tried creating image “tst1”.
342 Query SELECT COUNT(imageID) AS total FROM `images` WHERE `imageName` = 'tst1' AND `imageID` <> '0' 342 Query INSERT INTO `images` (`imageName`, `imagePath`, `imageCreateBy`, `imageTypeID`, `imageNFSGroupID`, `imageOSID`) VALUES ('tst1', 'tst1', 'fog', '1', '1', '50') ON DUPLICATE KEY UPDATE `imageID` = '', `imageName` = 'tst1', `imageDesc` = '', `imagePath` = 'tst1', `imageBuilding` = '', `imageSize` = '', `imageTypeID` = '1', `imageNFSGroupID` = '1', `imageOSID` = '50', `imageLastDeploy` = '', `imageFormat` = '', `imageMagnetUri` = '', `imageID` = LAST_INSERT_ID(imageID) 342 Query INSERT INTO `history` (`hText`, `hUser`, `hTime`, `hIP`) VALUES ('Image created: ID: 0, Name: tst1', 'fog', '2016-03-24 19:54:05', 'myIP') ON DUPLICATE KEY UPDATE `hID` = '', `hText` = 'Image created: ID: 0, Name: tst1', `hIP` = 'myIP', `hID` = LAST_INSERT_ID(hID)
-
@wrs2 There should be more output… please show us more from the log (5 lines before and after)
-
What happens if you try an insert by hand? See your mysql credentials in /var/www/fog/lib/fog/Config.class.php
mysql --user=username -p Enter password: ... mysql> INSERT INTO `images` (`imageName`, `imagePath`, `imageCreateBy`, `imageTypeID`, `imageNFSGroupID`, `imageOSID`) VALUES ('tst2', 'tst2', 'fog', '1', '1', '50'); ... mysql> SELECT LAST_INSERT_ID(); ... mysql> EXIT
-
@Sebastian-Roth
The manual insert of ‘tst2’ worked (confirmed in the web interface). The ID returned by the second query was 70.For the other parts of the database log, they appeared to be repeating entries (master-node related?)
342 Query SELECT * FROM `plugins` WHERE `pName` = 'location' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'accesscontrol' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'accesscontrol' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'accesscontrol' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'capone' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'capone' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'example' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'example' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'location' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'location' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT * FROM `plugins` WHERE `pName` = 'location' AND `pState` = '1' AND `pInstalled` = '1' ORDER BY `pName` ASC 342 Query SELECT COUNT(imageID) AS total FROM `images` WHERE `imageName` = 'tst1' AND `imageID` <> '0' 342 Query INSERT INTO `images` (`imageName`, `imagePath`, `imageCreateBy`, `imageTypeID`, `imageNFSGroupID`, `imageOSID`) VALUES ('tst1', 'tst1', 'fog', '1', '1', '50') ON DUPLICATE KEY UPDATE `imageID` = '', `imageName` = 'tst1', `imageDesc` = '', `imagePath` = 'tst1', `imageBuilding` = '', `imageSize` = '', `imageTypeID` = '1', `imageNFSGroupID` = '1', `imageOSID` = '50', `imageLastDeploy` = '', `imageFormat` = '', `imageMagnetUri` = '', `imageID` = LAST_INSERT_ID(imageID) 342 Query INSERT INTO `history` (`hText`, `hUser`, `hTime`, `hIP`) VALUES ('Image created: ID: 0, Name: tst1', 'fog', '2016-03-24 19:54:05', 'myIP') ON DUPLICATE KEY UPDATE `hID` = '', `hText` = 'Image created: ID: 0, Name: tst1', `hIP` = 'myIP', `hID` = LAST_INSERT_ID(hID) 342 Quit 343 Connect root@localhost on 343 Init DB fog 343 Query SELECT vValue FROM schemaVersion LIMIT 1 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC 343 Query SELECT * FROM `plugins` WHERE `pName` = '' AND `pInstalled` = '1' ORDER BY `pName` ASC
-
I actually just remembered that we have been having this problem after we updated the code from 1.1.2. After we updated, I had tried to edit an existing image and I was not able to. Looking at the php code, it seems that the same code is used for creating a new entry as updating an old one. So it seems to be an issue with our database.
Two things I noticed looking at our image entries in our database:
- Some images have 0, 1, or no value in ImageLegacy
- ImageCreateBy has users that no longer exist
Would these cause an issue?
-
@wrs2 Possibly one of your image entries has the imageID 0? Not sure why or how this can happen. It certainly should not be the case (at least not for FOG 1.2.0). Maybe I am wrong but please check your database:
mysql> SELECT imageID,imageName FROM images WHERE imageID=0; +---------+-----------+ | imageID | imageName | +---------+-----------+ | 0 | test | +---------+-----------+ 1 row in set (0.00 sec) mysql> UPDATE images SET imageID=99 WHERE imageID=0; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0
See if you are able to add new image definitions then.
-
Running:
SELECT imageID,imageName FROM images WHERE imageID=0;
returns:
Empty set (0.00 sec) -
So we took a look at our database and compared it to a fresh 1.2.0 database. The images table was missing the columns imageMagnetUri and imageFormat. After adding the columns (but not populating them), creating the image worked.
Thanks for the help!
-
@wrs2 Wow, would have never thought about that. Why would columns go missing?!?! Definitely not good!
-
@Sebastian-Roth I’m just guessing a botched upgrade path possibly. Something unforeseen and unpredictable failing to put in the new schema changes but still updating the schema version. I’ve seen it happen very rarely but I have seen it. I have no idea how to replicate the problem.
-
@Tom-Elliott From what wrs2 posted so far it does not seam that he’s tried to update!! Just plain FOG 1.2.0 installation which started to show a DB issue. Maybe I am wrong but that’s what I found from his explanations.
Edit: Sorry I somehow missed this from @wrs2’s post:
I actually just remembered that we have been having this problem after we updated the code from 1.1.2.
So Tom is probably right about this having been a schema update issue.