Skip to main content

MagicINFO upgrade failed: database check, service or blank page

A failed MagicINFO Server upgrade almost always tells you why in two text files in the install folder. Read those first, match what they say to the cases below, and do not run the installer again until you know which case you have. The one we have seen ourselves is a wrong database user name; the others are reported by other administrators and are given here as outlines.

Where to look first​

WhatWhere
Pre-flight resultsC:\MagicInfo Premium\verification.txt
Installer logC:\MagicInfo Premium\MyInstallLog_<version>.txt
Application log after startC:\MagicInfo Premium\runtime\logs\wsrm.log
Tomcat logs after startC:\MagicInfo Premium\tomcat\logs\

On the build we upgraded from, verification.txt listed these checks in order: Service Status Check, Tomcat Version Check, File / Directory Writable Check, Registry Check, Database Check, Database Validation, Database Firmware Check, and a final Total Result. Find the first line marked [FAIL]; everything after it is a consequence.

Before anything else, confirm what is running. Open http://localhost:7001/MagicInfo/openapi/auth?cmd=isMagicInfo (or the HTTPS form on your port). A short number such as 211070.0 means the old build is still answering; an error or timeout means the service is down.

Failure 1: [FAIL] DB Connect Check and exit code 1 (seen first-hand)​

We ran the 21.1091.1 installer over a 21.1070 server. It stopped the MagicINFO service, passed the service, Tomcat, file and registry checks, and then failed at the database step. The two files showed:

verification.txt
  28P01: password authentication failed for user "postgre"
  [FAIL] DB Connect Check
  ...
  DB Connection Failed.            (Database Validation and Database Firmware Check)
  ...
  Total Result
  [FAIL]

MyInstallLog_21.1091.1.txt
  InstallVerification Exit Code = 1

28P01 is PostgreSQL rejecting a user name or password. Here the installer was connecting as postgre, a mistyped user name, instead of the real role.

  1. Open Services and check that MagicInfoPremium ("MagicInfo-i Premium Edition Server") is running. The installer stopped it before the checks; start it if it is not.
  2. Confirm the old build answers isMagicInfo. In our case nothing had been changed and it still returned 211070.0.
  3. Test the same user name and password you gave the installer with pgAdmin or psql. If that login fails, you have found the problem.
  4. Correct the user name or password and run the installer again.

We have not carried out the retry ourselves, so treat "correct and rerun" as the diagnosis, not a proven result. The pre-upgrade list is in Before you upgrade.

Failure 2: "Database Update Failed. Please Check Your Database." (reported)​

Reported on older upgrades, during the schema update rather than at the connection check. The usual explanations are a database that has drifted from the layout the installer expects (an object already present or missing), or a change the new build applies that older rows do not satisfy. One report concerns an hourly statistics table when going from 21.1000.3 to 21.1010.2.

Restore your backup so the server is whole again. Then look for a later build that goes straight to your target, and find the exact failing statement in the install log before you ask your supplier or Samsung about it. We do not give SQL fixes for this: editing a production schema by hand is how a failed upgrade becomes a damaged database.

Failure 3: no MagicINFO service after a version 8 to 9 upgrade (reported)​

Version 9 moves to Tomcat 9 and the installer is meant to replace the old Tomcat folder. In reported failed runs the new Tomcat landed in a differently named folder and only an update service was installed. In outline: make the Tomcat 9 folder the one named tomcat, install the service from its bin folder in an administrator prompt, bring back your connector settings, then start the service. Check Get-Service for the service name before and after.

Failure 4: the web console never finishes loading (reported)​

If tomcat\conf\server.xml still names the old native connector, org.apache.coyote.http11.Http11AprProtocol, the new Tomcat cannot load it and the page hangs. Change the protocol on the connector to org.apache.coyote.http11.Http11Nio2Protocol, which is what a 21.1070 install uses, and restart the service. Allow five to seven minutes before judging the result.

Failure 5: "permission denied" on tables after manual database work​

This follows hand-made database changes: objects created as the postgres superuser while MagicINFO connects as its own role. Create or restore objects as the application role instead. Our guide to backup and restore covers doing that correctly.

How to confirm it worked​

  1. isMagicInfo returns the build you meant to install.
  2. MagicInfoPremium is running and runtime\logs\wsrm.log shows no new errors after start.
  3. You can sign in, content and thumbnails appear, and screens return to connected.
  4. Your hand-made changes (connector settings, certificates) are still in place.
warning

Always take a database backup and copy conf, runtime and tomcat before any upgrade. Every outline above ends with "restore", and that only works if the backup exists.

Checked against MagicINFO Server 21.1070 on Windows, October 2026. Failure 1 is first-hand; failures 2 to 5 are reported by other administrators.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on