reassign 708339 dbconfig-common retitle 708399 Upgrade steps executed twice thanks
❦ 15 mai 2013 09:23 CEST, Frédéric Gobry <[email protected]> : > I've upgraded my squeeze system to wheezy and faced problems during the > roundcube mysql update. > > Detailed sequence: > > * The first upgrade failed because I had modified the mysql permissions of > root@localhost. This is > not a bug in itself, I just let you know for the context: > > Creating database backup in > /var/cache/dbconfig-common/backups/roundcube_0.3.1-6.mysql. > ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using > password: NO). > unable to connect to mysql server. > error encountered backing up the old database: > ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using > password: NO) > > * once I had modified the permissions back, I retried the upgrade (in "don't > ask questions" mode) > but this failed again: > > creating database backup in > /var/cache/dbconfig-common/backups/roundcube_0.3.1-6.mysql. > applying upgrade sql for 0.3.1-6 -> 0.5-1. > applying upgrade sql for 0.3.1-6 -> 0.6+dfsg-1. > applying upgrade sql for 0.3.1-6 -> 0.7-1. > applying upgrade sql for 0.3.1-6 -> 0.7.1-1. > dbconfig-common: flushing administrative password > applying upgrade sql for 0.3.1-6 -> 0.5-1. > error encountered processing > /usr/share/dbconfig-common/data/roundcube/upgrade/mysql/0.5-1: > mysql said: ERROR 1146 (42S02) at line 5: Table 'roundcube.messages' doesn't > exist > > I'm surprised to see that the 0.3.1-6 - > 0.5-1 step took place twice. The > failure is > caused by the "messages" table being dropped in the 0.3.1-6 -> 0.7-1 update. > > I then started hacking my way through it, and noticed that the backup in > /var/cache was > actually in a strange mixed state. Turns out that the backup is recreated at > _every_ > attempt. So, after the first failed attempt, the backup is replaced with a > half-backed > one, which means that even if I had fixed the duplicate application of the > update > script, I wouldn't have been able to go smoothly through the whole > process. The upgrade is handled by dbconfig-common. It is a known problem that a failed upgrade may lead to partially updated DB but this is not your case. I don't know why the upgrade step has been executed twice. Reassigning to dbconfig-common and let's see if we can get a hint. -- Write clearly - don't sacrifice clarity for "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
pgp2sP1T5wkmo.pgp
Description: PGP signature
