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
On Thu, Oct 23, 2014 at 5:52 PM, Sandro Bonazzola <sbonazzo@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!
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
Il 23/10/2014 17:58, Gianluca Cecchi ha scritto:
On Thu, Oct 23, 2014 at 5:52 PM, Sandro Bonazzola <sbonazzo@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!
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
On Fri, Oct 24, 2014 at 8:05 AM, Sandro Bonazzola <sbonazzo@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@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!
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/fedora... enabled=1 skip_if_unavailable=1 gpgcheck=0
Thanks for help, Gianluca
On Thu, Nov 6, 2014 at 7:18 PM, Gianluca Cecchi <gianluca.cecchi@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
Il 09/11/2014 00:00, Gianluca Cecchi ha scritto:
On Thu, Nov 6, 2014 at 7:18 PM, Gianluca Cecchi <gianluca.cecchi@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
On Wed, Nov 12, 2014 at 4:09 PM, Sandro Bonazzola <sbonazzo@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
participants (2)
-
Gianluca Cecchi -
Sandro Bonazzola