As of 17.05.01, I was told there were reports of successful installations. However, I have not been able to reproduce such. I had earlier made a couple of attempts to add Koha to a multipurpose appliance, and that remains my end goal. However, when I tried to back up, I saw the same issue verbatim. What I have done today was: Download a fresh Linux Mint 18.1 ISO. Build a VirtualBox VM with the ISO, with mostly default features and with third-party addons, and also enabling auto-login, but in general intended to be a plain vanilla install. Rebooted; installed Chrome and touched /etc/sudoers, ran "aptitude update"; ran "aptitude upgrade", installed MariaDB, and rebooted again. Followed the steps, including a couple of a2enmod enablings, and created a virtual site. I was able to edit passwords in /etc/koha/.../koha-conf.xml, and enter the web setup wizard. However, I experienced identical output from the installer: at a certain point, it says: > Software error: > > DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'root'@'localhost' at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1492. at /usr/share/koha/lib/Koha/Database.pm line 100 For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. I am having difficulties with MariaDB and my difficulties may be contributing to the problem. My understanding, as inherited from MySQL, is that "mysql -uroot -p", for any account that will run it, will check a password and, if you have root's password set, will let you into the MySQL root command line if and only if you type the password exactly. The behavior I have observed is that as root "mysql -uroot" does not prompt for a password, but just logs you in, and "mysql -uroot -p" prompts for a password, but will accept any password, the empty password included. However, from an unprivileged account, "mysql -uroot -p" prompts for a password, but none of the passwords I've tried have worked; I've tried and used values as set in my customized koha-conf.xml, and every single password is rejected. I believe that this command line behavior is a symptom of the same problem quoted above: permission is being denied for user 'root'@'localhost' where the action in question would be permitted for any account with UID 0 and no account with any other UID. Again, this is after the 17.05.01 release, where it was reported to me that some people have had success. The system setup shows a couple of my personal idiosyncracies, but is meant to be awfully close to a procedure of "Step 1: Create a new Linux Mint VM. Step 2: Install Koha." The behavior is the same between the fresh new VM running 17.05.01, and an "everything but the kitchen sink" multitool of an appliance. C.J.S. Hayward https://CJSHayward.com
Please bring this up on the mailing list - many more people are reading there. There is probably only a handful reading the incoming bug reports.
From a mailing list response, after things are working: -- Tim Young <Tim.Young@lightsys.org> 8:56 PM (17 hours ago) to koha Hi, This sounds like it is because of an odd "feature" of mysql which is not always present. This page: https://askubuntu.com/questions/766334/cant-login-as-mysql-user-root-from-normal-user-account-in-ubuntu-16-04 with the answer from "Todor", explains that mysql will change over to using an auth_socket "plugin." So, instead of using password authentication, part of the permission is blocked by unix file-level permissions. The simple solution: sudo mysql -u root update mysql.user set plugin = 'mysql_native_password' where User='root'; FLUSH PRIVILEGES; Then you should be able to connect up as root even if you are not a root user. After that, you should be able to run the script. - Tim