Upgrade from 4.0.13-1 to 4.2.8-3 failed on one of my instance of RT4
Upgrade from 4.0.19 to 4.2.8-1 - worked.

I don't know where I can find full upgrade logs.
In RT admin page in RT upgrade history I see:


If I correctly understand upgrade history above all updates from 4.0.19
to 4.2.8 applied and after that upgrade script tries to apply updates
one more time

They are output to the dpkg session (ie to STDOUT). I assume you didn't
manage to capture those? The only way I can see that a given database
upgrade would have been attempted several times is if there was some sort
of error during the initial upgrade (dbconfig-common, which the RT packages
use to manage the database upgrades, may offer to retry actions in
some cases). Without seeing a transcript of the dpkg run it's going
to be quite difficult to work out what happened here in order to be able
to fix anything. Do you have any more recollections of what happened?

What is the current state of your system? Does RT work? And does
dpkg think the package is configured?

Dominic.

Hi, Dominic

05.04.2015 19:04, Dominic Hargreaves пишет:

Yes, dpkg output was overwritten by other messages.

RT is working now, but i don't know if internal db structure fully
correct or not.
dpkg thinks that package is fully configured because I refuse upgrading
via dbconfig after error.

I'll try to make temporary VM with archive db and 4.0.13 RT and try to
reproduce this problem.

PS. I have another very similar RT instance (cloned from main) with
other uprgade path: 4.0.13->4.0.19->4.2.8
I have no problem with upgrade at this instance.

Hi, Dominic

I'm sorry, but I can't reproduce problem on dev instance of RT4.
So I try to reproduce on copy of production VM as soon as I can make new
instance from backups.


06.04.2015 14:01, Max Kosmach пишет:

Hi, Dominic

Problem replicated, log below

Steps to reproduce:
1 - first attempt to upgrade via dbconfig fail
(my primary RT - RT update innvocation fail because my RT modifications
my dev RT - dbcondig can't backup 4.0.13 DB because lack of disk space)
2 - continue with upgrade after fixing problem
3 - upgrade fail with "DBD::Pg::st execute failed: ERROR:  column
"disabled" of relation "scrips" already exists"


log from dpkg:
Configuring package (in russian)

no free space on device (russian)



06.04.2015 17:42, Max Kosmach пишет:

Control: retitle -1 request-tracker4 DB upgrade can't be applied multiple times

Okay, I now think we have a clear summary of the problem; thanks for
taking the time to run those tests! It seems to be a general issue
with recovering from errors (the actual error was not caused by a bug
in RT). It should be possible to improve the situation so that an upgraade
can be run twice, although we'll have to talk to upstream about the best
way to achieve that.

Cheers,
Dominic.

Dear submitter,

as the package request-tracker4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1134418

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)