10:52 a.m.
Hi,
just finished testing migration path from F19 to F20 for systems running oVirt.
F19 is going EOL one month after F21 release which is currently planned for December 2nd.
If you're running oVirt on Fedora 19 I suggest you to do it once finished to upgrade
oVirt to 3.5.0.
I've saved some notes in the test request bug[1]:
Bug 1131828 - Test upgrade path from Fedora 19 with oVirt 3.5.z to Fedora 20
Enjoy!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1131828
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10:58 a.m.
On Thu, Oct 23, 2014 at 5:52 PM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
Hi,
just finished testing migration path from F19 to F20 for systems running
oVirt.
F19 is going EOL one month after F21 release which is currently planned
for December 2nd.
If you're running oVirt on Fedora 19 I suggest you to do it once finished
to upgrade oVirt to 3.5.0.
I've saved some notes in the test request bug[1]:
Bug 1131828 - Test upgrade path from Fedora 19 with oVirt 3.5.z to Fedora
20
Enjoy!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1131828
NIce to hear this.
I'm going to do it and give feedback on one of my personal workstations
that is currently on F19 with all-in-one 3.4.4 due to this.
Do you think the workflow is ok also for an all-in-one environment?
Gianluca
1:05 a.m.
Il 23/10/2014 17:58, Gianluca Cecchi ha scritto:
On Thu, Oct 23, 2014 at 5:52 PM, Sandro Bonazzola
<sbonazzo(a)redhat.com>
wrote:
> Hi,
> just finished testing migration path from F19 to F20 for systems running
> oVirt.
> F19 is going EOL one month after F21 release which is currently planned
> for December 2nd.
>
> If you're running oVirt on Fedora 19 I suggest you to do it once finished
> to upgrade oVirt to 3.5.0.
> I've saved some notes in the test request bug[1]:
> Bug 1131828 - Test upgrade path from Fedora 19 with oVirt 3.5.z to Fedora
> 20
>
> Enjoy!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1131828
>
>
NIce to hear this.
I'm going to do it and give feedback on one of my personal workstations
that is currently on F19 with all-in-one 3.4.4 due to this.
Do you think the workflow is ok also for an all-in-one environment?
I've not tested all-in-one upgrade, just to be sure, save current iptables config and
do a backup before starting the upgrade.
Gianluca
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
12:18 p.m.
On Fri, Oct 24, 2014 at 8:05 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
Il 23/10/2014 17:58, Gianluca Cecchi ha scritto:
> On Thu, Oct 23, 2014 at 5:52 PM, Sandro Bonazzola <sbonazzo(a)redhat.com>
> wrote:
>
>> Hi,
>> just finished testing migration path from F19 to F20 for systems running
>> oVirt.
>> F19 is going EOL one month after F21 release which is currently planned
>> for December 2nd.
>>
>> If you're running oVirt on Fedora 19 I suggest you to do it once
finished
>> to upgrade oVirt to 3.5.0.
>> I've saved some notes in the test request bug[1]:
>> Bug 1131828 - Test upgrade path from Fedora 19 with oVirt 3.5.z to
Fedora
>> 20
>>
>> Enjoy!
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1131828
>>
>>
> NIce to hear this.
> I'm going to do it and give feedback on one of my personal workstations
> that is currently on F19 with all-in-one 3.4.4 due to this.
> Do you think the workflow is ok also for an all-in-one environment?
I've not tested all-in-one upgrade, just to be sure, save current iptables
config and do a backup before starting the upgrade.
>
> Gianluca
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
trying to proceed with migration to f20.
yum update gives nothing:
[root@tekkaman sysconfig]# yum update
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock
Loading mirror speeds from cached hostfile
* fedora: ftp-stud.hs-esslingen.de
* livna: rpm.livna.org
* ovirt-3.4-stable: ftp.snt.utwente.nl
* ovirt-3.5: ftp.snt.utwente.nl
* rpmfusion-free: mirror.de.leaseweb.net
* rpmfusion-free-updates: mirror.de.leaseweb.net
* rpmfusion-nonfree: mirror.de.leaseweb.net
* rpmfusion-nonfree-updates: mirror.de.leaseweb.net
* updates: ftp-stud.hs-esslingen.de
No packages marked for update
But I get this with "yum distro-sync"
what does it mean?
[root@tekkaman sysconfig]# yum distro-sync
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock
Dropbox
| 951 B 00:00:00
adobe-linux-x86_64
| 951 B 00:00:00
google-chrome
| 951 B 00:00:00
livna
| 1.3 kB 00:00:00
ovirt-3.4-fedora-virt-preview
| 2.9 kB 00:00:00
ovirt-3.4-stable
| 2.9 kB 00:00:00
ovirt-3.5
| 2.9 kB 00:00:00
ovirt-3.5-fedora-virt-preview
| 2.9 kB 00:00:00
ovirt-3.5-patternfly1
| 3.0 kB 00:00:00
rpmfusion-free-updates
| 3.3 kB 00:00:00
rpmfusion-nonfree-updates
| 3.3 kB 00:00:00
updates/19/x86_64/metalink
| 28 kB 00:00:00
Loading mirror speeds from cached hostfile
* fedora: ftp-stud.hs-esslingen.de
* livna: rpm.livna.org
* ovirt-3.4-stable: ftp.snt.utwente.nl
* ovirt-3.5: ftp.snt.utwente.nl
* rpmfusion-free: mirror.de.leaseweb.net
* rpmfusion-free-updates: mirror.de.leaseweb.net
* rpmfusion-nonfree: mirror.de.leaseweb.net
* rpmfusion-nonfree-updates: mirror.de.leaseweb.net
* updates: ftp-stud.hs-esslingen.de
Resolving Dependencies
--> Running transaction check
---> Package SLOF.noarch 0:0.1.git20121018-1.fc19 will be a downgrade
---> Package SLOF.noarch 0:0.1.git20130430-2.fc19 will be erased
---> Package ipxe-roms-qemu.noarch 0:20130517-2.gitc4bce43.fc19 will be a
downgrade
---> Package ipxe-roms-qemu.noarch 0:20130517-3.gitc4bce43.fc19 will be
erased
---> Package libcacard.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package libcacard.x86_64 2:1.6.1-2.fc19 will be erased
---> Package openbios.noarch 0:1.0.svn1063-2.fc19 will be a downgrade
---> Package openbios.noarch 0:1.1.svn1198-2.fc19 will be erased
---> Package qemu.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-common.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-common.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-img.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-img.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-kvm.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-kvm.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-alpha.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-alpha.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-arm.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-arm.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-cris.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-cris.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-lm32.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-lm32.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-m68k.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-m68k.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-microblaze.x86_64 2:1.4.2-15.fc19 will be a
downgrade
---> Package qemu-system-microblaze.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-mips.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-mips.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-or32.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-or32.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-ppc.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-ppc.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-s390x.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-s390x.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-sh4.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-sh4.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-sparc.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-sparc.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-unicore32.x86_64 2:1.4.2-15.fc19 will be a
downgrade
---> Package qemu-system-unicore32.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-x86.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-x86.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-system-xtensa.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-system-xtensa.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-user.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-user.x86_64 2:1.6.1-2.fc19 will be erased
---> Package seabios-bin.noarch 0:1.7.2.2-3.fc19 will be a downgrade
---> Package seabios-bin.noarch 0:1.7.3.1-1.fc19 will be erased
---> Package seavgabios-bin.noarch 0:1.7.2.2-3.fc19 will be a downgrade
---> Package seavgabios-bin.noarch 0:1.7.3.1-1.fc19 will be erased
---> Package sgabios-bin.noarch 1:0.20110622svn-5.fc19 will be a downgrade
---> Package sgabios-bin.noarch 1:0.20110622svn-6.fc19 will be erased
---> Package virt-install.noarch 0:0.10.0-5.fc19 will be a downgrade
---> Package virt-install.noarch 0:0.10.0-5.git1ffcc0cc.fc19 will be erased
---> Package virt-manager-common.noarch 0:0.10.0-5.fc19 will be a downgrade
---> Package virt-manager-common.noarch 0:0.10.0-5.git1ffcc0cc.fc19 will be
erased
--> Finished Dependency Resolution
Error: Package: 2:qemu-system-moxie-1.6.1-2.fc19.x86_64
(@fedora-virt-preview)
Requires: qemu-common = 2:1.6.1-2.fc19
Removing: 2:qemu-common-1.6.1-2.fc19.x86_64
(@fedora-virt-preview)
qemu-common = 2:1.6.1-2.fc19
Downgraded By: 2:qemu-common-1.4.2-15.fc19.x86_64 (updates)
qemu-common = 2:1.4.2-15.fc19
Available: 2:qemu-common-1.4.2-3.fc19.x86_64 (fedora)
qemu-common = 2:1.4.2-3.fc19
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
my repos config;
[root@tekkaman sysconfig]# ls -1 /etc/yum.repos.d/*repo
/etc/yum.repos.d/adobe-linux-x86_64.repo
/etc/yum.repos.d/dropbox.repo
/etc/yum.repos.d/fedora.repo
/etc/yum.repos.d/fedora-updates.repo
/etc/yum.repos.d/fedora-updates-testing.repo
/etc/yum.repos.d/google-chrome.repo
/etc/yum.repos.d/livna.repo
/etc/yum.repos.d/ovirt-3.4-dependencies.repo
/etc/yum.repos.d/ovirt-3.4.repo
/etc/yum.repos.d/ovirt-3.5-dependencies.repo
/etc/yum.repos.d/ovirt-3.5.repo
/etc/yum.repos.d/rpmfusion-free-rawhide.repo
/etc/yum.repos.d/rpmfusion-free.repo
/etc/yum.repos.d/rpmfusion-free-updates.repo
/etc/yum.repos.d/rpmfusion-free-updates-testing.repo
/etc/yum.repos.d/rpmfusion-nonfree-rawhide.repo
/etc/yum.repos.d/rpmfusion-nonfree.repo
/etc/yum.repos.d/rpmfusion-nonfree-updates.repo
/etc/yum.repos.d/rpmfusion-nonfree-updates-testing.repo
In the past when this system was with oVirt 3.x and x <3 I think I had
virt-preview enabled, but now I have only
/etc/yum.repos.d/fedora-virt-preview.repo.rpmsave
because virt-preview is in
/etc/yum.repos.d/ovirt-3.4-dependencies.repo
/etc/yum.repos.d/ovirt-3.5-dependencies.repo
[root@tekkaman sysconfig]# diff
/etc/yum.repos.d/ovirt-3.4-dependencies.repo
/etc/yum.repos.d/ovirt-3.5-dependencies.repo1c1
< [ovirt-3.4-fedora-virt-preview]
---
[ovirt-3.5-fedora-virt-preview]
7a8,15
[ovirt-3.5-patternfly1]
name=Copr repo for patternfly1 owned by patternfly
baseurl=
http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/fed...
enabled=1
skip_if_unavailable=1
gpgcheck=0
Thanks for help,
Gianluca
5 p.m.
On Thu, Nov 6, 2014 at 7:18 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
> I've not tested all-in-one upgrade, just to be sure, save current
> iptables config and do a backup before starting the upgrade.
>
>
>
> >
> > Gianluca
> >
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
trying to proceed with migration to f20.
[snip]
But I get this with "yum distro-sync"
what does it mean?
[root@tekkaman sysconfig]# yum distro-sync
[snip]
--> Running transaction check
---> Package SLOF.noarch 0:0.1.git20121018-1.fc19 will be a downgrade
---> Package SLOF.noarch 0:0.1.git20130430-2.fc19 will be erased
---> Package ipxe-roms-qemu.noarch 0:20130517-2.gitc4bce43.fc19 will be a
downgrade
---> Package ipxe-roms-qemu.noarch 0:20130517-3.gitc4bce43.fc19 will be
erased
---> Package libcacard.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package libcacard.x86_64 2:1.6.1-2.fc19 will be erased
---> Package openbios.noarch 0:1.0.svn1063-2.fc19 will be a downgrade
---> Package openbios.noarch 0:1.1.svn1198-2.fc19 will be erased
---> Package qemu.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-common.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-common.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-img.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-img.x86_64 2:1.6.1-2.fc19 will be erased
---> Package qemu-kvm.x86_64 2:1.4.2-15.fc19 will be a downgrade
---> Package qemu-kvm.x86_64 2:1.6.1-2.fc19 will be erased
In practice the problem is due to the fact that it is an all-in-one
installation and so it pulled in the virt-preview part for vdsm and related
packages (qemu-kvm, seabioes, etc..).
How much is it risky to bypass the "yum distro-sync" step? Will the fedup
part run itself the distro-sync command then, or is it only a sort of
pre-check to verify consistency of packages?
In my case if fedup will retain the ovirt repos all should go ok, correct?
Gianluca
9:09 a.m.
Il 09/11/2014 00:00, Gianluca Cecchi ha scritto:
On Thu, Nov 6, 2014 at 7:18 PM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com>
wrote:
>
>
>> I've not tested all-in-one upgrade, just to be sure, save current
>> iptables config and do a backup before starting the upgrade.
>>
>>
>>
>>>
>>> Gianluca
>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>
>
>
> trying to proceed with migration to f20.
>
>
[snip]
> But I get this with "yum distro-sync"
>
> what does it mean?
>
> [root@tekkaman sysconfig]# yum distro-sync
>
> [snip]
> --> Running transaction check
> ---> Package SLOF.noarch 0:0.1.git20121018-1.fc19 will be a downgrade
> ---> Package SLOF.noarch 0:0.1.git20130430-2.fc19 will be erased
> ---> Package ipxe-roms-qemu.noarch 0:20130517-2.gitc4bce43.fc19 will be a
> downgrade
> ---> Package ipxe-roms-qemu.noarch 0:20130517-3.gitc4bce43.fc19 will be
> erased
> ---> Package libcacard.x86_64 2:1.4.2-15.fc19 will be a downgrade
> ---> Package libcacard.x86_64 2:1.6.1-2.fc19 will be erased
> ---> Package openbios.noarch 0:1.0.svn1063-2.fc19 will be a downgrade
> ---> Package openbios.noarch 0:1.1.svn1198-2.fc19 will be erased
> ---> Package qemu.x86_64 2:1.4.2-15.fc19 will be a downgrade
> ---> Package qemu.x86_64 2:1.6.1-2.fc19 will be erased
> ---> Package qemu-common.x86_64 2:1.4.2-15.fc19 will be a downgrade
> ---> Package qemu-common.x86_64 2:1.6.1-2.fc19 will be erased
> ---> Package qemu-img.x86_64 2:1.4.2-15.fc19 will be a downgrade
> ---> Package qemu-img.x86_64 2:1.6.1-2.fc19 will be erased
> ---> Package qemu-kvm.x86_64 2:1.4.2-15.fc19 will be a downgrade
> ---> Package qemu-kvm.x86_64 2:1.6.1-2.fc19 will be erased
>
In practice the problem is due to the fact that it is an all-in-one
installation and so it pulled in the virt-preview part for vdsm and related
packages (qemu-kvm, seabioes, etc..).
How much is it risky to bypass the "yum distro-sync" step? Will the fedup
part run itself the distro-sync command then, or is it only a sort of
pre-check to verify consistency of packages?
In my case if fedup will retain the ovirt repos all should go ok, correct?
I think it should go ok.
Gianluca
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
5:11 p.m.
On Wed, Nov 12, 2014 at 4:09 PM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
I think it should go ok.
>
> Gianluca
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
OK, all went ok.
The only problem I had was PostgreSQL upgrade that didn't succeed.
I used the newly released postgresql-upgrade-9.3.5-2.fc20.x86_64 and not
the version referred inside the bugzilla entry.
I don't know if it was part of the problem.
[root@tekkaman Downloads]# postgresql-setup upgrade
Upgrading database: failed
See /var/lib/pgsql/pgupgrade.log for details.
[root@tekkaman data]# cat /var/lib/pgsql/pgupgrade.log
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.
connection to database failed: could not connect to server: No such file or
directory
Is the server running locally and accepting
connections on Unix domain socket "/var/lib/pgsql/.s.PGSQL.5432"?
could not connect to old postmaster started with the command:
"/usr/lib64/pgsql/postgresql-9.2/bin/pg_ctl" -w -l
"pg_upgrade_server.log"
-D "/var/lib/pgsql/data-old" -o "-p 5432 -b -c listen_addresses=''
-c
unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'"
start
Failure, exiting
Digging more in log files I saw:
-----------------------------------------------------------------
pg_upgrade run on Thu Nov 13 00:18:11 2014
-----------------------------------------------------------------
command: "/usr/lib64/pgsql/postgresql-9.2/bin/pg_ctl" -w -l
"pg_upgrade_server.log" -D "/var/lib/pgsql/data-old" -o "-p 5432
-b -c listen_addresses='' -c unix_socket_permissions=0700 -c
unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_se
rver.log" 2>&1
waiting for server to start....LOG: SSL is not supported by this build
LOG: SSL is not supported by this build
LOG: SSL is not supported by this build
FATAL: configuration file "/var/lib/pgsql/data-old/postgresql.conf"
contains errors
.... stopped waiting
pg_ctl: could not start server
Examine the log output.
After removing from postgresql.conf the line
ssl = on
I was then able to upgrade PostgreSQL and continue with the other steps.
The Hypervisor part was fulfilled by the os upgrade itself.
BTW: in f19 I had iptables and not firewalld and this kind of configuration
was kept in f20 too by the installer.
Gianluca
3689
days inactive
3713
days old
6 comments
2 participants
participants (2)
-
Gianluca Cecchi -
Sandro Bonazzola