Migrating 6.4 to 7.1 fails on Linux using the Default Setup (HSQL to H2)

Jonathan Leaders February 23, 2016

The error message says to start JIRA 7.1 but does not state how to do this.


I had a working JIRA 6.4 setup (relatively simple) on 64-bit linux using the default HSQL in memory database because I had no additional need to change it to MySQL. I bought the new JIRA Software product I ran the installer in Upgrade mode while still in HSQL.

The upgrade completed. I am now succesfully. at 7.1, but unfortunately I get a cryptic error every time I try to load my JIRA.

 

Failed to start due to problems with your database configuration. HSQL is no longer supported.

In order to migrate your HSQL database to supported H2 database, please run JIRA 7.0 which will trigger migration procedure.

 

So, being a smart person, I figure this means I need to start the new JIRA service. I run

sudo /etc/init.d/jira stop

sudo /etc/init.d/jira start

Expecting this to run JIRA 7.1 and migrate my database. No luck, I still get this error.

 

The error says I need to run JIRA 7.1.... how do I do that besides just starting the JIRA service?

 

image2016-2-23 9:47:25.png

2 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

1 vote
Jan Stian Gabrielli March 11, 2016

I have been using the Binary linux installer version. Should have read the upgrade notes, but it was a test/poc env so I figured I'd just go for it.

I went :
6.4.1 -> 7.1.1 (Failed with: HSQL is no longer supported. please run JIRA 7.0)
-Unziped the backup that the installer made to /opt/atlassian/jira again

Then upgraded:

6.4.1 -> 7.0.0
-(Appended proxy and contextpath from the old 6.4.1 server.xml file in to the new -server.xml file as some listener names had changed in the jira config ).
7.0.0 -> 7.1.1
-Copied back the server.xml file from the 7.0.0 installation to preserve context path etc.

Everything is now OK.

0 votes
Boris Georgiev _Appfire_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 24, 2016

If you're planning to move to another database anyway - why don't you roll back the upgrade, then migrate to the other database using the XML backup of JIRA and then run the upgrade again ?

Boris Georgiev _Appfire_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 24, 2016

There's also a bug that looks similar to your problem - you may try the workarounds proposed there https://jira.atlassian.com/browse/JRA-59484

 

Jonathan Leaders February 24, 2016

How does one "roll back" the upgrade on Linux? Is there an uninstaller script? Typically in debian linux you would to `apt-get install jira=6.4` and it would be done in one command.
but it's not clear why Atlassian doesn't use package management.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 24, 2016

Atlassian doesn't use package management because the products are cross-platform.  The tar.gz non-packaged distribution works on everything that's Unix or BSD based and conforms to the minimum environmental requirements (hardware and an OS that supports the right version of java).  Much as proper packages have benefits around stability, dependency and upgrade, they completely fail any test of portability and standardisation.  If there's one thing I'd fix about Unix and BSD based systems, it's a single, working way to deliver software (without dependency hell, while we're talking about it)

There is no "downgrade" or "rollback" code because it's messy, hard to maintain, and pretty pointless, as a backup is something you should always do before a major system upgrade.  I'm not talking about the software here - that could easily be done with a packaging system.  The issue is actually your data - an upgrade often changes the shape of the data, and it's a massive effort to write "reverse all data changes", even assuming you have built in (a useless and exponentially complex) system that allows you to reverse data changes that destroy data.

Jonathan Leaders February 25, 2016

Fair enough. I did find the uninstaller here: https://confluence.atlassian.com/jira/uninstalling-jira-from-linux-240910484.html

I will go ahead and uninstall, and import from a backup


Frankly it is shocking the default install of JIRA 6.4 (HSQL) is not supported in the default upgrade path to JIRA 7.0. It sounds like that would be required for even pre-release Alpha of 7.0


Jonathan Leaders February 29, 2016

Also it is very difficult to download version 6.4, which makes this even more of a headache.

Jonathan Leaders February 29, 2016

Also apparently they decided not to document the default database on the migration hub... why was this released so early??
https://confluence.atlassian.com/migration/search?q=hsql&max=10

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 29, 2016

I think it's understandable.  Not ideal, but understandable.

First of all, you shouldn't be using hsql in any system that matters, so there's little need to provide an upgrade path to h2 (which is better than hsql, but still not really a production class database). 

When you're serious about testing  and then performing an upgrade, you should be doing it all with production-like databases (or database independent methods).  Hsql based (Atlassian) systems can legitimately considered to be "throwaway". So there's little incentive to code an upgrade path.

I'm sort of with you on the difficult to download.  I don't agree that it's a hard download - choose one from https://www.atlassian.com/software/jira/download-archives and click on it.  But finding that page when you are wandering around Atlassian's site is where I agree totally.  It used to be that you could say "download JIRA", it would offer up "latest" and link directly to the archives.  Now it seems to be a lot more clicks.  (And it doesn't have versions earlier than 4, which is a pain for those of us getting "we've got this old old JIRA and would like an upgrade" work)

Jonathan Leaders February 29, 2016

If they don't want to provide an upgrade path for the default database, then they should throw an error if you run the upgrader. Instead, it runs the upgrade, essentially corrupting your JIRA install, causing you to spend hours uninstalling, looking up support, downloading old JIRA installation, reinstalling, importing the backup, on and on. Is it that hard to just have one "IF" statement in the JIRA upgrader and make it fail saying "HSQL databases are not supported" for migration?

Also no mention of 6.4 on the migration help page.


https://confluence.atlassian.com/migration/search?q=6.4&max=10

Jonathan Leaders February 29, 2016

I understand HSQL is not production class. But I use JIRA sometimes in environments that I want to set up quickly. HSQL is the default install, it is the FASTEST to set up, and quite honestly, it's "good enough" to use for small projects.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 29, 2016

That would be nice, yes smile  - at least try to prevent the waste of time.

I might try it for myself soon, just to see what happens (I've got an hsql 6.4.11 here on Linux, be nice to see how much of a mess it makes)

Jonathan Leaders February 29, 2016

I've filed this as a bug, so update it if you see the issue as well.

https://jira.atlassian.com/browse/JSW-13292

Jonathan Leaders March 1, 2016

I tried installing 7.0 instead of 7.1, and it got a different error, and showed an expired license, but there was no way for me to enter the license. It tried asking, but it had no "Apply" button... then totally failed with an 'unknown' error, asking to check logs. Logs again showed an expired license, but there was no way for me to enter the license after that point. ( I do have a valid license key I purchased for 7.0 )

Jonathan Leaders March 2, 2016

I obliterated everything and tried to import the backup into a totally fresh 7.1 and it fails too
JIRA 7.1 fails to import data from JIRA 6.4 with "org.xml.sax.SAXException"

At this point I quit. Screw 7.1


I've spent over a week hitting a minefield trying to upgrade to this totally Alpha-quality release. I don't know who tested this or managed this release but it's a total mess. I've hit no less than 5 separate mission-critical failures, each with cryptic errors, no documentation, and no workarounds. And I don't count totally uninstalling everything as a workaround.

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 3, 2016

Ok, that's really odd.  I've just done 6.4.11 to 7.1 on an HSQL/H2 install on a Ubuntu-like box (Sparky to be specific) and it sailed straight through.  VERY small amount of data and no add-ons, or integrations with other systems, but it worked fine.  I'm not sure it's worth spending a week on a non-production system though.

Jonathan Leaders March 3, 2016

Huh, I wonder why I had a different experience. Did you install 7.0 before 7.1?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 3, 2016

Nope, it was a single jump.  But it was 6.4.11 -> xml, then import.  Not an in-place upgrade.

Jonathan Leaders March 7, 2016

When you exported it as XML, then did you somehow delete the existing data, clean it out, or otherwise unload the data? I did do an XML backup, as you did, just in case it fails, but then I did an in-place upgrade. It never got to the point of asking me for an import of data.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 11, 2016

Nope, flat out import, nothing more.

steve moffat May 6, 2016

Hi. I hope someone is still watching this thread.

I am going in circles and could use some guidance.

I have a JIRA installation at v6.4.5, without the Agile components, and am trying to upgrade to the latest 7.1 (currently .4, but I now see .6 is available).  We have a 500 user license with about 350 users defined, and just over 100 projects.

To test the upgrade, on a separate Linux x64, I did the following

  1. installed v6.4.5 (hsql database)
  2. imported an xml backup of our data
  3. ran the 7.1.4 installer, which told me to use 7.0 because that would fix/upgrade the in-memory database.
  4. Started over, this time installing 6.4.5, and going to 7.0.10
  5. ran the 7.0.10 installer, which failed saying there were Agile records that needed to be updated, and to use an earlier installer (6.7 I think.. I'll start again to be sure, I lost the message)

I saw the warnings about using the in-memory database.  Next week I will try to get a better database installed, but I don't think the db is the issue at step 5 above.

What would be the right order of incremental migrations to get from 6.4.5 (no-Agile), to 7.1.6 JIRA Software?

TAGS
AUG Leaders

Atlassian Community Events