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

05.04.2015 19:04, Dominic Hargreaves пишет:
On Fri, Apr 03, 2015 at 05:55:32PM +0300, Max Kosmach wrote:
Package: request-tracker4
Version: 4.2.8-3
Severity: important


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:

They are output to the dpkg session (ie to STDOUT). I assume you didn't
manage to capture those?

Yes, dpkg output was overwritten by other messages.

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?

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.



--
With best wishes
Max


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to