[rt-users] Upgrade History shows Upgrade Incomplete

Nathan Baker bakern at gmail.com
Fri May 23 10:30:29 EDT 2014

> On Thu, May 22, 2014 at 04:33:01PM -0400, Kevin Falcone wrote:
> > oh.
> > You cannot safely upgrade RT like that.
> >
> > Restore from a backup and upgrade cleanly.
> >
> > I wouldn't trust a database that had run the upgrades twice.

You're right, that would be the safest.  I've been running it in production
for 1-2 days now though, with no errors or noticeable issues, so I think
I'm just going to leave it.  Thanks to the new "RT upgrade history", I can
see which steps attempted to run twice before it failed the second time.  I
looked at all of those changes, and I don't see anything in there that
would cause any problems with the data or schema.  The steps that ran a
second time are:

Insert from /usr/share/request-tracker4/etc/upgrade/4.0.9/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.0.18/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.0.19/content
Insert from /usr/share/request-tracker4/etc/upgrade/4.1.0/content

So I think I got lucky that it failed right after that before getting any
further :)

On Fri, May 23, 2014 at 6:13 AM, Dominic Hargreaves <
dominic.hargreaves at it.ox.ac.uk> wrote:

> Ah, I had always assumed that updates were idempotent. Sounds like
> we need to adjust the error handling in the Debian package then.
> (What I think happened in Nathan's case was that the upgrade itself
> went okay but something else went wrong in the package postinst).

The first thing that failed during the upgrade process was the database
backup.  Peer authentication for user "postgres" failed.  I'm not sure if
it ever worked on this system, but RT was installed originally using Debian
packages.  I had backed up the database manually before starting just to be
safe.  Running "passwd postgres" and setting a password for that user got
peer authentication working.

During the database upgrade part, I'm not sure why it was failing to
perform the upgrade.  Finally after I selected "retry" and then answered
"No" when asked to use dbconfig to upgrade the database (I was going to do
it manually at that point), it actually started performing the database
upgrade, but from what I can tell it tried to do it twice.

I'm not ruling out that I did something wrong, but if you have anything you
want me to check on this system let me know.  I have the apt term.log yet
which shows what was done, but unfortunately won't show what answers I
chose during the process.  When the RT 4.2.4 package gets to testing I will
try that one and let you know if I have any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140523/a21adddf/attachment.htm>

More information about the rt-users mailing list