Upgrade from v5.0.2 to v7.0.0 failed

The upgrade fails with this error messages

   OpenEMR Error : Decryption failed authentication.
   OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting.

PHP 8.1.2-1
ubuntu 2.11

Here were the steps taken to get here.

  1. Created new server to move to.

  2. Install dependencies from the dependencies page

  3. Followed the instructions to upgrade from the upgrade page

  4. Backup database from v5 and imported into a new empty database created on the new server and copied key set sixa and sixb to new server before next step

  5. Ran the upgrade script. No problems. Upgrade script completed with no errors.

Attempted to access the login page. A blank screen shows. Tried accessing the login screen from two more different browsers, blank. Keeps repeating the same error message.

According to @brady.miller , keys should never be deleted and keys should follow the database.

If I delete the keys, then the login username and password do not work.

I have tried upgrading from v5 - v6. That does not work. There is an internal error displayed.

There are no modifications to the v5 database.

My question. Is there a routine that upgrades the key set between versions?

As a test I decided to upgrade a different server of mine with version 7.0.0 (2) to 7.0.1.
I move the current version to oemr-old, copied the contents of the old
oemr/sites/default/documents/* folder into oemr/sites/default/documents/

Tried to run the upgrade script and I get

 [Sat Apr 29 21:22:18.561369 2023] [php:notice] [pid 76103] [client] OpenEMR Error : Decryption failed authentication.
 [Sat Apr 29 21:22:18.561413 2023] [php:notice] [pid 76103] [client] OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting

I reverse the folders and put the system back and everything works fine.
I guess, I will have to setup xdebug to see where this is breaking at.

hi @juggernautsei , are you using cp -r for a recursive copy?

Yes, I am otherwise the error message shows that says skipping directory.

If asking users to reset their passwords is an option, after upgrade reset admin to ‘pass’ and reset passwords for self and other active users.

ok, what are the permissions on the key since it can only get to the

OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting

if the key is empty.

The key is not empty. The permission is 644. Owner www-data.
I went back to the previous install that did not work. It was not due to a key issue. It was a module failure. I removed the failing module and everything worked fine. I am going back to the v5 and copy over the entire documents folder this time.

1 Like

I let some time pass before trying this again. I am still having the same issue upgrading from version v5 on ubuntu to v7.0.1 on ubuntu.

I still get the same error.

 [Mon May 08 20:52:06.639111 2023] [php:notice] [pid 125577] [client] OpenEMR Error : Decryption failed authentication.
 [Mon May 08 20:52:06.639325 2023] [php:notice] [pid 125577] [client] OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting.

I will pull the database down to a local machine so I can troubleshoot it better.
I can get into it by resetting the password. But the calendar does not show. I ran the SQL patch but that did not solve the calendar issue.

I need help understanding what I am looking at. I dumped out the key. The Collect key keysource is database. In the trap, I get this output below.

 [Tue May 09 08:53:09.815296 2023] [php:notice] [pid 169856:tid 1872] [client ::1:50619] OpenEMR : Key retrieved from database\xb5\xcc\xa28\x13|BEB\xaa\xbb\xee\xd2#\x89W]^\xfc7yS\x10\xc2-;\x8f^\bi\xa0\xea

The line above is from

I dumped the key again after line 470

   This is the encryption version: 6
   1. OpenEMR : Key retrieved from database \t\xc5\x7f\\\xaaj\xde \xd2hp\x1e\xae\t\xce\xc6\xa1\xf9\xeco,iA\xcdb\xa4\xdf@h\xf3\x92\xdb
   2. Decrypt key: \t\xc5\x7f\\\xaaj\xde \xd2hp\x1e\xae\t\xce\xc6\xa1\xf9\xeco,iA\xcdb\xa4\xdf@h\xf3\x92\xdb
   1. OpenEMR : Key retrieved from database \xb5\xcc\xa28\x13|BEB\xaa\xbb\xee\xd2#\x89W]^\xfc7yS\x10\xc2-;\x8f^\bi\xa0\xea
   2. Decrypt key: \xb5\xcc\xa28\x13|BEB\xaa\xbb\xee\xd2#\x89W]^\xfc7yS\x10\xc2-;\x8f^\bi\xa0\xea
    OpenEMR Error : Decryption failed authentication.
    2. Decrypt key: 
    3. Is the key empty

@stephenwaite The key is empty.

So, I went back to the version 5 original database and looked for the keys table. There is no keys table in version 5.0.2 (5) that I am working with. Because the keys table was not created. There is no key.

My guess is that the system is doing what it is supposed to do and creates a key when the key table is empty. It creates a new key and calls that key. Now when that new key is called. It does not match the version 5 keys from the methods folder.

Now I have gone back to version 5.0.2 (5) and added the keys table. The keys table is now populated with a key. I will run the upgrade again to see what happens.

that’s odd @juggernautsei since the upgrade script from 501 to 502 should have created that table

Yes, very odd but that should fix the issue. I got a chance to use new tools for me and some old ones as well. Never assume all the tables are where they are supposed to be even though those tables should have been created. Verify all data sources. I started tracking backward just to make sure that a key was existing in the previous database before the upgrade. Because after the upgrade the table exits. I had no proof it existed before the upgrade. Turned out to be something basic and simple to fix. I want to wait until the end of the day to make a current copy of the database and run the upgrade script on it.

This rabbit hole keeps getting deeper. Version 5 is not producing the database key. I created the table. The system has not populated the table with a key entry. Now I need to figure out why.

maybe it was a 5.0.2-dev version? (in that case would try to sql-upgrade from 5.0.1 instead of 5.0.2)

@brady.miller I am not sure where you are talking about running sql_upgrade from. When I am doing the upgrade from v5. I aways start two version back from where I think the database is. So, in this case the database should be 5.0.2 (5). I started the upgrade at 5.0.0.

But the issue is that the original 5.0.2 (5) code is not creating a key in the database. The mechanism for inserting the key into the table has been the same since v5.0.2. I put in a trap just before the insert statement and the code is not hitting the trap.

This has been an exercise in paying attention.
This is an old multi-site. I was grabbing the wrong database.

All is well now. Good exercise in the encryption process.