<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="GENERATOR" content="GtkHTML/4.4.4">
</head>
<body>
Update!<br>
<br>
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:<br>
# cd /usr/share/ovirt-engine/dbscripts<br>
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine<br>
<br>
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.<br>
<br>
What I find strange is the last line of output from the upgrade.sh:<br>
...<br>
Refreshing materialized views...<br>
Done.<br>
<b>/usr/share/ovirt-engine/dbscripts</b><br>
<br>
Where the last lines of upgrade.sh are like:<br>
...<br>
run_upgrade_files<br>
<br>
ret=$?<br>
printf &quot;Done.\n&quot;<br>
exit $ret<br>
<br>
And I looked through run_upgrade_files and couldn´t figure out why that function would exit with &quot;/usr/share/ovirt-engine/dbscripts&quot;? No that doesn´t quite add up. Something just doesn´t smell right but I haven´t figured it out what it is yet,<br>
<br>
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 &quot;rpmconf -a&quot; in the upgrade process, after updating the rpms?<br>
<br>
/Karli<br>
<br>
ons 2013-06-26 klockan 13:33 &#43;0000 skrev Karli Sjöberg:<br>
<blockquote type="CITE">tis 2013-06-25 klockan 16:02 &#43;0003 skrev Alex Lourie:
<blockquote type="CITE">
<pre>

On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg &lt;<a href="mailto:Karli.Sjoberg@slu.se">Karli.Sjoberg@slu.se</a>&gt; 
wrote:
&gt; tis 2013-06-25 klockan 15:35 &#43;0200 skrev Gianluca Cecchi: &#127;On Tue, 
&gt; Jun 25, 2013 at 2:58 PM, Karli Sjöberg&nbsp;wrote:
&gt;  &#127;&#127;
&gt;&gt;&gt; 
&gt;&gt;&gt; 
&gt;  &#127;&#127;Yes, I had much better success following that article, and managed 
&gt; to upgrade fedora to 18, had to tune my kernel parameters a little 
&gt; for the postgres upgrade to work, but then engine-upgrade fails just 
&gt; as it did the last time we tried. The log is attached. Hoping to hear 
&gt; back from you soon with ideas on what to try next.
&gt;  &#127;&#127;
&gt;&gt;&gt; 
&gt;&gt;&gt; 
&gt;&gt;&gt; 
&gt;  &#127;
&gt;&gt; 
&gt;&gt; 
&gt;  &#127;But now the error seems different from the original one in March 
&gt; (if I remember correctly the original post).
&gt;&gt; 
&gt;  
&gt; They are quite the same:
&gt; 
&gt; Then
&gt; psql:drop_old_uuid_functions.sql:25: ERROR:&nbsp; cannot drop function 
&gt; uuid_nil() because extension uuid-ossp requires it
&gt; 
&gt; Now
&gt; 2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
&gt; psql:drop_old_uuid_functions.sql:25: ERROR:&nbsp; cannot drop function 
&gt; uuid_nil() because extension uuid-ossp requires it
&gt; 
&gt;&gt; Could it be somehow related with this rhev one bug:
&gt;  &#127;<a href="https://bugzilla.redhat.com/show_bug.cgi?id=923614">https://bugzilla.redhat.com/show_bug.cgi?id=923614</a>
&gt;&gt; 
&gt;&gt; 
&gt;  &#127;and that changing permissions for the impacted objects in db before 
&gt; running upgrade could help?
</pre>
</blockquote>
<br>
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.<br>
<br>
dbmodify:<br>
#!/bin/sh<br>
export PGPASSFILE=/root/.pgpass
<pre>
for tbl in `psql -U postgres -wqAt -c &quot;select tablename from pg_tables where schemaname = 'public';&quot; engine` ; do  psql -U postgres -c &quot;alter table $tbl owner to engine&quot; engine ; done
for tbl in `psql -U postgres -wqAt -c &quot;select sequence_name from information_schema.sequences where sequence_schema = 'public';&quot; engine`; do  psql -U postgres -c &quot;alter table $tbl owner to engine&quot; engine ; done
for tbl in `psql -U postgres -wqAt -c &quot;select table_name from information_schema.views where table_schema = 'public';&quot; engine` ; do psql -U postgres -c &quot;alter table $tbl owner to engine&quot; 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

</pre>
<blockquote type="CITE">
<pre>
&gt;&gt; 
&gt;  
&gt; Very interesting, thanks for the hint! That is definitely worth 
&gt; 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.

&gt; 
&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;  &#127;BTW: is your environment directly created in 3.1 or did it come 
&gt; from a further upgrade? 
&gt;&gt; 
&gt;  
&gt; Started with a minimal Fedora 17 install, added the oVirt-3.1 repo, 
&gt; ran yum upgrade -y first, then yum install -y ovirt-engine and lastly 
&gt; engine-setup. Nothing more. So it´s just an empty engine that I´m 
&gt; trying to upgrade at this point. When that works, I´ll add hosts, 
&gt; VMs, Templates, etc.
&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;  &#127;HIH,
&gt;  &#127;Gianluca
&gt;  
&gt; -- 
&gt; 
&gt; Med Vänliga Hälsningar
&gt; -------------------------------------------------------------------------------
&gt; Karli Sjöberg
&gt; Swedish University of Agricultural Sciences
&gt; Box 7079 (Visiting Address Kronåsvägen 8)
&gt; S-750 07 Uppsala, Sweden
&gt; Phone: &nbsp;&#43;46-(0)18-67 15 66
&gt; <a href="mailto:karli.sjoberg@slu.se">karli.sjoberg@slu.se</a>

</pre>
</blockquote>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: &nbsp;&#43;46-(0)18-67 15 66<br>
<a href="mailto:karli.sjoberg@adm.slu.se">karli.sjoberg@slu.se</a> </td>
</tr>
</tbody>
</table>
</blockquote>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: &nbsp;&#43;46-(0)18-67 15 66<br>
<a href="mailto:karli.sjoberg@adm.slu.se">karli.sjoberg@slu.se</a> </td>
</tr>
</tbody>
</table>
</body>
</html>