370664 - Upgrade from 2.16.7 to 2.22.1-2 fails without updating the database

Status: RESOLVED WONTFIX

(Bugzilla :: Installation & Upgrading, defect)

Description

[Pedro Viegas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061115 Ubuntu/dapper-security Firefox/1.5.0.8
Build Identifier: 2.22.1-2

I use debian and after a debian based upgrade of bugzilla since the database username was not the default one, the build stopped without connecting to the database.

This was all fine, I then corrected the "/etc/bugzilla/localconfig" to set the correct DB user and tryed to run the:

./checksetup.pl

(witch is what the debian package would do since I allready issued a reinstall on the debian package manager apt-get.

On checksetup execution I get errors on checking some objects in the database.

I have know a dead production bugzilla instalation with the database waiting for the upgrade.

Reproducible: Always

Steps to Reproduce:
1. Install a Debian system with the stable repositories (it has bugzilla 2.16.7)
2. Change the username from 'bugzilla' to 'bugs' in the database and change the localconfig accordingly
3. Change apt-get for the testing repositorys (they have bugzilla 2.22.1)
4. issue: apt-get install bugzilla for an upgrade
5. Select to install the new localconfig file overwriting the existing one where the username had been changed
6. We get the result log...

Can't connect to the database.
Error: Access denied for user: 'bugzilla@localhost' (Using password: YES)
  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?

7. Change the username again in localconfig to 'bugs'
8. Issue a apt-get installl bugzilla --reinstall or a ./checksetup.pl... the results are the same

I have got this in 2 out of 2 attempts.
the first one I did not have a bug database. It was a sandbox for testing, so I deleted the database schema and ran ./chacksetup again and it installed an empty funcioninal repository.
In this case I can«t do that since this bugzilla supports all of the 7000 bugs my company has solved over the years!
Actual Results:  
When I issue the...

cvs:/usr/share/bugzilla/lib# ./checksetup.pl

I get...

Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.56
Checking for             CGI (v2.93)   ok: found v3.15
Checking for    Data::Dumper (any)     ok: found v2.121_08
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.38)   ok: found v1.46
Checking for      File::Spec (v0.84)   ok: found v3.12
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.10)   ok: found v2.14
Checking for      Text::Wrap (v2001.0131) ok: found v2005.082401
Checking for    Mail::Mailer (v1.67)   ok: found v1.74
Checking for    MIME::Base64 (v3.01)   ok: found v3.07
Checking for    MIME::Parser (v5.406)  ok: found v5.420
Checking for        Storable (any)     ok: found v2.15

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.23
Checking for Template::Plugin::GD::Image (any)     ok: found v1.56
Checking for     Chart::Base (v1.0)    ok: found v2.2
Checking for       XML::Twig (any)      not found
Checking for       GD::Graph (any)      not found
Checking for GD::Text::Align (any)      not found
Checking for     PatchReader (v0.9.4)   not found
Checking for   Image::Magick (any)      not found
Checking for    HTML::Parser (v3.40)   ok: found v3.45
Checking for  HTML::Scrubber (any)      not found

If you want to use the bug import/export feature to move bugs to
or from other bugzilla installations, you will need to install
 the XML::Twig module by running (as root):

   /usr/bin/perl -MCPAN -e 'install "XML::Twig"'

If you want to convert BMP image attachments to PNG to conserve
disk space, you will need to install the ImageMagick application
Available from http://www.imagemagick.org, and the Image::Magick
Perl module by running (as root):

   /usr/bin/perl -MCPAN -e 'install "Image::Magick"'

If you you want to see graphical bug reports (bar, pie and line charts of
current data), you should install libgd and the following Perl modules:

GD::Graph:       /usr/bin/perl -MCPAN -e 'install "GD::Graph"'
GD::Text::Align: /usr/bin/perl -MCPAN -e 'install "GD::Text::Align"'

If you want to see pretty HTML views of patches, you should install the
PatchReader module:
PatchReader: /usr/bin/perl -MCPAN -e 'install "PatchReader"'
If you want additional HTML tags within product and group descriptions,
you should install:
HTML::Scrubber: /usr/bin/perl -MCPAN -e 'install "HTML::Scrubber"'

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v2.9006
Checking for           MySQL (v4.0.14) ok: found v4.0.24_Debian-10sarge2-log

DBD::mysql::st execute failed: Table 'bugzilla.flags' doesn't exist [for Statement "SHOW INDEX FROM flags"] at /usr/share/perl5/Bugzilla/DB/Mysql.pm line 634
        Bugzilla::DB::Mysql::bz_index_info_real('Bugzilla::DB::Mysql=HASH(0xa075d24)', 'flags', 'flags_bidattid_idx') called at /usr/share/perl5/Bugzilla/DB/Mysql.pm line 297
        Bugzilla::DB::Mysql::bz_setup_database('Bugzilla::DB::Mysql=HASH(0xa075d24)') called at ./checksetup.pl line 1656


Of course when I try to access bugzilla now I get a fully installed version with errors when reading the database structure like this upon login...

DBD::mysql::db selectcol_arrayref failed: Table 'bugzilla.user_group_map' doesn't exist [for Statement "SELECT DISTINCT groups.name, group_id
                                              FROM groups, user_group_map
                                             WHERE groups.id=user_group_map.group_id
                                               AND user_id=?
                                               AND isbless=0"] at /usr/share/perl5/Bugzilla/User.pm line 311
	Bugzilla::User::groups('Bugzilla::User=HASH(0x8bb4180)') called at /usr/share/perl5/Bugzilla/User.pm line 403
	Bugzilla::User::in_group('Bugzilla::User=HASH(0x8bb4180)', 'bz_sudoers') called at /usr/share/bugzilla/Bugzilla.pm line 176
	Bugzilla::login('Bugzilla', 0) called at /usr/lib/cgi-bin/bugzilla/index.cgi line 37

Comment 1

[Pedro Viegas]

I have changed tge severity to Blocker since my bugzilla instalation is DOWN so I have a "No service" situation!

Please help as fast as you can.

Thanks

Comment 2

[Frédéric Buclin]

You have to complain to Debian, not Bugzilla as we don't maintain packages for them.

Comment 3

[Teemu Mannermaa (:wicked)]

While this report is based on Debian package, this might also indicate an upgrade problem in upstream code. Problem is that flags table doesn't exist (it didn't on 2.16) but Bugzilla/DB/Mysql.pm code at line 316 (2.22 branch tip) seems to assume it does. Code does verify bugs table existence but not flags table when it checks their indexes.

CC mkanat so he can take a look. Also, reopening for now so we don't loose this.

Comment 4

[Max Kanat-Alexander]

The code is this:

    if (grep($_ eq 'bugs', @tables)
        && ($self->bz_index_info_real('bugs', 'assigned_to')
            || $self->bz_index_info_real('flags', 'flags_bidattid_idx')) )

  This is failing because he (or somebody) removed the assigned_to index on the bugs table, which has *always* been there (since Bugzilla 2.0, pretty much).

  The workaround is to add back the assigned_to index on the bugs table before running the upgrade. This is a situation that would be rather complex to resolve, and is only created by users modifying their database manually. As such, we won't be fixing it upstream.

Comment 5

[Pedro Viegas]

I urge you to take a look at this as a general bugzilla issue. I have gave detailed explanations as to the reproduce steps in the debian package becausde it's easy to reprocude it that way, but the problem is in the checksetup.pl part, with I belease is a general procedure that debian does not modify.

I have read the explanation that mkanat has gave.
It makes perfect sence, but, I have never changed the database manually.
All I have done is update some values in maintenence tasks, as is, several bug changes in batch processing. Never have I changed someting in the model defintion.

I have looked at the model and I do have an index for the assigned_to field.
It is called "bugs_assigned_to_idx". Isn't this the required index? Was it suposed to have a diferent name and that's why it doesn't find it?

Should I change the name of the index to another?

Please help solving this issue as I beleave it will not be much word required to unlock the default upgrade code but like this I have a dead bugzilla instance that tens of users are currently waiting apon!

Comment 6

[Teemu Mannermaa (:wicked)]

(In reply to comment #5)
> It makes perfect sence, but, I have never changed the database manually.

I wonder if either Debian changed it or this is yet another issue with perl DB modules making up names for indexes. What say you, mkanat?

> It is called "bugs_assigned_to_idx". Isn't this the required index? Was it
> suposed to have a diferent name and that's why it doesn't find it?
> Should I change the name of the index to another?

Try changing name of that index to "assigned_to" and run checksetup again. Hopefully this will allow you to have a working Bugzilla again.

Comment 7

[Pedro Viegas]

Thanks very much Teemu.
It has unlocked the procedure.
I have droped the index with the name "bugs_assigned_to_idx" and created a new clone named "assigned_to".
It worked fine to a point... solving other issues at the moment...

Just to give report that that was the problem.
Although the stangeness continues, it continues, deletes my index and creates a new one again with the name "bugs_assigned_to_idx". Very strange!

Will post the end result... A few more errors to overcome! Related to my data in the tables and how it is trying to takle them...

Thanks again!

Comment 8

[Pedro Viegas]

OK, all solved!
Indeed it was that little details that was blocking the whole procedure.
The rest of my problems were some problems with the fields that previously were maitained in the localconfig file and now are in tables.

Thanks again Teemu for all your help.

Comment 9

[Teemu Mannermaa (:wicked)]

Cool that it works now. We use FIXED resolution only for actual code changes so reverting to WONTFIX per comment #4.

Comment 10

[Max Kanat-Alexander]

FWIW, your index could only be named that if you ran a failed or interrupted upgrade at some point in the past.