I am not sure if this is the right Stack Exchange to post to or not (StackOverflow figured it belonged elsewhere, so maybe it will do better here?) but I keep receiving this MySQL error when I try to install Magento2 on a VPS (Centos6, MySQL 5.7.11):
SQLSTATE[HY000]: General error: 1030 Got error 168 from storage engine
I have searched around and have found that it has to do with
InnoDB not being able to write to its data files. I have also found that people who have had the same
1030 error mostly receive a
28 error and both are easily identified as 1)
innodb_force_recovery set to greater than 0 (I don't have this set in my
my.cnf file), and 2) not enough disk space (I have 5GB left on the drive mysql is on).
I should note that it installs anywhere from 136-162 tables fine before it stops and errors out. After that I try to add the last table it errored on manually, it then exhibits symptoms similar to this issue:
The MySQL manual says:
"Check the %d value to see what the OS error means. For example, 28 indicates that you have run out of disk space."
So my question(s) are:
- Does anyone know what the
168code means? -OR-
- Where to find the list of "%d value" errors so I can hopefully get some idea for what else to try? I have Googled
%d value mysqland other versions of these search criteria and don't get back any results of value (that I can decipher anyway)
What I have tried thus far:
- Adding a line to my
fstabto up the storage of my
/tempfolder to 2GB
- I have tried to repair tables (which actually was not a good idea, that messed up a bunch of stuff)
- I tried to run the
mysql_upgrade(I recently updated the MySQL install so I could install Magento2 so I was hoping I forgot to do that and that might work)
- Various other tinkering-type things that probably broke something else I don't know about...
If anyone has any insight on where these
%d descriptions are or can point me in the right direction besides what's already out there for the
28 versions of this error, I would appreciate it. I am not a Database expert at all, but I've never had so much trouble installing into a database before, usually it's pretty straight forward.
After reviewing the log, this is the top-most part of the error and is the table it failed on:
2016-05-15T15:08:22.610729Z 240 [ERROR] InnoDB: Unable to lock
./magento_test2/authorization_rule.ibd error: 37
2016-05-15T15:08:22.610789Z 240 [ERROR] InnoDB: Operating system error
number 37 in a file operation. 2016-05-15T15:08:22.610840Z 240 [ERROR]
InnoDB: Error number 37 means 'No locks available'
2016-05-15T15:08:22.610879Z 240 [Note] InnoDB: Some operating system
error numbers are described at
2016-05-15T15:08:22.610896Z 240 [ERROR] InnoDB: Cannot create file
'./magento_test2/authorization_rule.ibd' 2016-05-15T15:08:23.025333Z 0
[ERROR] InnoDB: Unable to lock ./magento_test2/quote_address.ibd
error: 37 2016-05-15 08:08:23 0x7f968ae75700 InnoDB: Assertion
failure in thread 140284552238848 in file fil0fil.cc line 884 InnoDB:
Failing assertion: success InnoDB: We intentionally generate a memory
trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be InnoDB:
corruption in the InnoDB tablespace. Please refer to InnoDB:
InnoDB: about forcing recovery. 15:08:23 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this
binary or one of the libraries it was linked against is corrupt,
improperly built, or misconfigured. This error can also be caused by
malfunctioning hardware. Attempting to collect some information that
could help diagnose the problem. As this is a crash and something is
definitely wrong, the information collection process might fail.
I guess it's just not working very well in general.