Bug 21273 - After upgrade from 17.11.08 to 18.05.02 intra not working, Software error: Template process failed
Summary: After upgrade from 17.11.08 to 18.05.02 intra not working, Software error: Te...
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Installation and upgrade (command-line installer) (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 18336
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-27 11:21 UTC by Elias
Modified: 2020-01-06 20:14 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot phpmyadmin (48.79 KB, image/png)
2018-08-27 11:21 UTC, Elias
Details
Alter Table not working (162.71 KB, image/png)
2018-08-31 14:42 UTC, Michael Oehrlich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elias 2018-08-27 11:21:20 UTC
Created attachment 78177 [details]
Screenshot phpmyadmin

After upgrading from 17.11.08 to 18.05.02 we get the following software error on the intra:

Software error:
Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): Table 'koha_koha.branches' doesn't exist in engine at /usr/share/koha/lib/Koha/Objects.pm line 269

Users can't login on the OPAC and a search from the opac throws the following error:
DBIx::Class::Storage::DBI::_dbh_execute(): Table 'koha_koha.branches' doesn't exist in engine at /usr/share/koha/lib/Koha/Objects.pm line 129

It seems like there went something wrong during the upgrade process.

With phpmyadmin we can see that the table 'koha_koha.branches' is still there but the collation is shown as in-use. If we try to select this table we get the following error:

#1932 - Table 'koha_koha.branches' doesn't exist in engine

The same error occurs on three other tables:
 borrower_attribute_types
 categories
 currency
Comment 1 Jonathan Druart 2018-08-29 17:45:32 UTC
If it happens on your test system I would replay the upgrade.

You can also try
  REPAIR TABLE `table_name`
Comment 2 Elias 2018-08-30 09:36:10 UTC
Just tested it with the 18.05.03 update.
The upgrade went fine, but after a server restart the same issues occur.

REPAIR TABLE fails with message that the table doesn't exist in the engine
Comment 3 Michael Oehrlich 2018-08-31 14:42:06 UTC
Updated the MariaDB Version to 10.2.17-MariaDB-10.2.17+maria~xenial
Than it works. Probably the update script should check this. See attachment.
Comment 4 Michael Oehrlich 2018-08-31 14:42:52 UTC
Created attachment 78330 [details]
Alter Table not working
Comment 5 Jonathan Druart 2018-09-14 22:48:10 UTC
(In reply to Michael Oehrlich from comment #3)
> Updated the MariaDB Version to 10.2.17-MariaDB-10.2.17+maria~xenial
> Than it works. Probably the update script should check this. See attachment.

Which version did you have before?
Comment 6 Michael Oehrlich 2018-09-17 06:50:09 UTC
(In reply to Jonathan Druart from comment #5)
> (In reply to Michael Oehrlich from comment #3)
> > Updated the MariaDB Version to 10.2.17-MariaDB-10.2.17+maria~xenial
> > Than it works. Probably the update script should check this. See attachment.
> 
> Which version did you have before?

10.0.36

https://packages.ubuntu.com/de/xenial/mariadb-server

Last stable version from package manager. The update is only possible if we are using an additional mirror.
Comment 7 Katrin Fischer 2018-10-28 18:33:10 UTC
Hi Michael, were you able to solve the problem? 
Is there a chance that you have additional indexes or similar or some other changes to standard?
Comment 8 Michael Oehrlich 2018-10-29 07:31:20 UTC
(In reply to Katrin Fischer from comment #7)
> Hi Michael, were you able to solve the problem? 
> Is there a chance that you have additional indexes or similar or some other
> changes to standard?

At the moment on Ubuntu 16.04.05 it is not possible to get an official release upgrade from mariadb. On Ubuntu 18 it's "10.1.34-MariaDB-0ubuntu0.18.04.1". Out of the box that doesn't work. You just need another release package from another source. It would be okay to do that, but you just need a check or a warning and a stop of the upgrade process from koha-common if you not have a mariadb version that can handle this emojis in its index.
Comment 9 Jonathan Druart 2018-10-31 15:40:03 UTC
(In reply to Michael Oehrlich from comment #4)
> Created attachment 78330 [details]
> Alter Table not working

On this screenshot: "Index column size too large. The maximum column size is 767 bytes. at /usr/share/perl5/DBIx/RunSQL.pm line 273."

(To help searching this issue)
Comment 10 Martin Renvoize 2018-11-09 10:38:09 UTC
I can confirm this is also the case with 10.1.26

martin@mr-dev$ sudo apt-cache show mariadb-common
Package: mariadb-common
Source: mariadb-10.1
Version: 10.1.26-0+deb9u1
Installed-Size: 70
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Architecture: all
Depends: mysql-common (>= 5.6.25)
Description-en: MariaDB common metapackage
 MariaDB is a fast, stable and true multi-user, multi-threaded SQL database
 server. SQL (Structured Query Language) is the most popular database query
 language in the world. The main goals of MariaDB are speed, robustness and
 ease of use.
Description-md5: a8bf2c1aebcb16934e54a7cb04adbfb4
Multi-Arch: foreign
Homepage: https://mariadb.org/
Tag: protocol::db:mysql, role::app-data, role::metapackage, works-with::db
Section: database
Priority: optional
Filename: pool/main/m/mariadb-10.1/mariadb-common_10.1.26-0+deb9u1_all.deb
Size: 27258
MD5sum: 0e84745e82042355606e8f0e3a2f3fba
SHA256: 284fd5170a4c84651f54f15211ac209022473e38ce978f77b9e1e2518d276154
Comment 11 Martin Renvoize 2018-11-09 11:03:01 UTC
A complete drop and restors of the database from a backup worked for me.. no package update required.. I tihnk it may be to do with some file permissions getting mis-set during mariadb server upgrade?
Comment 12 Michael Oehrlich 2018-11-09 11:05:23 UTC
(In reply to Martin Renvoize from comment #11)
> A complete drop and restors of the database from a backup worked for me.. no
> package update required.. I tihnk it may be to do with some file permissions
> getting mis-set during mariadb server upgrade?

No did not work for us. Only an instance up to 10.2 from MariaDB did work.
Comment 13 Owen Leonard 2019-02-22 14:59:55 UTC
It sounds like this was more of a support issue and has been resolved.