[Users] Fedora upgrading from 3.1 to 3.2
Karli Sjöberg
Karli.Sjoberg at slu.se
Wed Jun 26 14:28:21 UTC 2013
Update!
I have actually made some headway, I managed to get it passed the database upgrade! As I was looking at the log, I drilled down into the engine-upgrade script at looked at what it was trying to do, which was a pythonic way of doing:
# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine
So I first reinstalled everything (I´ve stopped counting) and an hour later I was back at just before doing engine-upgrade again. What I did then was to upgrade ovirt-engine-dbscripts first and ran the upgrade.sh script manually (which went by smoothly, output also attached), downgraded all of the ovirt packages back to 3.1.0-4 (because engine-upgrade didn´t think there was any updating to act upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran engine-upgrade. That made it pass the database upgrade, yeay! But! Now it stopped at doing the CA instead... Log is attached.
What I find strange is the last line of output from the upgrade.sh:
...
Refreshing materialized views...
Done.
/usr/share/ovirt-engine/dbscripts
Where the last lines of upgrade.sh are like:
...
run_upgrade_files
ret=$?
printf "Done.\n"
exit $ret
And I looked through run_upgrade_files and couldn´t figure out why that function would exit with "/usr/share/ovirt-engine/dbscripts"? No that doesn´t quite add up. Something just doesn´t smell right but I haven´t figured it out what it is yet,
About the second error, with handling the CA, it seems like it´s having trouble connecting to the database after it´s upgrade, but since the upgrade itself went by OK, I did engine-cleanup, engine-setup, stopped engine, restored the database and started engine again, and it worked. Which should point more to something like a configuration being missed, or improperly handled at the upgrade that makes engine-config fail to connect. Maybe some old configurations lying around that shouldn´t be, that hinders it, I don´t know. Is there anything handling configuration changes, like "rpmconf -a" in the upgrade process, after updating the rpms?
/Karli
ons 2013-06-26 klockan 13:33 +0000 skrev Karli Sjöberg:
tis 2013-06-25 klockan 16:02 +0003 skrev Alex Lourie:
On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg <Karli.Sjoberg at slu.se<mailto:Karli.Sjoberg at slu.se>>
wrote:
> tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi: On Tue,
> Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:
>
>>>
>>>
> Yes, I had much better success following that article, and managed
> to upgrade fedora to 18, had to tune my kernel parameters a little
> for the postgres upgrade to work, but then engine-upgrade fails just
> as it did the last time we tried. The log is attached. Hoping to hear
> back from you soon with ideas on what to try next.
>
>>>
>>>
>>>
>
>>
>>
> But now the error seems different from the original one in March
> (if I remember correctly the original post).
>>
>
> They are quite the same:
>
> Then
> psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> uuid_nil() because extension uuid-ossp requires it
>
> Now
> 2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr =
> psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> uuid_nil() because extension uuid-ossp requires it
>
>> Could it be somehow related with this rhev one bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=923614
>>
>>
> and that changing permissions for the impacted objects in db before
> running upgrade could help?
I have now tried that and it did no change in success there unfortunately, so it´s probably not anything permissions related in the database.
dbmodify:
#!/bin/sh
export PGPASSFILE=/root/.pgpass
for tbl in `psql -U postgres -wqAt -c "select tablename from pg_tables where schemaname = 'public';" engine` ; do psql -U postgres -c "alter table $tbl owner to engine" engine ; done
for tbl in `psql -U postgres -wqAt -c "select sequence_name from information_schema.sequences where sequence_schema = 'public';" engine`; do psql -U postgres -c "alter table $tbl owner to engine" engine ; done
for tbl in `psql -U postgres -wqAt -c "select table_name from information_schema.views where table_schema = 'public';" engine` ; do psql -U postgres -c "alter table $tbl owner to engine" engine ; done
# yum update -y ovirt-engine-setup
# ./dbmodify
# engine-upgrade
fail
Log is attached this time as well, it bombs out at the exact same place, in the same way.
/K
>>
>
> Very interesting, thanks for the hint! That is definitely worth
> trying out. Will try that first thing tomorrow:)
Hi Karli
If it helps, let me know - I will add a troubleshooting section to the
wiki.
>
>
>>
>>
>>
> BTW: is your environment directly created in 3.1 or did it come
> from a further upgrade?
>>
>
> Started with a minimal Fedora 17 install, added the oVirt-3.1 repo,
> ran yum upgrade -y first, then yum install -y ovirt-engine and lastly
> engine-setup. Nothing more. So it´s just an empty engine that I´m
> trying to upgrade at this point. When that works, I´ll add hosts,
> VMs, Templates, etc.
>
>>
>>
>>
> HIH,
> Gianluca
>
> --
>
> Med Vänliga Hälsningar
> -------------------------------------------------------------------------------
> Karli Sjöberg
> Swedish University of Agricultural Sciences
> Box 7079 (Visiting Address Kronåsvägen 8)
> S-750 07 Uppsala, Sweden
> Phone: +46-(0)18-67 15 66
> karli.sjoberg at slu.se<mailto:karli.sjoberg at slu.se>
--
Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg at slu.se<mailto:karli.sjoberg at adm.slu.se>
--
Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg at slu.se<mailto:karli.sjoberg at adm.slu.se>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130626/bb8f7017/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: db_upgrade.out
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130626/bb8f7017/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt-engine-upgrade_2013_06_26_13_37_54.log
Type: text/x-log
Size: 139240 bytes
Desc: ovirt-engine-upgrade_2013_06_26_13_37_54.log
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130626/bb8f7017/attachment-0001.bin>
More information about the Users
mailing list