(Solved) Upgrade to 6.0.0 - command for extracting openemr-6.0.0 from installation instructions fails on EC2 Ubuntu instance

Situation
I am trying to follow the instructions here to get the tar.gz file:
https://www.open-emr.org/wiki/index.php/OpenEMR_6.0.0_Linux_Installation#Required_Software_Installation_.28distribution_specific.29

$ curl https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.tar.gz --output openemr-6.0.0.tar.gz
$ tar -pxvzf openemr-6.0.0.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

$ file openemr-6.0.0.tar.gz 
openemr-6.0.0.tar.gz: HTML document, ASCII text

Apparently it isn’t gzipped at all?
–RBL

There is another distribution file in the .zip format. I also tried to extract it instead. When I did so, I got the following error:

~/openemr-6.0.0$ curl https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.zip --output openemr-6.0.0.zip
~/openemr-6.0.0$ unzip openemr-6.0.0.zip 
Archive:  openemr-6.0.0.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of openemr-6.0.0.zip or
        openemr-6.0.0.zip.zip, and cannot find openemr-6.0.0.zip.ZIP, period.

I looked at the .zip distribution and found the following:

<html>
 <head>
  <title>301 Moved Permanently</title>
 </head>
 <body>
  <h1>301 Moved Permanently</h1>
  The resource has been moved to <a href="https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.zip/">https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.zip/</a>;
you should be redirected automatically.


 </body>
</html>

Then I retried looking at the new location:

https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.zip/">https://sourceforge.net/projects/openemr/files/OpenEMR%20Current/6.0.0/openemr-6.0.0.zip/

I finally just used a web browser to download the file and that worked. Evidently, you can’t use curl the way that I used it.

Now I’m continuing with the instructions here for the actual upgrade from 5.0.2p5 to 6.0.0p1
https://www.open-emr.org/wiki/index.php/Linux_Upgrade_5.0.2_to_6.0.0

–RBL

OpenEMR Version
I’m using OpenEMR version 6.0.0

Operating System
I’m using: Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-1128-aws x86_64)

@brady.miller So the wiki needs to be updated with the new url, if that is the problem.

1 Like

hi @benmarte, what url?

if you use wget, just have to rename download to openemr-6.0.0.tar.gz

1 Like

Based on what @Ralf_Lukner posted it sounded like sourceforge did a 301 redirect but apparently. After checking now on a computer the link works just fine so disregard my comment.

2 Likes

I think the problem was that I did not use wget (I used curl), which created this bizarre download.
Do you know of a script or a way that I can upgrade only my database from 5.0.2p5 to 6.0.0? I have everything else upgraded on my test system (openemr directory, restored documents).
–RBL

Why is this a concern Ralf? OpenEMR will only upgrade what it needs…

Note: Upgrade uses the sql macro script in openemr/sql. For v6 in your case is 5_0_2-to-6_0_0_upgrade.sql

1 Like

When I tried to run the sql_upgrade.php script, it told me to check if mysqld was running. That made me concerned that the sql_upgrade.php script and the scripts it calls were not aware that the AWS STANDARD implementation has the MySQL server on another instance (“workstation”) … there shouldn’t be a mysql server running locally on the docker in this case.

openemr calls the upgrade script DB access the same way as normal DB access for login say.
If using a RDS on AWS this should be seamless to our App if setup correctly.

So if upgrade doesn’t work, neither will openemr.

The sql_upgrade.php file does not work and at this point, and, of course, openemr doesn’t either … I suspect because the database is not ready and maybe other things are undone.

I wonder if it is failing for similar reasons that docker up failed for me (webserver would not respond at all) or if there are different issues at play.

I guess I will need to go through the sql_upgrade.php file manually and do all the things it would have done at a command line.

I see the OpenEMR preinstallation screen when I go to the web server.

Pre Install - Checking File and Directory Permissions

Welcome to OpenEMR. This utility will step you through the installation and configuration of OpenEMR for your practice.

  • Before proceeding, be sure that you have a properly installed and configured MySQL server available, and a PHP configured webserver.
  • Detailed installation instructions can be found in the ‘INSTALL’ manual file.
  • If you are upgrading from a previous version, DO NOT use this script. Please read the ‘Upgrading’ section found in the ‘INSTALL’ manual file.

We will now ensure correct file and directory permissions before starting installation:

Ensuring following file is world-writable…

/var/www/localhost/htdocs/openemr/sites/default/sqlconf.php file is ready

Ensuring the /var/www/localhost/htdocs/openemr/sites/default/documents directory and its subdirectories have proper permissions…

/var/www/localhost/htdocs/openemr/sites/default/documents directory and its subdirectories are ready.

All required files and directories have been verified.

Click Proceed to Step 1 to continue with a new installation.

CAUTION: If you are upgrading from a previous version, DO NOT use this script. Please read the ‘Upgrading’ section found in the ‘INSTALL’ manual file.

I have been trying to get an upgrade from OpenEMR Cloud (AWS) STANDARD 5.0.2p5 -> 6.0.0 to work for months now. So far, no luck in demonstrating a successful upgrade with a test replica of my system.

–RBL

Looks like you are installing a new OpenEMR instance instead of upgrade.

This may mean your installed flag is not set for some reason due to how you tried to create the test instance.
If you have copied your production site directory to your new instance then you shouldn’t get screen you’re getting.

Check the sites/default/sqlconf.php and ensure the config is set

//////DO NOT TOUCH THIS///
$config = 1; /////////////
//////////////////////////
1 Like

You are correct. I tried copying the files again, and forgot to make that change. I also needed to change localhost to the rds instance endpoint.

Once I corrected that, the upgrade started to work … holding my breath now … 10% complete and still running …

… 100% complete
DONE upgrading access controls
Updating version indicators…

Database and Access Control upgrade finished. Wow. IT WORKED!!

–RBL

Okay, just don’t get discouraged if upgrade is taking a lot of time. It depends on your DB size and the quality of the machine you are running on.

It worked!! It was fast (I put a lot of effort and $$ into optimizing performance of the database and EC2 instance)! Now I have an upgraded test system. Now I’m going to upgrade the production server.
–RBL

1 Like

Glad to hear upgrade went well. Wish you luck…

One more thing … when I try to upgrade my production sever, I’m running out of space when I try to copy my documents onto the docker volume. The test system did not have this problem. I tried deleting the error logs to free up room. Still failing. I read somewhere that this can sometimes be a permissions issue. Anyway, I’m trying to figure out to how make space (I have plenty of disk space but my docker space is apparently full? 43G?)

ubuntu@ip-10-0-2-213:~$ sudo docker cp documents/ standard_openemr_1:/var/www/localhost/htdocs/openemr/sites/default/documents/
Error response from daemon: Error processing tar file(exit status 1): Error setting up pivot dir: mkdir /mnt/docker/aufs/mnt/3dccbf1bdee1332497bb348ba67b7a73b5c3209df4b406386b4b46xxxxxxxx/var/www/localhost/htdocs/openemr/sites/default/documents/.pivot_root075757591: no space left on device
ubuntu@ip-10-0-2-213:~$ df -lH
Filesystem      Size  Used Avail Use% Mounted on
udev            4.2G     0  4.2G   0% /dev
tmpfs           837M  9.4M  827M   2% /run
/dev/xvda1      209G   20G  189G  10% /
tmpfs           4.2G  1.1M  4.2G   1% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           4.2G     0  4.2G   0% /sys/fs/cgroup
/dev/loop2       59M   59M     0 100% /snap/core18/2066
/dev/loop1       34M   34M     0 100% /snap/snapd/11841
/dev/loop0       35M   35M     0 100% /snap/amazon-ssm-agent/3552
/dev/loop4       34M   34M     0 100% /snap/amazon-ssm-agent/2996
/dev/loop3       59M   59M     0 100% /snap/core18/1997
/dev/loop5       34M   34M     0 100% /snap/snapd/11588
/dev/xvdd        43G   43G     0 100% /mnt/docker
tmpfs           837M     0  837M   0% /run/user/1000

For some reason the upgrade keeps hanging … I suspect that the aws timeouts are coming into play here. I suspect that I will need to change some of the aws timeout parameters to longer values in order for the production database upgrade to succeed. Alas, I need to call it a night here at 3:00am CST. I’ll restore the v502p5 production system from snapshots for now and try again on a different night.
–RBL

after you increase the size of the volumes you have to extend the filesystems

I’m able to increase the size of the volumes and extend the filesystems. I have read the conceptual process of increasing a docker volume (backing it up, deleting it, and re-creating it with a bigger size option). I do not have the confidence to do this on a production system yet. I may play around with a docker volume on a test replica of a production system, however.

$ sudo docker info
Containers: 2
Running: 1
Paused: 0
Stopped: 1
Images: 5
Server Version: 17.05.0-ce
Storage Driver: aufs
Root Dir: /mnt/docker/aufs
Backing Filesystem: extfs
Dirs: 33
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.15.0-1099-aws
Operating System: Ubuntu 16.04.7 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.788GiB
Name: ip-10-0-2-70
ID: xxxxxxxxxxxx:AXM6:4HVX:7OQT:2Xxxxxxxxxxxx
Docker Root Dir: /mnt/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support

$ df -lH
Filesystem Size Used Avail Use% Mounted on
udev 4.2G 0 4.2G 0% /dev
tmpfs 837M 9.3M 828M 2% /run
/dev/xvda1 209G 13G 196G 6% /
tmpfs 4.2G 418k 4.2G 1% /dev/shm
tmpfs 5.3M 0 5.3M 0% /run/lock
tmpfs 4.2G 0 4.2G 0% /sys/fs/cgroup
/dev/loop5 34M 34M 0 100% /snap/snapd/11841
/dev/loop4 59M 59M 0 100% /snap/core18/1997
/dev/loop3 34M 34M 0 100% /snap/amazon-ssm-agent/2996
/dev/loop0 59M 59M 0 100% /snap/core18/2066
/dev/loop1 35M 35M 0 100% /snap/amazon-ssm-agent/3552
/dev/xvdd 43G 38G 2.8G 94% /mnt/docker

–RBL

I do not have the technical knowledge and experience to backup, delete, and restore the OpenEMR docker with a larger size. Thus, what I am doing is something that does work for me … create a duplicate system of my AWS OpenEMR Cloud 5.0.2p5 STANDARD system and then upgrading that. For some reason, when I run a cloudformation stack, it creates a docker that does not run out of space as my existing EC2/docker does.