Could someone suggest any idea on why my OpenEMR loging screen is blank? I installed OpenEMR 6.0 with new emtpy database and it works fine. Then I proceeded to test upgrading my 4.2.2 database to 6.0. After database upgrade is successful, my login screen is blank.
Thank you,
Hi @Kanoberson ,
There are dozen things that can go off the rails when upgrading from 4.2.2. There are a lot of questions I have about the upgrade path that you took.
Did you install v6 on a new server first, then brought in v4 db by doing a mysql openemr < my4.2.2.sql?
Or did you manually create the 4.2.2 DB and then pointed the code at the database for upgrade?
There are small differences I have found on how to get from 4.2.2 up to v6 that can make all the difference on the final result.
More details is what is needed to help troubleshoot the issue. It is not straight forward.
If I am correct, you did the following:
There are encryption keys in the sites/default/documents/log_and_misc/methods called sixa and sixb.
You want to remove theses keys and let the system generate new ones with your upgraded database.
Just delete these keys and try logging into OpenEMR. These keys are regenerated when they don’t exist. Please let me know if this helps.
it’s best to bring in the keys from a back up of the documents which you’ll want to do anyways on an upgrade unless you have none
seeing how this was a 4.2 version there wouldn’t be any keys since they were added in version 5.0.2
since you took 6.0 for a test drive before upgrading what @growlingflea states makes sense
@stephenwaite Just to confirm.
Lets say that we are migrating a customer’s instance of OpenEMR from one host (5.0.2) (i.e. Host 1) to a brand new host (host 2) where we plan on upgrading to 7.0.0, we should bring the keys from the 5.0.2 in the sites directory into the GCP instance sites directory.
What happens if we generate new keys on the new instance after upgrading the DB? Are we locked out of the documents?
For an OpenEMR instance would consider the database and filesystem (documents directory) to be interlocked (they should always travel together on upgrades and host transfers). If are ever in a situation where need to remove keys then would argue the mistake should be remedied rather than removing keys. At this point those keys on the filesystem will always encrypt passwords in globals (not a huge loss if lose these) and will sometime encrypt the entire log if this option is turned on (would be a huge irretrievable loss if remove the keys).
Check out this post for description on keys (there is a set in database and a set on the filesystem):
