Hi Colin,
> I am running Aventurin{e} with Virtual BQ sites and the latest yum update
> (on a BQ virtual site) is failing with
>
> Processing Conflict: kernel conflicts dev < 3.2-7
>
> Not sure why - I am not clued up enough (or brave enough) to fiddle with
> operational servers, so haven't changed the kernel outside yum. This just
> seems to have happened.
>
> Anybody able to give me some help or guidance? Michael?
It'll take longer explaining than fixing, but it'll be good to have it in the
archives for future reference.
**** ALL - PLEASE NOTE: This only applies to CentOS + BlueQuartz running under
Aventurin{e} or OpenVZ - NOT regular BlueQuartz!!! ****
Let's cover the basics first:
A virtual server under OpenVZ doesn't need a kernel, as the kernel is provided
by the master node. It doesn't hurt to have the kernel RPMs installed in the
VPS, but it's a waste of space and can create dependency issues in the long
run.
However, the kernel RPM provides some dependencies that are used or needed by
other RPMs inside the VPS. So if the kernel RPM is missing, we have to
substitute these to make the RPM database happy.
For that a CentOS VPS has two RPMs that are providing these (otherwise)
missing dependencies:
- vzdev (replaces udev)
- dummy-dentos-4 (provides missing bits and pieces from the kernel RPM)
Now on to your specific problem:
The virtual server where you're now having these problems was probably a
physical server (stand alone CentOS + BlueQuartz) that we - sometime along
the road - imported into a VPS.
When we did that I probably didn't remove the kernel RPMs, which are now
causing this dependency issues while you're trying to "yum update" to
CentOS-4.7 (which was released yesterday).
So when you run "yum update" now, it sees that a kernel is present, wants to
update it to the latest one available on YUM, but "udev" (one of the kernel
dependencies) is not present, as it has been replaced with "vzdev". Hence
the "yum update" fails. This leads to a "catch-22" situation that yum cannot
resolve without a little help from us.
So there are now two ways to resolve it. You need to use only one of the two
methods listed below to untagle this.
1.) Manually force the newer kernel in:
rpm -hUv --nodeps
http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/kernel-2.6.9-78.EL.i686.rpm
(goes into one line)
Afterwards login to the BlueQuartz GUI of the VPS, click on "Software Updates"
(or "BlueLinQ"), click on "YUM-updates" and then on "Settings".
Under "Exclude these RPMS" enter "kernel" and hit save. That will exclude the
Kernel from future YUM updates.
2.) Remove all kernel RPMs from the virtual server in question:
rpm -q kernel | xargs rpm -e --nodeps
To be double sure we have all dependencies we also re-install the "vzdev"
and "dummy-centos-4" RPMs for good measure:
rpm -hUv --force
http://vbq.solarspeed.net/pub/BlueQuartz/5100R/CentOS4/bluequartz/i386/RPMS/vzdev-3.3.13-1.4.swsoft.i386.rpm
rpm -hUv --force
http://vbq.solarspeed.net/pub/BlueQuartz/5100R/CentOS4/bluequartz/i386/RPMS/dummy-centos-4-6.0-SOL1.i386.rpm
One or both of these two RPMs may give errors during the run of
its "post-install" scripts. That's OK, as we already had them aboard earlier.
Either method (1) or method (2) should sort you out.
Afterwards you can run "yum update" again and it should go through just fine.
Method (2) will fix it on a more permanent basis, while the problem can
happen again during the next major update if you use method (1), as a future
update *may* possibly remove the "exclude kernel from future updates" notice
that we stuffed into yum.conf.
--
With best regards,
Michael Stauber