Bug#781833: [request-tracker-maintainers] Bug#781833: Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
Control: retitle -1 request-tracker4 DB upgrade can't be applied multiple times On Mon, Apr 06, 2015 at 07:38:39PM +0300, Max Kosmach wrote: 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 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781833: [request-tracker-maintainers] Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
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
Bug#781833: [request-tracker-maintainers] Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
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
Bug#781833: [request-tracker-maintainers] Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
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: Настраивается пакет request-tracker4 (4.2.8-3) … Configuring package (in russian) **WARNING** **WARNING** If you are using mod_perl or any form of persistent perl **WARNING** process such as FastCGI, you will need to restart your **WARNING** web server and any persistent processes now. **WARNING** **WARNING** For mod_perl this means **WARNING** **WARNING** invoke-rc.d apache2 stop invoke-rc.d apache2 start **WARNING** **WARNING** **WARNING** If you are using mod_perl or any form of persistent perl **WARNING** process such as FastCGI, you will need to restart your **WARNING** web server and any persistent processes now. **WARNING** **WARNING** For mod_perl this means **WARNING** **WARNING** invoke-rc.d apache2 stop invoke-rc.d apache2 start **WARNING** dbconfig-common: writing config to /etc/dbconfig-common/request-tracker4.conf creating database backup in /var/cache/dbconfig-common/backups/request-tracker4_4.0.13-1.pgsql. error encountered backing up the old database: pg_dump: [архиватор] could not write to output file: На устройстве не осталось свободного места no free space on device (russian) dbconfig-common: request-tracker4 configure: retrying. dbconfig-common: writing config to /etc/dbconfig-common/request-tracker4.conf creating database backup in /var/cache/dbconfig-common/backups/request-tracker4_4.0.13-1.pgsql. applying upgrade script for 4.0.13-1 - 4.0.19. Working with: Type: Pg Host: localhost Port: Name: requesttracker4 User: requesttracker4 DBA:requesttracker4 (No DBA) Now inserting data. Done inserting data. Done. Working with: Type: Pg Host: localhost Port: Name: requesttracker4 User: requesttracker4 DBA:requesttracker4 (No DBA) Now inserting data. Done inserting data. Done. applying upgrade script for 4.0.13-1 - 4.2.3. Working with: Type: Pg Host: localhost Port: Name: requesttracker4 User: requesttracker4 DBA:requesttracker4 (No DBA) Enter RT version you're upgrading from: Going to apply following upgrades: * 4.1.0 * 4.1.1 * 4.1.4 * 4.1.5 * 4.1.6 * 4.1.7 * 4.1.8 * 4.1.9 * 4.1.10 * 4.1.11 * 4.1.12 * 4.1.13 * 4.1.14 * 4.1.15 * 4.1.16 * 4.1.17 * 4.1.18 * 4.1.19 * 4.1.20 * 4.1.21 * 4.1.22 * 4.1.23 * 4.2.1 * 4.2.2 * 4.2.4 * 4.2.6 * 4.2.7 * 4.2.8 Enter RT version if you want to stop upgrade at some point, or leave it blank if you want apply above upgrades: Going to apply following upgrades: * 4.1.0 * 4.1.1 * 4.1.4 * 4.1.5 * 4.1.6 * 4.1.7 * 4.1.8 * 4.1.9 * 4.1.10 * 4.1.11 * 4.1.12 * 4.1.13 * 4.1.14 * 4.1.15 * 4.1.16 * 4.1.17 * 4.1.18 * 4.1.19 * 4.1.20 * 4.1.21 * 4.1.22 * 4.1.23 * 4.2.1 * 4.2.2 Processing 4.1.0 Now inserting data. Processing 4.1.1 Now populating database schema. Now inserting database ACLs. Now inserting data. Processing 4.1.4 Now populating database schema. Now inserting data. Processing 4.1.5 Now populating database schema. Now inserting data. Processing 4.1.6 Now inserting data. Processing 4.1.7 Now populating database schema. Processing 4.1.8 Now populating database schema. Processing 4.1.9 Now inserting data. Processing 4.1.10 Now populating database schema. Processing 4.1.11 Now populating database schema. Processing 4.1.12 Now inserting data. Processing 4.1.13 Now populating database schema. Processing 4.1.14 Now populating database schema. Processing 4.1.15 Now inserting data. Processing 4.1.16 Now inserting data. Processing 4.1.17 Now inserting data. Processing 4.1.18 Now inserting data. Processing 4.1.19 Now populating database schema. Processing 4.1.20 Now inserting data. Processing 4.1.21 Now inserting data. Processing 4.1.22 Now populating database schema. Now inserting data. [13319] [Mon Apr 6 15:41:58 2015] [info]: Going to delete all SMIMEKeyNotAfter attributes (/usr/share/request-tracker4/etc/upgrade/4.1.22/content:61) Processing 4.1.23 Now inserting database indexes. Processing 4.2.1 Now inserting data. Processing 4.2.2 Now inserting data. Done. applying upgrade script for 4.0.13-1 - 4.2.4. Working with: Type: Pg Host: localhost Port: Name: requesttracker4 User: requesttracker4 DBA:requesttracker4 (No DBA) Enter RT version you're upgrading from: Going to apply following upgrades: * 4.2.4 * 4.2.6 * 4.2.7 * 4.2.8 Enter RT version if you want to stop upgrade at some point, or leave it blank if you want apply above upgrades: Going to apply following upgrades: * 4.2.4 Processing 4.2.4 Now inserting data. Done. applying upgrade script for 4.0.13-1 - 4.2.6. Working with: Type: Pg Host: localhost Port: Name: requesttracker4 User: requesttracker4 DBA:
Bug#781833: [request-tracker-maintainers] Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
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? 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. RT (Current version: 4.2.8) Action DateElapsed RT Version Insert from /usr/share/request-tracker4/etc/upgrade/4.0.18/content Mon Mar 30 20:56:48 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.0.19/content Mon Mar 30 20:56:50 20150 seconds 4.2.8 Upgrade from 4.0.19 to 4.2.3 Mon Mar 30 20:56:51 201544 seconds 4.2.8 Upgrade from 4.0.19 to 4.1.0 Mon Mar 30 20:56:51 201511 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.0/content Mon Mar 30 20:56:51 201511 seconds 4.2.8 Upgrade from 4.1.0 to 4.1.1Mon Mar 30 20:57:02 20151 second4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.1 Mon Mar 30 20:57:02 20150 seconds 4.2.8 ACL updates from /usr/share/request-tracker4/etc/upgrade/4.1.1 Mon Mar 30 20:57:02 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.1/content Mon Mar 30 20:57:02 20151 second4.2.8 Upgrade from 4.1.1 to 4.1.4Mon Mar 30 20:57:03 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.4 Mon Mar 30 20:57:03 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.4/content Mon Mar 30 20:57:03 20150 seconds 4.2.8 Upgrade from 4.1.4 to 4.1.5Mon Mar 30 20:57:03 20151 second4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.5 Mon Mar 30 20:57:03 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.5/content Mon Mar 30 20:57:03 20151 second4.2.8 Upgrade from 4.1.5 to 4.1.6Mon Mar 30 20:57:04 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.6/content Mon Mar 30 20:57:04 20150 seconds 4.2.8 Upgrade from 4.1.6 to 4.1.7Mon Mar 30 20:57:04 20154 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.7 Mon Mar 30 20:57:04 20154 seconds 4.2.8 Upgrade from 4.1.7 to 4.1.8Mon Mar 30 20:57:08 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.8 Mon Mar 30 20:57:08 20150 seconds 4.2.8 Upgrade from 4.1.8 to 4.1.9Mon Mar 30 20:57:09 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.9/content Mon Mar 30 20:57:09 20150 seconds 4.2.8 Upgrade from 4.1.9 to 4.1.10 Mon Mar 30 20:57:09 20151 second4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.10 Mon Mar 30 20:57:09 20151 second4.2.8 Upgrade from 4.1.10 to 4.1.11 Mon Mar 30 20:57:10 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.11 Mon Mar 30 20:57:10 20150 seconds 4.2.8 Upgrade from 4.1.11 to 4.1.12 Mon Mar 30 20:57:10 20151 second4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.12/content Mon Mar 30 20:57:10 20151 second4.2.8 Upgrade from 4.1.12 to 4.1.13 Mon Mar 30 20:57:11 201511 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.13 Mon Mar 30 20:57:11 201511 seconds 4.2.8 Upgrade from 4.1.13 to 4.1.14 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.14 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Upgrade from 4.1.14 to
Bug#781833: upgrade from 4.0.13 to 4.2.8 failed
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: RT (Current version: 4.2.8) Action DateElapsed RT Version Insert from /usr/share/request-tracker4/etc/upgrade/4.0.18/content Mon Mar 30 20:56:48 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.0.19/content Mon Mar 30 20:56:50 20150 seconds 4.2.8 Upgrade from 4.0.19 to 4.2.3 Mon Mar 30 20:56:51 201544 seconds 4.2.8 Upgrade from 4.0.19 to 4.1.0 Mon Mar 30 20:56:51 201511 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.0/content Mon Mar 30 20:56:51 201511 seconds 4.2.8 Upgrade from 4.1.0 to 4.1.1 Mon Mar 30 20:57:02 20151 second 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.1 Mon Mar 30 20:57:02 20150 seconds 4.2.8 ACL updates from /usr/share/request-tracker4/etc/upgrade/4.1.1 Mon Mar 30 20:57:02 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.1/content Mon Mar 30 20:57:02 20151 second4.2.8 Upgrade from 4.1.1 to 4.1.4 Mon Mar 30 20:57:03 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.4 Mon Mar 30 20:57:03 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.4/content Mon Mar 30 20:57:03 20150 seconds 4.2.8 Upgrade from 4.1.4 to 4.1.5 Mon Mar 30 20:57:03 20151 second 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.5 Mon Mar 30 20:57:03 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.5/content Mon Mar 30 20:57:03 20151 second4.2.8 Upgrade from 4.1.5 to 4.1.6 Mon Mar 30 20:57:04 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.6/content Mon Mar 30 20:57:04 20150 seconds 4.2.8 Upgrade from 4.1.6 to 4.1.7 Mon Mar 30 20:57:04 20154 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.7 Mon Mar 30 20:57:04 20154 seconds 4.2.8 Upgrade from 4.1.7 to 4.1.8 Mon Mar 30 20:57:08 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.8 Mon Mar 30 20:57:08 20150 seconds 4.2.8 Upgrade from 4.1.8 to 4.1.9 Mon Mar 30 20:57:09 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.9/content Mon Mar 30 20:57:09 20150 seconds 4.2.8 Upgrade from 4.1.9 to 4.1.10 Mon Mar 30 20:57:09 20151 second 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.10 Mon Mar 30 20:57:09 20151 second4.2.8 Upgrade from 4.1.10 to 4.1.11 Mon Mar 30 20:57:10 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.11 Mon Mar 30 20:57:10 20150 seconds 4.2.8 Upgrade from 4.1.11 to 4.1.12 Mon Mar 30 20:57:10 20151 second 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.12/content Mon Mar 30 20:57:10 20151 second4.2.8 Upgrade from 4.1.12 to 4.1.13 Mon Mar 30 20:57:11 201511 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.13 Mon Mar 30 20:57:11 201511 seconds 4.2.8 Upgrade from 4.1.13 to 4.1.14 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.14 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Upgrade from 4.1.14 to 4.1.15 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.15/content Mon Mar 30 20:57:22 20150 seconds 4.2.8 Upgrade from 4.1.15 to 4.1.16 Mon Mar 30 20:57:22 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.16/content Mon Mar 30 20:57:22 20150 seconds 4.2.8 Upgrade from 4.1.16 to 4.1.17 Mon Mar 30 20:57:22 20151 second 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.17/content Mon Mar 30 20:57:22 20151 second4.2.8 Upgrade from 4.1.17 to 4.1.18 Mon Mar 30 20:57:23 20150 seconds 4.2.8 Insert from /usr/share/request-tracker4/etc/upgrade/4.1.18/content Mon Mar 30 20:57:23 20150 seconds 4.2.8 Upgrade from 4.1.18 to 4.1.19 Mon Mar 30 20:57:23 20150 seconds 4.2.8 Schema updates from /usr/share/request-tracker4/etc/upgrade/4.1.19 Mon
