This document describes the standard, recommended procedure for upgrading to JIRA 5.0.x on Linux or Windows. Use this procedure if:
Otherwise:
|
Please read/perform all steps and sub-steps in consecutive order.
1. Before You Start
- You will need current software maintenance to perform the upgrade. If you are unsure, confirm the following:
- Your license support period is still valid.
- If your current license has expired but you have a new license with you, please update your license in JIRA.
If you forget to do this and your license has expired, you will receive errors during the upgrade process. Refer to the instructions on upgrading beyond current license period.
- Read the release notes and upgrade guide for the version of JIRA you are upgrading to. The upgrade guide (in particular) contains important information that may be relevant to your JIRA installation.
- If you plan to skip a few JIRA versions for your next JIRA upgrade, we strongly recommend that you read the upgrade guides for all major versions between your current version and the version to which you are upgrading. Refer to Important Version-Specific Upgrade Notes for quick links to these guides.
- Confirm that your operating system, database, other applicable platforms and hardware still comply with the requirements for JIRA 5.0.x. Newer versions of JIRA may have different requirements and supported platforms to previous JIRA versions.
The End of Support Announcements for JIRA page also has important information regarding platform support for future versions of JIRA. - Some anti-virus or other Internet security tools may interfere with the JIRA upgrade process and prevent the process from completing successfully. If you experience or anticipate experiencing such an issue with your anti-virus/Internet security tool, disable this tool first before proceeding with the JIRA upgrade.
- Check for any known issues in the JIRA Knowledge Base.
- If you have installed any additional JIRA plugins (i.e. not included with JIRA), please verify that they will be compatible with the version of JIRA you are upgrading to. You can find a plugin's compatibility information from the the plugin's home page on the Atlassian Plugin Exchange. Once you have confirmed the availability of compatible versions, you should upgrade your plugins after successfully upgrading JIRA. This can be done via the 'Plugin Repository' in your Administration Console.
- Test first!— We strongly recommend performing your upgrade in a test environment first. Do not upgrade your production JIRA server until you are satisfied that your test environment upgrade has been successful.
- If you have any problems with your test environment upgrade which you cannot resolve, create an issue at our support site so that we can assist you.
- If you have any problems during the upgrade of your production JIRA server, do not allow your users to start using this server. Instead:
- Continue to use your old JIRA server — this will help ensure that you do not lose production data.
- Also create an issue at our support site so that we can help you resolve the problems with production JIRA upgrade.
2. Upgrade Overview
The upgrade feature of the Linux and Windows Installers, automates the following tasks for you:
- Backs up the Installation and Home Directories of the existing JIRA installation to be upgraded.
- Installs JIRA 5.0.x whilst migrating the following from your existing JIRA installation to the new JIRA 5.0.xinstallation:
- Legacy database configurations defined as a datasource within the application server (used in JIRA 4.3.x and earlier) to the new database configuration used in JIRA 4.4 and later. See JIRA 4.4 Upgrade Notes for details.
- TCP port values in your existing JIRA installation's
server.xmlfile. Be aware that other configurations or customisations in this file are not migrated. - Custom values in your existing JIRA installation's
jira-application.propertiesandsetenv.sh/setenv.batfiles.
Be aware that in the setenv.sh/setenv.batfile, only the following values are migrated:JVM_SUPPORT_RECOMMENDED_ARGSJVM_MINIMUM_MEMORYJVM_MAXIMUM_MEMORYJIRA_MAX_PERM_SIZE
The upgrade feature detects and notifies you of any files (other than jira-application.properties and setenv.sh / setenv.bat) in the atlassian-jira subdirectory of your existing JIRA Installation Directory, which had been deleted, added or modified from a 'default' JIRA installation. This informs you of any customisations you will need to migrate manually over to your upgraded JIRA installation directory.
The upgrade feature also re-uses your existing JIRA Home Directory so that any key data stored in this directory from your previous JIRA installation will be retained after the JIRA upgrade.
Please Note:
- The upgrade process requests that you conduct a backup of your database using your database's backup utilities. If your database does not support online backups, you can stop the upgrade process, shut down JIRA, perform your database backup and then restart the upgrade process to continue on.
- If you have made customisations to your
seraph-config.xmlfile or any other file customisations in your JIRA installation directory which are not handled by the upgrade wizard, these must be migrated manually. - If your attachments and index files are located outside your JIRA Home Directory, then backups of these directories must be performed manually.
3. Performing the Upgrade
Refer to the appropriate upgrade instructions below for your operating system:
Upgrading JIRA on Windows
- Download the JIRA 'Windows Installer' (.exe) file (for the new version of JIRA) from the JIRA Download page.
- Run the '.exe' file to start the upgrade wizard.
If a Windows 7 (or Vista) 'User Account Control' dialog box requests if you want to allow the upgrade wizard to make changes to your computer, specify 'Yes'. If you do not, the installation wizard will have restricted access to your operating system and any subsequent installation options will be limited. - At the 'Upgrading JIRA?' step, choose the 'Upgrade an existing JIRA installation' option.
- In the 'Existing JIRA installation directory' field, specify the JIRA Installation Directory of your JIRA installation to be upgraded.
The upgrade wizard will attempt to find an existing JIRA installation and use its location to pre-populate this field. However, always verify this location, particularly if you have multiple JIRA installations running on the same machine. - During subsequent steps of the upgrade wizard, you will be prompted to specify or do the following options:
- At the 'Back up JIRA directories' step, ensure the 'Back up these directories' option is selected. This creates 'zip' archive file backups of your existing JIRA Installation and JIRA Home Directories in their respective parent directory locations.
Please Note:- Choosing this option is strongly recommended!
- At this point, the upgrade wizard notes any customisations in your existing JIRA Installation Directory which it cannot automatically migrate to your upgraded JIRA installation. If you are informed of any files containing such customisations, please make a note of these files as you will need to manually migrate their customisations (which are not mentioned in the overview above) to your upgraded JIRA installation. One relatively common customisation that the upgrade wizard cannot automatically migrate is an SSL configuration defined in the
conf/server.xmlfile of the JIRA Installation Directory.
- At the 'Upgrade Check List' step, back up your external database and check that any non-bundled plugins will be compatible with your upgraded JIRA version. You may have already conducted the latter (in step 5 of the Before You Start section above).
- Upon clicking 'Next', your existing JIRA installation will be shut down if it is still running. The upgrade wizard will then:
- Back up your existing JIRA installation.
- Delete the contents of the existing JIRA Installation Directory.
- Install the new version of JIRA to the existing JIRA Installation Directory.
- Starts your new (upgraded) JIRA installation.
If you noted any files that contain customisations which must be migrated manually to your upgraded JIRA installation (above), then:- Stop the upgraded JIRA installation.
- Migrate the customisations from these files into the upgraded JIRA Installation Directory.
- Restart the upgraded JIRA installation.
- At the 'Back up JIRA directories' step, ensure the 'Back up these directories' option is selected. This creates 'zip' archive file backups of your existing JIRA Installation and JIRA Home Directories in their respective parent directory locations.
- At the last step of the upgrade wizard, select the option to launch the upgraded JIRA installation in a browser so you can check the upgrade.
Congratulations, you have completed upgrading your JIRA installation on Windows!
Upgrading JIRA on Linux
- Download the appropriate JIRA 'Linux 64-bit / 32-bit Installer' (.bin) file that suits your operating system (for the new version of JIRA) from the JIRA Download page.
- Open a Linux console and change directory (
cd) to the '.bin' file's directory.
If the '.bin' file is not executable after downloading it, make it executable, for example:
chmod a+x atlassian-jira-X.Y.bin
(where X.Y represents your version of JIRA) - Execute the '.bin' file to start the upgrade wizard.
- When prompted to choose between creating a new JIRA installation or upgrading an existing installation, choose the 'Upgrade an existing JIRA installation' option.
- Specify the JIRA Installation Directory of your JIRA installation to be upgraded.
The upgrade wizard will attempt to find an existing JIRA installation and will provide its location as a choice. However, always verify this location, particularly if you have multiple JIRA installations running on the same machine. - During subsequent steps of the upgrade wizard, you will be prompted to specify or do the following options:
- Choose the option to back up JIRA's directories. This creates 'zip' archive file backups of your existing JIRA Installation and JIRA Home Directories in their respective parent directory locations.
Please Note:- Choosing this option is strongly recommended!
- At this point, the upgrade wizard notes any customisations in your existing JIRA Installation Directory which it cannot automatically migrate to your upgraded JIRA installation. If you are informed of any files containing such customisations, please make a note of these files as you will need to manually migrate their customisations (which are not mentioned in the overview above) to your upgraded JIRA installation. One relatively common customisation that the upgrade wizard cannot automatically migrate is an SSL configuration defined in the
conf/server.xmlfile of the JIRA Installation Directory.
- At the 'Upgrade Check List' step, back up your external database and check that any non-bundled plugins will be compatible with your upgraded JIRA version. You may have already conducted the latter (in step 5 of the Before You Start section above).
- Upon proceeding, your existing JIRA installation will be shut down if it is still running. The upgrade wizard will then:
- Back up your existing JIRA installation.
- Delete the contents of the existing JIRA installation directory.
- Install the new version of JIRA to the existing JIRA installation directory.
- Starts your new (upgraded) JIRA installation.
If you noted any files that contain customisations which must be migrated manually to your upgraded JIRA installation (above), then:- Stop the upgraded JIRA installation.
- Migrate the customisations from these files into the upgraded JIRA Installation Directory.
- Restart the upgraded JIRA installation.
- Choose the option to back up JIRA's directories. This creates 'zip' archive file backups of your existing JIRA Installation and JIRA Home Directories in their respective parent directory locations.
- The last step of the upgrade wizard provides you with a link to launch the upgraded JIRA installation in a browser, so you can check the upgrade.
Congratulations, you have completed upgrading your JIRA installation on Linux!
Upgrade Check List
The upgrade wizard requests that you perform the following tasks before it actually commences the upgrade of your existing JIRA installation.
Back Up Your External Database
Perform a backup of your external database (using your database's native backup tools) and verify that the backup was created correctly.
- If your database's native backup tools support 'online backups' (i.e. which would typically create a 'snapshot' of your JIRA database while the database is still in use), you can leave the upgrade wizard running while you perform the database backup and then continue on with the wizard after verifying that the database backup was created correctly.
- If your database's native backup tools do not allow you to perform an 'online backup' of your JIRA database, you should:
- Quit the upgrade wizard now.
- Prevent users from updating your existing JIRA data (to ensure structural consistency of your database backup) by temporarily restricting access to JIRA. Refer to the Preventing users from accessing JIRA during backups page for more information. (To access this page in the documentation for another version of JIRA, click the documentation link for your version of JIRA at the top of the left Table of Contents column and use the search box below to find this page.)
- Use your database's native backup tools to perform an 'offline backup' of your JIRA database and verify that this backup was created correctly.
- Re-run the Linux / Windows Installer to start the upgrade wizard again and continue from where you left off.
- JIRA's 'internal' database is HSQLDB, which should be used for evaluating JIRA only. If you happen to accidentally use the HSQLDB database for a production system, quit the upgrade wizard now and use the Migrating JIRA to Another Server procedure to upgrade JIRA.
Inconsistent database backups may not restore correctly! If you are unfamiliar with your database's native backup/restore facilities, then before proceeding, test your database backup's integrity by:
- restoring the database backup to a different (test) system and
- connecting a test instance of your current JIRA version to this restored database.
Alternatively, use the Migrating JIRA to Another Server procedure to upgrade JIRA instead.
Check Plugin Compatibility
As you may have already done in point 5 of the Before You Start section above, if you have installed any additional JIRA plugins (i.e. not included with JIRA), please verify that they will be compatible with the version of JIRA you are upgrading to. You can find a plugin's compatibility information from the the plugin's home page on the Atlassian Plugin Exchange. Once you have confirmed the availability of compatible versions, you should upgrade your plugins after successfully upgrading JIRA. This can be done via the 'Plugin Repository' in JIRA's Administration Area.
Labels:
82 Comments
Hide/Show CommentsDec 08, 2010
Anonymous
Totally agree. I have much more important things to be doing than spend a day or two to "upgrade" two instances of Jira, and to also inconvenience users!
An "in-place" upgrade is essential.
Dec 09, 2010
Anonymous
I totally agree. Fisheye / Crucible is much more easy to upgrade in comparison. But even that requires a re-installation. Automatic update would be the best.
Feb 19, 2011
Anonymous
A day or two? What are you, dense? Can't handle editing a couple of files?
I just upgraded from 4.0 to 4.2.4 in under 10 minutes.
Feb 21, 2011
Anonymous
Do the upgrade from 3.x to 4.x in 10 mins and I will give you a medal.
Mar 08, 2011
Anonymous
You obviously have a small instance - exporting and importing the DB takes forever if you've been using the product very long or have *any* significant userbase, not to mention attachments.
Mar 09, 2011
Anonymous
Not to mention that it is much more complicated if you are also using Crowd, plugins, integration with Confluence, etc.
Mar 18, 2011
Anonymous
Oh really? Dumping a ~1,2B mysql db takes approx. 15 minutes. More fun is with googling plugins that doesn't work with new versions, because someone had a bright idea and changed URL of plugins repository.
Right now more precise description of moving an existing configuration of LDAP servers would be better.
May 05, 2011
Anonymous
You obviously did NOT follow all the steps. It would take more than 10 mins to backup your db and files.
Sep 01, 2011
Anonymous
How could I get the opportunity to work with you? You seem like a great person. In fact I'm surprised you need JIRA at all as I would have expected any product you worked on to be complete and bug-free.
Dec 09, 2010
Anonymous
Although I'll perform the upgrade, making it this much of a hassle (new db, new port, new file install, editing multiple config files individually, resetting configs, etc.) is what turns people off from upgrading when they should, and will leave many more vulnerable installations out there.
I've been impressed with Atlassian thus far, but this 'upgrade' path is bush-league.
Dec 09, 2010
Michael Downey
Hear, hear! Two upgrades (4.2.0 then urgent 4.2.1 security fixes) in one week is too much.
Dec 12, 2010
Wendell Keuneman [Atlassian]
I wanted to let you all know that we acknowledge the difficulties with the install and upgrade process and have a project underway to provide an improvement to the existing procedures. The scope includes both JIRA and Confluence, with the goal of reducing many of the pain points and simplifying the steps. We hope to have something new for you in the first half of 2011.
Dec 10, 2010
Michael Downey
Upgrading from 4.2.0 to 4.2.1, I tried to make our 4.2.0 MySQL database read-only so we could keep the old system up. I removed INSERT, UPDATE, and DELETE privileges for our jira database user. However, when trying to restart JIRA so the changes would take effect, JIRA would not start up.
Is it even possible to do that with the most recent versions? If so, did I remove too many privileges?
Dec 12, 2010
Rosie Jameson [Atlassian Technical Writer]
Hi Michael, can you please contact http://support.atlassian.com ? Many thanks, Rosie
Dec 13, 2010
Jason Fried
To make this process easier for me to complete and to make sure I do not miss anything i had to make up a script to give me a report of all the changes made to the existing Jira install from the released version.
So to use this you will need perl and a GNU compatible diff, and get the same version of jira you are currently running from the old version archive on atlassian's jira site.
perl jiradiff.pl /path/current-jira /path/dist-copy > diff-report.txt
This will produce a diff report of all the modifications that have been made to your current jira from the base version.
With this information I can upgrade a jira instance in less than 2 hrs and be ready to re-import the DB.
I could also add checks in the script to also scan the future jira version for files that I can just cleanly copy over then that would save some time and editing files.
So that leaves the majority of the time: checking existing plugins against the future version of jira for compatibility.
Feb 01, 2011
Anonymous
Try Beyond Compare. Diff your files and merge what you need. Pretty simple stuff, however, I agree with everyone else that manually upgrading is very 1980s.
Feb 14, 2011
Anonymous
yes, that's true.
Atlassian, please let us know by email when can we get the inline upgrade feature ?
Thanks.
Feb 22, 2011
Luc St-Laurent
Un outil de mise à jour s'impose!
Update Tool FTW !!
Merci :)
Mar 01, 2011
Anonymous
So, I read another post earlier that said Atlassian was working on this to be delivered in first part of 2011... any progress on this? I just got a notice about a security vulnerability and instead of providing a simple patch, I have to completely reinstall my instance of JIRA? This is just crazy, in my opinion, for a security patch. If it was an entirely new version of the software maybe.. but why should I have to reinstall my entire instance of JIRA just for a patch? My company had a HELL of a time setting up JIRA for SSL and integrating it with IIS. I would not upgrade my instance from scratch at all for fear of messing with any of those setups.
Mar 01, 2011
Anonymous
Also known as "Installing JIRA"..... Given the amount of feedback from your customers, don't you think its time to resolve this issue? Is there anyone actually communicating this data to the product management team for JIRA?
Cheers,
/m
Mar 01, 2011
Wendell Keuneman [Atlassian]
We are definitely progressing on this project. We have a separate team dedicated to this activity since the scope is broader than JIRA (i.e. will cover Confluence) and so a cross-functional team was deemed necessary. Naturally given this scope, there is a significant amount of effort. Our goal is to produce a cross-platform guided installation that is upgradeable. It will greatly minimise the steps involved and avoid error prone tasks such as manual file editing.
Our current policy on patches can be found here. We are regularly reviewing our patching policy and certainly plan to do so after we complete the install/upgrade project. We hope that upgrades will be relatively painless in the future.
If you are genuinely interested in our progress I invite you to sign up for our User Taskforce and mention this project with your contact information so we can consider you for our early access program for this activity.
Mar 14, 2011
Anonymous
Upgrade tool: +1
Mar 16, 2011
Michael Jones
We use Ubuntu Server to host Jira here. All packages on the system are collectively one command away from being updated to the newest version except for jira.
I've been trying to upgrade to 4.3 for 3 hours now from 4.2, and frankly this is ridiculous. Manually copying settings files? Thats such an outdated method... I have no recollection of which files I modified to hack together support for being behind a proxy. I have no recollection of which of the dozens of files in atlassian-jira/WEB-INF/classes have anything to do with settings that I care about or specified when I installed the first time.
I don't get why there isn't a one click solution to this built into Jira as it is. You have the steps all written out for us. Make a button that follows the steps! Integrate with the system package manager (Linux distrobutions have had package managers for years and years, after all) . Provide a upgrade executable. Something. ANYTHING, other than making me read through pages and pages of techno-babble trying to figure out what POSSIBLE reason could be causing Jira to not recognise that it's JIRA_HOME used to be occupied by 4.2. What POSSIBLE reason could be causing Jira to not be able to find my /usr/local/jira/export/jira_4_3_update_export.xml file, etc.
Jira is awesome (Overcomplicated by a long shot, but awesome), but only after its installed and running. Both the installation and upgrade procedure are what I would expect from a software product from pre-windows 95.
Mar 17, 2011
Daniel Varela Santoalla
I agree with all what's said here about the upgrades. I am writing a document describing the process just to remind myself of all the steps, which are a few. I am continuously upgrading our evaluation copy of JIRA to see the last features and that's a lot of work.
I am a bit reluctant to upgrade our licensed production copy precisely because of this. I would understand that being a pain as it is people will minimize the number of upgrades, specially in production.
BTW, I got an error upgrading from 4.2.3 to 4.3
ERROR: column "protocol" does not exist
I fixed it by manually adding (from the definition in entitymodel.xml) these three fields to the mailserver table.
protocol | character varying(60) |
istlsrequired | character varying(60) |
timeout | numeric(18,0)
Mar 17, 2011
Bogdan Dziedzic
Are you sure that you haven't reused
entitymodel.xmlfrom your 4.2.3 system? MailServer table has been just introduced in the 4.3 release the protocol is defined in there.<entity entity-name="MailServer" table-name="mailserver" package-name=""> <field name="id" type="numeric"/> <field name="name" type="long-varchar"/> <field name="description" type="very-long"/> <field name="from" col-name="mailfrom" type="long-varchar"/> <field name="prefix" type="short-varchar"/> <field name="smtpPort" col-name="smtp_port" type="short-varchar"/> <field name="protocol" col-name="protocol" type="short-varchar" /> <field name="type" col-name="server_type" type="short-varchar"/> <field name="servername" type="long-varchar"/> <field name="jndilocation" type="long-varchar"/> <field name="username" col-name="mailusername" type="long-varchar"/> <field name="password" col-name="mailpassword" type="long-varchar"/> <field name="istlsrequired" type="short-varchar"/> <field name="timeout" type="numeric" />Mar 18, 2011
Daniel Varela Santoalla
Yes, I'm quite sure of that. The funny thing is that the MailServer table was there, but was missing "protocol","istlsrequired" and "timout". SELECT statements during the migration were failing because these fields were included in the statement but not present in the table.
Mar 20, 2011
Bogdan Dziedzic
That sounds very strange. Is there any chance you could share with us your log file covering the upgrade phase, so we can learn a bit more about the problem?
If possible, can you create a support request and mention our conversation in here.
Cheers,
Mar 21, 2011
Daniel Varela Santoalla
Yes, sure. Thanks a lot for your interest Bogdan.
Created a support issue
https://support.atlassian.com/browse/JSP-75824
Daniel
Mar 29, 2011
Bogdan Dziedzic
From info provided by Daniel we were able to reproduce this problem locally and find the cause of the provided error.
If
entitiengine.xmlis missing the required scheme parameter when integrating with Postgres, during the ugprade process JIRA is unable to create its tables correctly.We have described this problem in more details in our KB page - Missing 'protocol' Column Error After Upgrade.
Mar 17, 2011
Daniel Varela Santoalla
There were a million errors like this in the logs too, for many entities. A problem with mixed/lower case perhaps?
2011-03-17 15:20:00,843 main WARN [core.entity.jdbc.DatabaseUtil] Entity "FavouriteAssociations" has no table in the database
2011-03-17 15:20:00,843 main ERROR [core.entity.jdbc.DatabaseUtil] Could not create table "favouriteassociations"
2011-03-17 15:20:00,843 main ERROR [core.entity.jdbc.DatabaseUtil] SQL Exception while executing the following:
CREATE TABLE favouriteassociations (ID NUMERIC(18,0) NOT NULL, USERNAME VARCHAR(255), entitytype VARCHAR(60), entityid NUMERIC(18,0), SEQUENCE NUMERIC(18,0), CONSTRAINT PK_favouriteassociations PRIMARY KEY (ID))
Error was: org.postgresql.util.PSQLException: ERROR: relation "favouriteassociations" already exists
Mar 17, 2011
Bogdan Dziedzic
If you still experience this problem, can you please create a support request at http://support.atlassian.com and provide us with some more details on the problem:
Apr 19, 2011
Anonymous
Agreed. The update process just makes me leave it as it is. I see no gain in spending hours fiddling in config-files I configured way back. The time (cost) spend simply outweighs the benefit. This is just not the way it is supposed to be. I woud rate this a A-grade issue that should have full focus.
May 11, 2011
Brian Provenzano
I agree with the sentiment above. It is mind boggling that the install/upgrade is not a simple walkthrough script that migrates the settings, database etc without all this hassle. I *love* JIRA, but the we will not be upgrading until this mess is sorted out. I see no point in wasting days planning/testing an upgrade for something like this. This should be priority #1 before any new features IMO. Process should be something like this: run a .deb or .rpm (or some installer), after installer completes - run the setup tool via the browser that migrates the database and verifies everything. Get prompted to restart the app - done. It should be that simple really. Other vendors do this and I know Atlassian can too. They have too good of a product not to get this sorted out. I really hope it comes in 2011.
May 11, 2011
Wendell Keuneman [Atlassian]
We've posted some info on our progress here. Subsequently we are working on an upgradeable installer that pretty much works as Brian Provenzano suggested. Our research indicated the two key customer deployment OS's as Windows and various flavours of Linux. Given the variances we are using an standard Wizard driven Windows executable and a .bin file for Linux rather than a platform specific package manager (although we considered this).
We will provide further news on the upgrade portion in the upcoming weeks.
Jul 27, 2011
Patrick Harris
...
Incidentally, the so-called "Console Wizard" binary download (1) was not executable - why not? (2) Errored with "The architecture or bitness (32/64)
of the bundled JVM might not match your machine". You test this stuff, right? You spin up an image and go through an upgrade yourselves before writing the documentation?
May 25, 2011
Wendell Keuneman [Atlassian]
Hi Patrick,
I'm sorry to hear you encountered issues with the EAP 4. A number of other early access customers have had positive experiences. We've tested the Linux console installer on Red Hat, CentOS, Ubuntu (amongst others) which are the most common platforms used by most of our user base.
What would be helpful in understanding the issues you encountered is if you could you either comment or reply to me via email some information on your OS and environment. Additionally what the mod/own permissions are on the .bin file you downloaded.
Thanks in advance.
Jun 01, 2011
Anonymous
THis fixed it for me on Ubuntu: sudo aptitude install ia32-libs.
Seems to be an issue with the 64bit arc vs the 32bit. The installer calls for 'bin/unpack200"' which is not in that location in 64bit JRE. If you install the 32bits package as well it all works fine :)
The architecture or bitness (32/64)
Jun 01, 2011
Anatoli Kazatchkov
Starting from the next milestone we will ship both 32 and 64 bit packages.
May 25, 2011
Anonymous
I am having the same issue as Patrick with the "Error unpacking jar files. The architecture or bitness (32/64)"
Here is my server info:
Ubuntu 10.10 (maverick - 64bit)
I will go ahead and just run it on a CentOS instance instead for now. The Ubuntu just has a little less overhead.
of the bundled JVM might not match your machine."Error unpacking jar files. The architecture or bitness (32/64)
of the bundled JVM might not match your machine.
Aug 02, 2011
Juerg Gutknecht
Trying to upgrade to 4.4 from JIRA 4.3.4 Standalone on Linux, I've run the upgrade feature without complications. However, when trying to access the new JIRA installation, the JIRA setup is displayed, asking me for a database configuration (even though the JIRA_HOME/dbconfig.xml file was created with the correct configuration data). When I enter the configuration details for my existing JIRA database and test the connection, the setup wizard tells me "The database specified is not empty. Please specify an empty database for your JIRA installation."
Well yes, of course it's not empty - I'm upgrading an existing system. What are the proper steps going from here? I don't see this covered in the above section "Upgrading JIRA on Linux".
ETA: I've created a new database to see what happens. After the tables are added, the setup wizard is asking for further details (license key etc.). Comparing the new database to my existing JIRA database, the two databases are almost identical, except for an additional table, "votehistory", in the new database. This leads me to believe, that my database wasn't migrated at all during the upgrade process. I've now restored my previous 4.3.4 installation and so far it seems to be working, even though I did not restore the database from the backup made before I started the upgrade.
Aug 03, 2011
Giles Gaskell [Atlassian Technical Writer]
Hi Juerg,
The fact that you're being prompted with the JIRA Setup Wizard after upgrading to JIRA 4.4 implies that your upgraded JIRA 4.4 installation was unable to access the
dbconfig.xmlfile in your JIRA Home Directory. If JIRA 4.4 detects adbconfig.xmlfile in your JIRA Home Directory, you should not see the JIRA Setup Wizard (or at least the DB Configuration step of this wizard) upon starting your upgraded JIRA installation for the first time.Is it possible that your upgraded JIRA 4.4 installation is not correctly accessing your JIRA Home Directory?
jira.homeproperty in either:jira-application.propertiesfile (in your JIRA Installation Directory), orconf/server.xmlfile in your JIRA Installation Directory (if you have defined the value of this property specifically in the Tomcat app server running JIRA).JIRA_HOME(as an environment variable on your OS) has been defined correctly (and points to the JIRA Home Directory used by your upgraded JIRA 4.4 installation). Be aware (as we've now clarified in our documentation), the value of aJIRA_HOMEenvironment variable overrides any definition of ajira.homeproperty defined in (1) above.Kind regards,
Giles.
P.S. If you're certain that your upgraded JIRA 4.4 installation is correctly accessing your JIRA Home Directory, then please submit a support request using the button at the end of this page. I'd also recommend attaching the following files:
dbconfig.xmljira-application.propertiesserver.xmlAug 02, 2011
XCOM Media Development Team
Hi,
I noticed that on 25 May 2011 a note was added to the JIRA 4.3 Mac OS X Installation Guide saying:
It seems that any reference to running JIRA 4.4 on Mac OS X Server has been completely removed in the new version also. Just wondering if you had published any warning about this change more widely (e.g. in your email notifications) that we weren’t aware of?
We are a Mac shop and have been running JIRA on our Mac OS X Snow Leopard Server (10.6.8) quite comfortably, but aren’t particularly thrilled with the general “not supported” line/direction that seems to have crept in over the last couple of months.
Another related question: since Apple is not shipping Java with Lion or Lion Server, and getting Oracle to build it instead, will you “support” and “test” JIRA on Mac OS X Lion once that’s released… or are you basically saying to your userbase “don’t install JIRA on a Mac Server, even if it runs the latest official version of Oracle JDK and JRE” moving forward?
Some clear guidance here would definitely be appreciated---we’d rather not have to migrate off JIRA to another task/issues manager but obviously we’ll plan for that if we need to.
Xander Plooy
Technical Team Leader, XCOM Media
Aug 02, 2011
Bryan Rollins [Atlassian]
Xander,
A couple of other customers have had the same question - I just posted some information here on when we removed support.
To your point, we could have been more vocal about the end of support - we posted the change and made the update to our documentation, but it clearly didn't get broad enough distribution because a few customers were surprised by the note when they looked at the JIRA 4.4 download page today. We don't have any explicit plans to reintroduce support for Mac OS X, but we continue to have a large number of customers like yourselves who run JIRA successfully.
Apologies again for any confusion caused,
Bryan Rollins
JIRA Product Management
Aug 02, 2011
XCOM Media Development Team
Thanks for the reply Bryan, but confusion is probably putting it mildly. From the page history it appears that note was added two days prior to the release of version 4.3.4, where no such notice existed when we installed version 4.3.2 (our current version). It’s also since been added to the “Download JIRA” page itself, where it wasn’t previously (i.e. when we installed it). So then…
If that’s the case, it puts us squarely up the creek with our installation, and looking for alternatives… and having to pay up for a hosted JIRA instance won’t be one of them. I’ve been advocating JIRA due to its many benefits, and was responsible for getting it implemented in our workplace, but am left feeling pretty unimpressed right now.
Xander
Dec 24, 2011
Anonymous
Clear to me. Out the door with Jira and Greenhopper. Thanks for everything. My opinion... not very professional to just stop supporting a product on a platform that you've supported for a long time, without notifying your customers properly. You know... you have our email addresses. You might as well have used it to send important information.
I promoted Atlassian several years. That will stop now. Not that you care now that you have more customers than ever, since you changed your licenses to 10 bucks for small teams.
I have been using Jira@Greenhopper on Mac OSX for some time now. Will just migrate my data to some other tool that will run on Mac OSX.
Aug 03, 2011
Anonymous
I tried to upgrade my Jira Beta installation (v4.4-beta1#644-r153810) to the release version 4.4 but I have this error message : "An error occurred when parsing your installation directory"
Any Idea ? Thxs, Clément.
Aug 03, 2011
Anatoli Kazatchkov
Hi Clément,
Unfortunately we never intended/tested the upgrade path from the beta versions to the final release, but there is a workaround for the problem you are seeing.
When installer runs it first works out if it upgrades from a version earlier than 4.4 (eg. 4.3.2 or 4.3.1) it needs to perform certain migration tasks. One of the task is to transfer the db configuration from the old way (config defined inside
<install-dir>/conf/server.xmland<install-dir>/atlassian-jira/WEB-INF/classes/entityengine.xml)to the new way (config defined inside<home-dir>/dbconfig.xml) .In your case installer rightly thinks that this version is earlier than 4.4 and assumes that the db would be configured in the old way and when it does not find the old way(because rc uses the new way already) it doesn't know what to do and exits.
As a workaround you can trick the installer by modifying
<install-dir>/atlassian-jira/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.propertiesfile and change the version from 4.4-beta1 to just 4.4 then the upgrade will work.Anatoli.
Oct 21, 2011
Anonymous
We are getting ready to upgrade from 4.4-rc1 to 4.4.1, should I make this change as well?
Oct 24, 2011
Anatoli Kazatchkov
Yep, you should make this change.
Aug 03, 2011
Anonymous
Exactly the same problem for me - running JIRA 4.4-beta1-#638.
When choosing the upgrade option in the installer it correctly detects the path of the existing jira installation and then as soon as you confirm this it fails with:
nice spelling of 'upgrade' too :)
Any suggestions?
Aug 03, 2011
Anatoli Kazatchkov
See the workaround I have described for the problem.
Thanks for catching the spelling mistake, we'll fix it.
Aug 05, 2011
Anonymous
After the update, from 4.3 to 4.4, I get this exception when I run Jira.
java.lang.NoClassDefFoundError: com/atlassian/jira/startup/ApplicationPropertiesJiraHomePathLocator$1
at com.atlassian.jira.startup.SystemTenantJiraHomeLocator.<init>(SystemTenantJiraHomeLocator.java:12)
at com.atlassian.jira.startup.JiraHomeStartupCheck.<clinit>(JiraHomeStartupCheck.java:37)
at com.atlassian.jira.logging.MultiTenantJiraHomeAppender.<init>(MultiTenantJiraHomeAppender.java:27)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:330)
at org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:121)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:664)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:647)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:544)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:440)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:476)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:125)
at org.apache.log4j.Logger.getLogger(Logger.java:118)
at com.atlassian.jira.startup.LauncherContextListener.<clinit>(LauncherContextListener.java:34)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
Thanks
Aug 05, 2011
Anonymous
I fix the problem. I have jira-home directory inside jira installation directory.
Aug 06, 2011
Giles Gaskell [Atlassian Technical Writer]
I'm glad you found the cause of the issue and just to reiterate, locating your JIRA Home Directory inside your JIRA Installation Directory is not recommended.
Aug 16, 2011
Anonymous
I have the same problem after running the upgrade script (on Linux). I've tried changing the JIRA home directory, but that didn't work.
The class is there:
What's the deal?
Aug 16, 2011
Joshua Davis
I've tried moving the JIRA Home and Installation directories, but that didn't work. I still get this NoClassDefFoundError on start up.
ApplicationPropertiesJiraHomePathLocatormust be referring to something that is not in the classpath, because as I posted below (anonymously), the class exists.Aug 08, 2011
Troy Murray
I performed an upgrade from JIRA 4.3.4 today to JIRA 4.4 on my Ubuntu Linux 10.04 system. This JIRA instance is hosted behind my Apache web server and uses SSL (I access JIRA using https://www.mydomain.com/jira).
The installation wizard is "nice", but it didn't migrate the following settings from my existing conf/server.xml in the <Connector> section under <Service name="Catalina">
The installation wizard also didn't migrate the additional setting from my existing conf/server.xml in <Engine>, <Host>, <Context>
Aug 08, 2011
Anatoli Kazatchkov
Hi Troy, thanks for mentioning your problems it will definitely help us to improve the upgrader.
The issues you described are discussed under https://jira.atlassian.com/browse/JRA-25277.
Aug 15, 2011
Anonymous
Just an FYI, if you change the name of the <JIRA Install Directory>/atlassian-jira directory, the upgrader will fail saying that the directory is "not a valid existing JIRA installation directory". Don't think this was specifically stated anywhere, but the sub-directory has to be named "atlassian-jira" to get it to work.
Aug 15, 2011
Burke Mamlin
Just ran the 64-bit Linux installer to upgrade a small instance on an Ubuntu server from 4.3 to 4.4. I answered a few questions and upgraded JIRA successfully in 1-2 minutes. Nice!
The only thing that surprised me was that the installation went into the same directory – i.e., 4.4 was installed into
/usr/local/jira-4.3/where my previous installation was located. It would be nice to have the option to install into a new directory. For example, upgrade from/usr/local/jira-4.3/ }}into {{/usr/local/jira-4.4/. Maybe other folks use a single directory, but I prefer to use versioned directories and keep/usr/local/jiraas a symlink to the current version.Aug 15, 2011
Michael Downey
+1 ... I had a similar experience with the directory names. (I had, after all, followed Atlassian's guidance on naming directories after the JIRA version).
Aug 16, 2011
Anatoli Kazatchkov
Burke, Michael,
It was quite tough for us to decide if we wanted to install the new version on-top of the old one or create a new version-named directory. On one hand if the old directory has the version number in its name then upgrading on-top will mean the new version will sit in the directory named after an old version. On the other hand customers may have existing scripts, services, custom created menu shortcuts on windows or other environment settings that depend on the existing name of the directory. At the end we decided that preserving the environment and not breaking the existing scripts is more important and we went with the on-top upgrade option. We have also changed the suggested installation directory name for the installer - now it doesn't include a version number.
Aug 16, 2011
Burke Mamlin
How about a separate question? e.g., if JIRA was detected in
/usr/local/jira-4.3/, then you'd get these two questions:Location of existing installation to upgrade [/usr/local/jira-4.3/]?Destination for upgraded version? [/usr/local/jira-4.3/]?Subsequent versions of the installer could try to be smarter and, if a version number detected in the current location, would suggest a folder with the new version in that case.
People who want to install directly over the existing location just need to press Enter one extra time. Those of us who use versioned installs & symlinks won't be surprised where the new version ends up.
Sep 12, 2011
Anonymous
seconded!
Sep 12, 2011
François Manchon
+1
I ran the installer to upgrade from 4.3.4 to 4.4. The upgrade process is perfect
Now, having version 4.4 installed in /home/jira/atlassian-jira-4.3.4-standalone/ is awkward. I know where I live (for now), but this is definitely confusing. I finally renamed the installation directory to /home/jira/atlassian-jira-standalone as follows:
bin/permgen.shand adjust JAVA_HOME to the new directory name/etc/init.d/jiraand adjust BASE to the new directory nameThis worked for me. I hope I didn't miss anything. Comments are welcome!
Sep 12, 2011
Anatoli Kazatchkov
etc/init.d/jirais one of a reason why we decided not to change the name of the installation directoryYour steps will work fine. If you have some other scripts that point to the old installation dir you will have to change them too.
Jan 25, 2012
Jason Brison
Thank you very much for posting this change.
Atlassian Support - It would be nice in the future if the upgrade script would just rename the directory for us
-Jason
Aug 16, 2011
Anonymous
Hi,
I've tried to update from 4.3.4 to 4.4 in Test Environment, but the update fails immediately with the already seen message:
An error occurred when parsing your installation directory. Unfortuantely the installer will be unable to continue with the automated updgrade.
My installation folder is:
C:\Program Files\Atlassian\JIRA 4.3.4
What could I do to bypass the problem? If possible I would not try to reinstall Jira by scratch and then reimport, copy files, etc.
Thanks,
Marco Barbaro
Aug 16, 2011
Anatoli Kazatchkov
Hi,
it is definitely possible to do the upgrade the old way i.e. export data from the old version install a new version of JIRA and import the data into it.
You might want to contact support to figure out why the new upgrader didn't work for you.
Aug 17, 2011
Giles Gaskell [Atlassian Technical Writer]
Hi Marco,
Try either the Upgrading JIRA Manually (which involves an 'in-place' upgrade of your JIRA database) or Migrating JIRA to Another Server (which involves lengthier XML exports and imports of your JIRA database).
Having said that, I'd also recommend contacting support to work out why the upgrade wizard didn't work for you.
Cheers,
Giles.
Aug 17, 2011
Marco Barbaro
Thanks to both Anatoli and Giles,
however I've opened an issue to the support (code 88141)
Marco
Aug 17, 2011
Joshua Davis
I've also filed a support incident: https://support.atlassian.com/browse/JSP-88240 Trying the manual upgrade tonight, after hours.
Aug 30, 2011
Max Abramovich
Hi!
Can I find instruction for upgrading from JIRA 3.13.5 to 4.4? Can i do this action from one step? Or I need upgrade to 4.0, and later to 4.4?
Sep 18, 2011
Giles Gaskell [Atlassian Technical Writer]
Hi Max,
Since you're upgrading from JIRA 3.13, please follow the Migrating JIRA to Another Server procedure to upgrade to JIRA 4.4.
There's no need to upgrade to an interim JIRA version before upgrading to JIRA 4.4, although the Migrating JIRA to Another Server procedure is more involved than the one described above.
Once you're on JIRA 4.4, however, upgrades to future versions of JIRA should be faster and relatively straightforward — i.e. based on the procedure above. (This is assuming you haven't customised your JIRA installation too much and you're using the JIRA Standalone distribution.)
Cheers,
Giles.
Sep 08, 2011
François Nonnenmacher
There are several caveats with the new upgrade application:
Sep 12, 2011
Anatoli Kazatchkov
François,
Thanks for listing the caveats, especially the fisheye problem - I don't think we mentioned it anywhere. Some background for 'installing everything in the old directory' : http://confluence.atlassian.com/display/JIRA/Upgrading+JIRA?focusedCommentId=252349591#comment-252349591 .
Sep 13, 2011
François Nonnenmacher
The Fisheye problem is a real UX bug, because if you follow the instructions provided within JIRA, you end up in a very difficult situation (having to delete records manually in the database isn't pleasant).
As for the directory name issue, I perfectly understand the reason for not changing it. It's a one time issue, once you understand how it works it's a matter of changing your habits (which might be more difficult than renaming things on the server
). I've just updated from 4.4 to 4.4.1 and it was a much more pleasant experience, so this one's going to be soon forgotten.
There remains one caveat that I faced again today: the upgrade does not properly pass through the proxy details in conf/server.xml which forces to stop and restart JIRA after carrying the modifications. Ideally you should allow the admin to copy the modifications during the update (may be showing diffs between the old and the new file), or at a minimum suspend the upgrade process and let the admin modify some key files before starting the upgraded JIRA instance.
Oct 22, 2011
Chris Johnson
More bugs in the new upgrade installer:
Sep 12, 2011
Anonymous
As I just completed the upgrade on Linux a few remarks regarding the upgrade-tool:
"chown -R jira: /opt/atlassian-jira-*-standalone/logs && chown -R jira: /opt/atlassian-jira-*-standalone/temp && chown -R jira: /opt/atlassian-jira-*-standalone/work")
Maybe this could be adressed for future versions of the upgrade tool?
(Also the "reusing of the old directory" is quite annoying if one did include the version in the path.. but that was already commented above)
Sep 12, 2011
Anatoli Kazatchkov
Sounds like a bug. When upgrading from 4.3 to 4.0 we actually try to preserve the ownership of the files and then start the process as the user who owns the files. Obviously id didn't work for you as "all files were chowned 403:root" . After changing the permissions you might want to set the username in the
user.shfile if you start it as a service (i.e. if you run the start command asroot), it will just switch tojirabefore launching the process.re: modifications of the
server.xmlWe actually do warn in the documentation that only port numbers get migrated over from
server.xml. Obviously, it is not the ideal behavior - this issue tracks the possible solutions and elaborates on why the current approach was chosen.Oct 20, 2011
Anonymous
Hey guys, how about detailed upgrade instructions for OSX as well?
Oct 20, 2011
Giles Gaskell [Atlassian Technical Writer]
Hi there,
Just so that you're aware, we don't focus on writing documentation for platforms or configurations that we don't support. Our Supported Platforms page indicates that Mac OS X is not a platform supported by JIRA and our Java section on the JIRA Requirements page indicates why we don't support this operating system.
If you do want to follow upgrade instructions for Mac OS X, the Upgrading JIRA Manually or Migrating JIRA to Another Server procedures might suit your requirements.
Cheers,
Giles.
Add Comment