Bug 752859 - Bugzilla setup broken after upgrade to Fedora 16
Summary: Bugzilla setup broken after upgrade to Fedora 16
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: bugzilla
Version: 16
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Emmanuel Seyman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-10 15:55 UTC by Nadav Har'El
Modified: 2012-01-08 19:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-08 15:58:59 UTC
Type: ---


Attachments (Terms of Use)

Description Nadav Har'El 2011-11-10 15:55:35 UTC
I just upgraded a working Bugzilla setup from Fedora 15 to Fedora 16 (using "preupgrade"), and it broke the setup: When I go its page, and for example try a search, I get:

    Software error:

    Table profile_search does not exist in the database schema. at Bugzilla/DB/Schema.pm line 1936.

    For help, please send mail to the webmaster (root@localhost), giving this error message and the time and date of the error. 

Running /usr/share/bugzilla/checksetup.pl once did not help - it didn't do anything, apparently, perhaps because it want to tell me of a new variable in the configuration, site_wide_secret (!?). But amazingly, running it *for the second time* did help, and now it restructured the tables as necessary, and Bugzilla started to work perfectly.

Why wasn't checksetup.pl properly run (or even twice??) on upgrade?

Another thing I should add is that because of a separate bug 752846, mysqld did not start after the upgrade. Does this perhaps explain why checksetup.pl didn't work? Is there any log I can look to see checksetup.pl errors? /root/upgrade.log doesn't contain anything relevant.

Thanks.

Comment 1 Emmanuel Seyman 2011-11-22 16:53:58 UTC
(In reply to comment #0)
>
> Running /usr/share/bugzilla/checksetup.pl once did not help - it didn't do
> anything, apparently, perhaps because it want to tell me of a new variable in
> the configuration, site_wide_secret (!?). But amazingly, running it *for the
> second time* did help, and now it restructured the tables as necessary, and
> Bugzilla started to work perfectly.

checksetup is actually a two-step program and I'm guessing the second step isn't run if the first step doesn't run without errors or wanings. Because it added a parameter to /etc/bugzilla/localconfig (site_wide_secret), it decided not to upgrade your database without giving you the time to review the changes.

> Why wasn't checksetup.pl properly run (or even twice??) on upgrade?

The only time checksetup.pl is run is when /etc/bugzilla/localconfig does not exist. The rest of the time, we assume the datebase exists and, because we have no idea if it has been backed up or not, we defer to not running checksetup.pl .

> Another thing I should add is that because of a separate bug 752846, mysqld did
> not start after the upgrade. Does this perhaps explain why checksetup.pl didn't
> work? Is there any log I can look to see checksetup.pl errors?
> /root/upgrade.log doesn't contain anything relevant.

No, checksetup.pl doesn't log anywhere.

Comment 2 Emmanuel Seyman 2012-01-08 15:58:59 UTC
I don't think there's anything to do here.

Comment 3 Nadav Har'El 2012-01-08 17:28:48 UTC
It sounds to me, from your previous comment, that you know that Bugzilla WILL NOT WORK after the upgrade, but prefer that the user run "checksetup.pl" on his own. But how is the user supposed to know that he should do that? He thinks bugzilla is running after the upgrade, but only when he tries an actual transaction or search, does he see all these database errors. None of the database error messages suggest that running "checksetup.pl" is the appropriate thing to do.

I'm not sure what is the appropriate way to fix this. I thought the right way is to run checksetup.pl, but if you consider this dangerous, perhaps at least notifying the user of the problem somehow (I'm not sure how) is the key. But I do think that this issue needs to be solved - when an upgrade breaks some of the services running on a machine, it is definitely a problem.

Comment 4 Emmanuel Seyman 2012-01-08 19:32:42 UTC
(In reply to comment #3)
> It sounds to me, from your previous comment, that you know that Bugzilla WILL
> NOT WORK after the upgrade

There's really no way to know. This depends on the contents of your database, the version you're upgrading from and the version you're upgrading to.

> NOT WORK after the upgrade, but prefer that the user run "checksetup.pl" on his
> own. But how is the user supposed to know that he should do that? He thinks
> bugzilla is running after the upgrade, but only when he tries an actual
> transaction or search, does he see all these database errors. None of the
> database error messages suggest that running "checksetup.pl" is the appropriate
> thing to do.

In cases like this, I recommend reading the "How to upgrade" part of the documentation of the Bugzilla version you're upgrading to.

http://www.bugzilla.org/docs/4.0/en/html/upgrade.html (for the 4.0 branch)

These clearly state to run checksetup.pl once the upgrade is done.


Note You need to log in before you can comment on or make changes to this bug.