On trying a yum update I get the following error:
Error: kernel conflicts with bfa-firmware
yum suggests I work around the problem with --skip-broken or try running 'rpm -Va --nofiles --nodigest'
Is there an accepted process for resolving this?
On 03/11/2013 05:21 AM, Giles Coochey wrote:
On trying a yum update I get the following error:
Error: kernel conflicts with bfa-firmware
yum suggests I work around the problem with --skip-broken or try running 'rpm -Va --nofiles --nodigest'
Is there an accepted process for resolving this?
Can you post the kernel versions and bfa-firmware versions that are trying to up upgraded ... and whether you have the i386 or x86_64 version installed?
Also, what are you upgrading from?
We have not seen this specific issue in our QA testing.
On 11/03/2013 12:50, Johnny Hughes wrote:
On 03/11/2013 05:21 AM, Giles Coochey wrote:
On trying a yum update I get the following error:
Error: kernel conflicts with bfa-firmware
yum suggests I work around the problem with --skip-broken or try running 'rpm -Va --nofiles --nodigest'
Is there an accepted process for resolving this?
Can you post the kernel versions and bfa-firmware versions that are trying to up upgraded ... and whether you have the i386 or x86_64 version installed?
Also, what are you upgrading from?
We have not seen this specific issue in our QA testing.
I am on Centos 6.3, but I'm assuming that 'yum update' is trying to get me to Centos 6.4
This is x86_64, current kernel is 2.6.32-279.22.1.el6.x86_64
[root@repo ~]# yum info bfa-firmware Loaded plugins: fastestmirror, presto, security Loading mirror speeds from cached hostfile Installed Packages Name : bfa-firmware Arch : noarch Version : 3.0.0.0 Release : 1.el6 Size : 1.3 M Repo : installed From repo : anaconda-CentOS-201112091719.x86_64 Summary : Brocade Fibre Channel HBA Firmware URL : http://www.brocade.com/sites/dotcom/services-support/drivers-downloads/CNA/L... License : Redistributable, no modification permitted Description : Brocade Fibre Channel HBA Firmware.
Hi Johnny,
Can you post the kernel versions and bfa-firmware versions that are trying to up upgraded ... and whether you have the i386 or x86_64 version installed?
I'm getting exactly the same error when I try to update using the 'updates' repo only:
[root@orcus7 ~]# yum update --disablerepo=* --enablerepo=updates Loaded plugins: downloadonly updates | 3.5 kB 00:00 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package bind-libs.x86_64 32:9.8.2-0.10.rc1.el6_3.6 will be updated ---> Package bind-libs.x86_64 32:9.8.2-0.17.rc1.el6.3 will be an update ---> Package bind-utils.x86_64 32:9.8.2-0.10.rc1.el6_3.6 will be updated ---> Package bind-utils.x86_64 32:9.8.2-0.17.rc1.el6.3 will be an update ---> Package cups.x86_64 1:1.4.2-48.el6_3.3 will be updated ---> Package cups.x86_64 1:1.4.2-50.el6_4.4 will be an update ---> Package cups-libs.x86_64 1:1.4.2-48.el6_3.3 will be updated ---> Package cups-libs.x86_64 1:1.4.2-50.el6_4.4 will be an update --> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2)(64bit) for package: 1:cups-libs-1.4.2-50.el6_4.4.x86_64 ---> Package dbus-glib.x86_64 0:0.86-5.el6 will be updated ---> Package dbus-glib.x86_64 0:0.86-6.el6 will be an update ---> Package gnutls.x86_64 0:2.8.5-4.el6_2.2 will be updated ---> Package gnutls.x86_64 0:2.8.5-10.el6_4.1 will be an update ---> Package kernel.x86_64 0:2.6.32-358.0.1.el6 will be installed ---> Package kernel-firmware.noarch 0:2.6.32-279.22.1.el6 will be updated ---> Package kernel-firmware.noarch 0:2.6.32-358.0.1.el6 will be an update ---> Package libcgroup.x86_64 0:0.37-4.el6 will be updated ---> Package libcgroup.x86_64 0:0.37-7.1.el6 will be an update ---> Package libxml2.x86_64 0:2.7.6-8.el6_3.4 will be updated ---> Package libxml2.x86_64 0:2.7.6-12.el6_4.1 will be an update ---> Package openldap.x86_64 0:2.4.23-26.el6_3.2 will be updated ---> Package openldap.x86_64 0:2.4.23-32.el6_4 will be an update ---> Package openssl.x86_64 0:1.0.0-25.el6_3.1 will be updated ---> Package openssl.x86_64 0:1.0.0-27.el6_4.2 will be an update ---> Package selinux-policy.noarch 0:3.7.19-155.el6_3.14 will be updated ---> Package selinux-policy.noarch 0:3.7.19-195.el6_4.1 will be an update ---> Package selinux-policy-targeted.noarch 0:3.7.19-155.el6_3.14 will be updated ---> Package selinux-policy-targeted.noarch 0:3.7.19-195.el6_4.1 will be an update ---> Package tzdata.noarch 0:2012j-1.el6 will be updated ---> Package tzdata.noarch 0:2012j-2.el6 will be an update --> Processing Conflict: kernel-2.6.32-358.0.1.el6.x86_64 conflicts bfa-firmware < 3.0.3.1 --> Finished Dependency Resolution --> Running transaction check ---> Package cups-libs.x86_64 1:1.4.2-50.el6_4.4 will be an update --> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2)(64bit) for package: 1:cups-libs-1.4.2-50.el6_4.4.x86_64 ---> Package kernel.x86_64 0:2.6.32-279.14.1.el6 will be erased --> Processing Conflict: kernel-2.6.32-358.0.1.el6.x86_64 conflicts bfa-firmware < 3.0.3.1 --> Finished Dependency Resolution Error: kernel conflicts with bfa-firmware Error: Package: 1:cups-libs-1.4.2-50.el6_4.4.x86_64 (updates) Requires: libjpeg.so.62(LIBJPEG_6.2)(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
I have the standard repos cr enabled.
[root@orcus7 ~]# yum list installed | grep bfa-firmware bfa-firmware.noarch 3.0.0.0-1.el6 @base
It works, however, when I do an update with the 'base' repo enabled as well.
Also, what are you upgrading from?
In my case, CentOS 6.3 with daily updates installed.
We have not seen this specific issue in our QA testing.
I found it by accident because I run yum-cron and pull daily updates.
Best regards,
Peter.
On 11/03/2013 13:13, Peter Eckel wrote:
Hi Johnny,
Can you post the kernel versions and bfa-firmware versions that are trying to up upgraded ... and whether you have the i386 or x86_64 version installed?
I'm getting exactly the same error when I try to update using the 'updates' repo only:
Yes - I use my own local repo and don't sync the 'os' part - I assumed that was going to be static and only updated with 'updates'
On Mon, Mar 11, 2013 at 01:24:17PM +0000, Giles Coochey wrote:
Yes - I use my own local repo and don't sync the 'os' part - I assumed that was going to be static and only updated with 'updates'
you can't update to 6.4 from 6.3 with only updates, you MUST have 6.4/os and 6.4/update
The os ([base]) part is unchanged during the 6.n lifetime, not during the 6.n -> 6.n+1.
Tru
On 03/11/2013 08:30 AM, Tru Huynh wrote:
On Mon, Mar 11, 2013 at 01:24:17PM +0000, Giles Coochey wrote:
Yes - I use my own local repo and don't sync the 'os' part - I assumed that was going to be static and only updated with 'updates'
you can't update to 6.4 from 6.3 with only updates, you MUST have 6.4/os and 6.4/update
The os ([base]) part is unchanged during the 6.n lifetime, not during the 6.n -> 6.n+1.
In other words ... we just updated from CentOS-6.3 to CentOS-6.4 ... so the OS directory and the UPDATES directories both changed ... so your assumption is incorrect.
This is because, 6.4/os is not the same as 6.3/os. Remember that the OS directory is what is on the ISOs ... that obviously updates if we move to a newer point release and release new ISOs.
You know what they say about assume :D
On 11/03/2013 16:55, Johnny Hughes wrote:
On 03/11/2013 08:30 AM, Tru Huynh wrote:
On Mon, Mar 11, 2013 at 01:24:17PM +0000, Giles Coochey wrote:
Yes - I use my own local repo and don't sync the 'os' part - I assumed that was going to be static and only updated with 'updates'
you can't update to 6.4 from 6.3 with only updates, you MUST have 6.4/os and 6.4/update
The os ([base]) part is unchanged during the 6.n lifetime, not during the 6.n -> 6.n+1.
In other words ... we just updated from CentOS-6.3 to CentOS-6.4 ... so the OS directory and the UPDATES directories both changed ... so your assumption is incorrect.
This is because, 6.4/os is not the same as 6.3/os. Remember that the OS directory is what is on the ISOs ... that obviously updates if we move to a newer point release and release new ISOs.
You know what they say about assume :D
So I rsync'd with 6 os on the mirrors and everything works now. Thanks for clarifying.