This content has been marked as final. Show 12 replies
The /lib/firmware directory is a shared directory and can only store firmware files for one version of the kernel. The problem is solved in Kernel 2.6.39 (version 3), which creates appropriate sub-directories according to kernel versions installed.
I don't know why you have run into this problem. It seems to me you are upgrading a kernel that is not your currently running kernel.
You could try to update the system without upgrading the kernel:
yum --exclude=kernel\* update
Or remove the kernel that causes the conflict. Did you install any additional kernel version or change the default one? What did you do?
Thanks for your thoughts.
This instance of the OS is running as the guest on a VM inside VirtualBox.
I have installed the guest additions (for better clipboard/mouse integration) and I believe that modifies the kernel...
I believe that's the only thing I've done/installed that would affect the kernel.
Installing the Virtualbox guest additions is definitely not the issue.
Do you use Oracle Public YUM?
Do you use YUM to update the system?
What is your currently running kernel (uname -r)?
I'm using the following kernel (uname -r): 2.6.39-1.el6.x86_64
I'm just using the Gnome Software Update component from the desktop for updates (assume it's using yum)...
These are the repos listed in /etc/yum.repos.d/
It includes the Oracle public OL6 repo.
What happens after you do the following:
Works for me.
su - root cd /etc/yum.repos.d mkdir old mv *.repo* ./old wget http://public-yum.oracle.com/public-yum-ol6.repo yum clean all yum update
Here's what I get from yum update with just the one repo in yum.repos.d:
Finished Dependency Resolution
Error: Protected multilib versions: 1:cups-libs-1.4.2-48.el6_3.1.i686 != 1:cups-libs-1.4.7-1.x86_64
You could try using --skip-broken to work around the problem
** Found 12 pre-existing rpmdb problem(s), 'yum check' output follows:
audit-libs-devel-2.1-5.el6.x86_64 has missing requires of kernel-headers >= ('0', '2.6.29', None)
1:cups-libs-1.4.7-1.x86_64 is a duplicate with 1:cups-libs-1.4.2-39.el6.i686
glibc-headers-2.12-1.25.el6.x86_64 has missing requires of kernel-headers
glibc-headers-2.12-1.25.el6.x86_64 has missing requires of kernel-headers >= ('0', '2.2.1', None)
libcap-ng-devel-0.6.4-3.el6_0.1.x86_64 has missing requires of kernel-headers >= ('0', '2.6.11', None)
libdrm-devel-2.4.23-1.el6.x86_64 has missing requires of kernel-headers >= ('0', '2.6.27', '0.144.rc0.git2.fc10')
libgcrypt-devel-1.4.5-5.el6.x86_64 has missing requires of libgcrypt = ('0', '1.4.5', '5.el6')
msttcorefonts-2.0-1.noarch has missing requires of /usr/sbin/chkfontpath
xdialog-2.3.1-3.el5.x86_64 has missing requires of libgdk-1.2.so.0()(64bit)
xdialog-2.3.1-3.el5.x86_64 has missing requires of libglib-1.2.so.0()(64bit)
xdialog-2.3.1-3.el5.x86_64 has missing requires of libgmodule-1.2.so.0()(64bit)
xdialog-2.3.1-3.el5.x86_64 has missing requires of libgtk-1.2.so.0()(64bit)
Did you have any previous aborted or failed installation attempt?
What is your output of the yum-complete-transaction command?
This was a clean install - no failed installations.
[root@nms-lnx ~]# yum-complete-transaction
Loaded plugins: refresh-packagekit
No unfinished transactions left.
Did you install anything from the 3rd party repositories?
Anyway you have software installed from the standard software repository that is failing software dependencies. How did you install it? Did you force install any package using RPM? Did you not use YUM, which automatically resolves software dependencies?
How did you install the following package:
xdialog-2.3.1-3.el5.x86_64 has missing requires of libgdk-1.2.so.0()(64bit)That's a package for EL5, not EL6.
I suggest to remove the el5 packages and try to reinstall the packages that have missing dependencies using the YUM utility, e.g.:
yum install libgcrypt.x86_64
yum reinstall libgcrypt-devel.x86_64
evildeer wrote:You're using an internal Oracle build of Oracle Linux -- please don't use the public forms for support. If you need support for a GDS image, contact GDS directly or use the GDS-related mailing lists. This is a known issue with the GDS build and has an appropriate solution.
Why are Oracle employees requesting help in the Oracle public forum?
For some Oracle products, public forums are valid places to post questions. Apparently, not so for this - I'll take it up with GDS.