Description of problem: When upgrading from 0.3 to 0.4, I have encountered the issue listed in #480618. I have applied the fix (meaning created a new file and put the new code in it) Now, when I want to use the upgrade script again /usr/bin/spacewalk-schema-upgrade, I've got this error message : Unknown schema name [no rows selected] found. And I can't go further. Version-Release number of selected component (if applicable): How reproducible: Installed 0.1 and then upgrade to 0.2 and then 0.3 and try to upgrade to 0.4 Steps to Reproduce: 1. yum upgrade 2. /usr/bin/spacewalk-schema-upgrade 3. Apply fix 4. /usr/bin/spacewalk-schema-upgrade again Actual results: Can't finish the upgrade Expected results: The upgrade script should runs successfully Additional info:
I have check what the upgrade schema does and it seems to try to validate the version info by running a query agains the XE db. I have found that one cause of the issue is that that in the 'rhnVersionInfo' table I have to value for 'schema' in the field LABEL but this: SQL> select label from rhnVersionInfo; LABEL ---------------------------------------------------------------- schema-from schema-from-20081107-161433 schema-from2
I have investigated further and maybe found the issue a a possible fix, still the upgrade script has a bug. The upgrade failed at some point because of the bug #480618. I have applied the fix and re runs the upgrade script which fail with: Unknown schema name [no rows selected] found. I have checked the upgrade script and see that he construct the upgrade path by querying the rhnVersionInfo table which the upgrade script has already updated: LABEL NAME_ID ---------------------------------------------------------------- ---------- EVR_ID CREATED MODIFIED ---------- ------------------ ------------------ schema-from-20081107-161433 2001 3483 07-NOV-08 19-JAN-09 schema-from2 2001 1761 19-SEP-08 07-NOV-08 schema-from 6 5 30-JUL-08 19-SEP-08 So I have tried to delete the rows which have for label 'schema-from-20081107-161433' and re runs the script. This time the it works but the upgrade path is 0.2->0.3->0.4 and I have already upgraded from 0.2 to 0.3. I have then re inserted the row: insert into rhnVersionInfo (label,name_id,evr_id,created,modified) values ('schema','2001','3483','07-NOV-08','19-JAN-09'); And then the script build an upgrade patch correct : 0.3->0.4 This does not comprise the upgrade process itself because the after applying the fix for #480618, you can still follow the upgrade process and it works. It is going to fail for the upgrade from 0.4 to 0.5 since there is no 'schema' value for the label field in rhnVersionInfo if you have not fix by end the issue. Re runs the upgrade script will also leave the rhnVersionInfo with buggy information simply because the script tries to update the table with some information that change the last 'schema' row to a new value and then there are no new row for the new version in the table. So the upgrade script should not update the rhnVersionInfo table unless the upgrade is successfull and you take care of the last 'schema-*' value to upgrade instead of only relying on the 'schema' value.
The point for the setup being this way is: if you do not have any 'schema' record, it means that some of the previous upgrades failed. The upgrade scripts are meant to be run only once, and in given order. If the upgrade fails, the database should be restored from backup, and upgrade retried with fixed set of upgrade scripts. So it is a feature that after failed (and unfixed) upgrade, any other upgrades will fail because they will not find your previous schema version. In your particular case, what failed was the last script in the set, and you can certainly apply the fix from bug 480618 and update the schema version manually. I'm going to close this bugzilla now for the reasons stated above. Please reopen if you disagree.
I am not disagree at all, still there is 2 things that I am concern with: - You says that if an upgrade fail, the user have to restore de database from a backup. Well, first, Spacewalk use Oracle XE and I really don't know how to do a restore for a table or the whole database, and just because of a little issue on a script, I found quite hard to do a restore simply to be ready for the update because of a bug. In my opinion, the upgrade script should not update definitively the table for the schema upgrade until the upgrade is successfull, so even if I apply a patch during the upgrade process, the upgrade script will still now that version or upgrade path it has to manage. Either the script do the update too early in the process or maybe the script should work with a temp value until all is correct. I am pretty sure that it could be acheive easily bu adding the upgrade path column in the version table and/or leave the 'schema' value set and update only when the upgrade is ok (I don't know how the script known it but it could also a field to be added somewhere) - Another point is: right now, I have manage to have 0.4 working, still my version table is incorrect because of the schema value for the label field. Is it possible to write/post here what should be the latest line in the table after the updagrade was successfull? By this way, the next upgrade from 0.4 to 0.5 will be easy. Thanks.
The trouble is, if the upgrade script does not remove the original version right at the beginning, once you execute the first upgrade script, you no longer have the original version. So if the upgrade fails in some of the subsequent scripts, and you re-run spacewalk-schema-upgrade, it will think that you still have the unmodified original version. But some modifications were already done to the schema, so it will most likely fail with some ORA-xxxxx error. If you know that you've fixed the problem and you have 0.4 schema, you can just run insert into rhnVersionInfo ( label, name_id, evr_id, created, modified ) values ('schema', lookup_package_name('spacewalk-schema'), lookup_evr(null, '0.4.18' , '1.el5' ), sysdate, sysdate ); commit; This is what the schema upgrade script would have done as the last step if it did not fail. Please check that you indeed have spacewalk-schema rpm of version spacewalk-schema-0.4.18-1.el5 installed -- that's what in http://spacewalk.redhat.com/yum/0.4/rhel/5Server/i386/ so I assume that's the correct version.