[request-tracker-maintainers] Bug#781833: Bug#781833: upgrade from 4.0.13 to 4.2.8 failed

[Max Kosmach]

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