Red Hat Bugzilla – Bug 855887
vdsm: reinstall of host when vdsm repo was updated from 4.9-113.3 to vdsm-4.9.6-32.0 fails on Transaction Check Error
Last modified: 2012-12-04 14:11:14 EST
Created attachment 611437 [details]
Description of problem:
I tried to upgrade my host from vdsm 4.9-113.3 to 4.9.6-32 by reinstalling the host and installation failed with Transaction Check Error.
bootsrap is running on update vdsm instead of update vdsm-* which causes conflicts on vdsm-cli.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a 3.0 cluster -> host should have vdsm-4.9-113.3 + vdsm-client
2. add repo's for vdsm-4.9.6-32
3. put host in maintenance are reinstall the host
we fail on reinstall with conflict on vdsm-client
we should not fail
Additional info: install log
Transaction Check Error:
file /usr/share/vdsm/dumpStorageTable.py from install of vdsm-4.9.6-32.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.3.el6_3.x86_64
file /usr/share/vdsm/dumpStorageTable.pyc from install of vdsm-4.9.6-32.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.3.el6_3.x86_64
file /usr/share/vdsm/dumpStorageTable.pyo from install of vdsm-4.9.6-32.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.3.el6_3.x86_64
after I ran yum update vdsm-* I was able to reinstall the host
This is expected.
libvirt-1.10.1 is a new dependency of vdsm but missing from fedora repository.
What exactly should I do with this one?
We should have asked fedora to add the new libvirt before merging whatever depend on the new version.
but this is about rhel 6?
Dafna - does you host have libvirt-1.10.1 in one of its repo's?
This exact issue happened to be at fedora because of the libvirt dependency.
Sorry for the confusion, vdsm downstream does not required newer libvirt.
I will be happy to reproduce.
no. I'm working with rhel6
but here are my rpm's just in case you need them
[root@localhost ~]# rpm -qa |grep libvirt
[root@localhost ~]# rpm -qa |grep vdsm
Author: Federico Simoncelli <firstname.lastname@example.org>
Date: Tue Feb 14 11:20:51 2012 +0000
Move dumpStorageTable from vdsm_cli to vdsm
The dumpStorageTable.py script is used by the sos plugin shipped with
Reviewed-by: Dan Kenigsberg <email@example.com>
Tested-by: Dan Kenigsberg <firstname.lastname@example.org>
This is actually opposite report of bug#633820 for downstream.
Author: Dan Kenigsberg <email@example.com>
Date: Wed Sep 22 00:57:59 2010 +0200
BZ#633820 - no need to remove vdsm from RHEL-6
(at least until we have a vdsm24 package...)
Author: Alon Bar-Lev <firstname.lastname@example.org>
Date: Tue Sep 18 22:46:17 2012 +0300
bootstrap: use yum API
Use of yum command-line to automate package installation.
Install package almost one by once, so valid status can be reported to
PROBLEMS IN PREVIOUS IMPLEMENTATION
- As each package was installed separately, conflicts could not be
- Dependency list should have been maintained, to match dependencies'
changes over time.
- Alternate packages, or any alternate dependency trees should have
been maintained separately.
- Each execution of yum recalculate the cache, mirrors and
dependencies, this took time.
- If another instance is running, yum waits for ever.
Use the yum python API, use single transaction, only top-level
components, proper logging.
This implementation resolves all the issue of previous implementation.
Also removing the architecture specific package naming.
PROBLEMS IN NEW IMPLEMENTATION
As it turns out, the yum API is not exactly pure API, it needs a lot
more work especially at log interface, as its lazy use of logs and
direct print of messages to stdout/stderr is not something that is
expected from an API.
The new implementation applies workarounds to these issues, for now we
As the vdsm-bootstrap package is to be installed on older engines,
legacy code could not have been removed. The usage of yum from
deployUtils, and the installation functions from the vds_bootstrap.py
could have been removed, ~340 lines of code.
Signed-off-by: Alon Bar-Lev <email@example.com>
Proper (future) fix is tracked at bug#861575.
I'm getting the same conflict on yum update vdsm
we cannot update vdsm without removing vdsm-cli first.
tested with vdsm-4.9-113.4.el6_3.x86_64 ->> vdsm-4.9.6-39.0.el6_3.x86_64
Package Arch Version Repository Size
vdsm x86_64 4.9.6-39.0.el6_3 qa-latest 675 k
Installing for dependencies:
libvirt-lock-sanlock x86_64 0.9.10-21.el6_3.5 qa-latest 125 k
vdsm-python x86_64 4.9.6-39.0.el6_3 qa-latest 84 k
Install 2 Package(s)
Upgrade 1 Package(s)
Total download size: 884 k
Is this ok [y/N]: y
(1/3): libvirt-lock-sanlock-0.9.10-21.el6_3.5.x86_64.rpm | 125 kB 00:00
(2/3): vdsm-4.9.6-39.0.el6_3.x86_64.rpm | 675 kB 00:00
(3/3): vdsm-python-4.9.6-39.0.el6_3.x86_64.rpm | 84 kB 00:00
Total 25 MB/s | 884 kB 00:00
Running Transaction Test
Transaction Check Error:
file /usr/share/vdsm/dumpStorageTable.py from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
file /usr/share/vdsm/dumpStorageTable.pyc from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
file /usr/share/vdsm/dumpStorageTable.pyo from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
Full log please.
BTW: Did you update the vdsm-bootstrap at the engine side? This is what actually runs.
comment#13 is per MANUAL yum invocation.
To upgrade vdsm packages properly use:
# yum update 'vdsm*'
Bootstrap issue was resolved, please verify that one, and close this bug.
Manual yum execution is a totally different discussion.
Please close this one and open a new one for this discussion.
Using yum update manually should assume the user knows what he is doing, or at least read the output and proceed accordingly.
There is no bug in manual yum execution in my opinion, but should be discussed outside of the bootstrap scope.
as you wish.
verified on si22.1
new bug opened as regression for yum update vdsm
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.