1 Topic by redcar

  • redcar
  • Member
  • Offline
  • Registered: 2018-09-03
  • Posts: 7

Topic: roundcube Oops... something went wrong!

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release):  1.8.0 MARIADB edition.
- Deployed with iRedMail Easy or the downloadable installer? downloadable installer
- Linux/BSD distribution name and version: Rocky 8.10
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): mariadb
- Web server (Apache or Nginx):Nginx
- Manage mail accounts with iRedAdmin-Pro?No
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====
I have made mistakes while upgrading iredmail to 1.8.0
Everything seems OK now, except accessing roundcube gives to message: Oops... something went wrong!

My initial mistake was that I missed the instruction to upgrade php from v8.0 to v8.2, and I tried v8.5 (which is not compatible).  After I got that sorted out (installed php v8.2), I don't see any relevant error message in any log, but the problem continues.

If I replace the roundcube index.php with a test .php file, that is served correctly, so nginx and php-fpm are working, and mariadb is running.

Can you give some hints as to where to look, or how to enable more logging?

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by redcar (edited by redcar Yesterday 16:06:39)

  • redcar
  • Member
  • Offline
  • Registered: 2018-09-03
  • Posts: 7

Re: roundcube Oops... something went wrong!

I managed to fix it myself.
As the index.php script appeared to run, but there was no debug output to any log, I configured xdebug (which I don't like doing on a live server), and found that in the initial database sanity check was the error: Unknown column 'expires_at' which led me to: https://github.com/roundcube/roundcubemail/issues/10178

Checking the database system table I found that the version number was 2020020101, but I am sure that I updated it since then (maybe a year ago), so it looks like that update did not complete properly, leading to the latest update failing.

I re-ran all the mysql updates after 2020020101, a couple of them generated error about changes already applied (confirming that the database had already been partially updated), but after that everything seems to be working again.