[Devel] Re: [Users] OpenVZ kernel RPM name

Sat Nov 11 04:11:29 PST 2006

On Wed, 8 Nov 2006, Kir Kolyshkin wrote:

> Dag Wieers wrote:
> > On Tue, 17 Oct 2006, Kirill Kolyshkin wrote:
> > > On 10/16/06, Dag Wieers <dag at wieers.com> wrote:
> > >     
> > > > Yet another mail. The official openvz kernel RPMs are named in such a
> > > > way
> > > > that it causes problems. Tools like yum and apt make a special case
> > > > about
> > > > kernel RPM files because multiple of these can be installed next to each
> > > > other.
> > > >
> > > > Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
> > > > change the name of the OpenVZ kernel package from:
> > > >
> > > >         ovzkernel-2.6.9-023stab030.1-smp
> > > > to:
> > > >         kernel-smp-2.6.9-42.0.3.ovz.1
> > > >
> > > > This would make it more clear to people what it is based on and would
> > > > make
> > > > apt and yum work with those kernels by default.
> > > >       
> > > I though that (at least) yum detects "install-only" packages by their
> > > 'provides', not by name. I might be wrong with that though...here's a
> > > relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):
> > >
> > >    for instpkg in conf.installonlypkgs:
> > >        for m in mems:
> > >            if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
> > >                   and m.ts_state in ('i', 'u'):
> > >
> > > I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()'
> > > is
> > > the piece of code which helps in this scenario.
> > >     
> >
> > It's possible, still I don't see why you would deviate from the standard
> > name. The functionality is most likely introduced to consider kernel-smp and
> > kernel-bigmem as an alternative to kernel.
> >
> > Nevertheless, this doesn't work for apt. kernel-ovz might work, but the
> > proper way to tag a package is in the version or release tags. Not the
> > package-name.
> >
> >   
> > > We name our kernel packages as 'ovzkernel...' just because we don't want
> > > to
> > > mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should
> > > not
> > > be treated uniformly, otherwise yum will "upgrade" OpenVZ
> > > 2.6.16-basedkernel with stock
> > > 2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends
> > > on
> > > something that ovzkernel provides might help, but I'm not sure.
> > >     
> >
> > People should restrict what packages they use from what repsitory they have
> > enabled and/or exceptions. Having ovzkernel will not prevent additional
> > kernel packages to be updated and potentially replacing the ovz kernel in
> > grub. Especially when like in our case, we like to have the stock kernel
> > available for disaster recovery, troubleshooting or vendor-support.
> >
> > So I don't see the purpose of renaming the ovz kernel package to ovzkernel.
> > Users still need to check what kernel is in place and verify before
> > rebooting. If anything, it gives a false sense of security or causes more
> > confusing.
> >
> > Especially when documentation and forums refer to the following command to
> > list the available kernels:
> >
> > 	rpm -q kernel
> > or	rpm -qa 'kernel-*'
> >
> > Proper standards should try to reduce the amount of 'expert' information.
> > Needing to know that the openvz kernel is called ovzkernel is useless
> > information by any means.
>
> Dag, all,
> 
> As you might be aware we have switched to name our kernel rpm just 'kernel' in
> the latest devel release.
> 
> Apparently, it broke the yum update procedure. New kernel is not recognized by
> yum, even if it provides vzkernel. I have tried with a kernel package which
> also 'Provides: ovzkernel = 2.6.18-ovz028test002' but that doesn't change the
> situation. I will now try with 'Obsoletes: ovzkernel' but this solution is
> rough since it will probably uninstall the previous kernel (depends on yum
> version perhaps).
> 
> I have also try "new install" scenario on my FC5 system, it works but with a
> bad side effect:
> 
> Dependencies Resolved
> 
> =============================================================================
> Package                 Arch       Version          Repository        Size
> =============================================================================
> Installing:
> vzctl                   i386       3.0.12-1         openvz            114 k
> vzquota                 i386       3.0.9-1          openvz             47 k
> Removing:
> kernel                  i686       2.6.18-1.2200.fc5  installed          39 M
> Installing for dependencies:
> kernel                  i686       2.6.18-ovz028test002.1  openvz-kernel-devel
> 11 M
> 
> I.e. it tries to remove the latest FC5 kernel :-\ Too bad, I don't want
> that...
> 
> Perhaps somebody has a way to fix that?

Might this be because your system is configured to hold not more than X 
number of kernels ? I see no reason why a new kernel would cause an old 
kernel to be removed if there's no obsolete statement, except if there's a 
LIFO mechanism to push old kernels out.

I'm interested to see the SPEC file and debug the problem.

Also I noticed that the ovz kernel had no internal changelog. I do 
understand that if it is based on the RHEL kernel, there is no real need 
to list the Red Hat changes. But having (fictitious) statements in the 
changelog like:

 * Sun Nov 12 OpenVZ kernel developer 2
 - Fixed a conditional kernel oops when <the shit hits the fan>
 - Improved locking in the <ultra-glue whoosy bits>
 - Fixed a security problem due to UBC counter overflow

 * Sat Nov 11 OpenVZ Kernel developer 1
 - Fixed bug M, BU Y and bug Z
 - Removed CONFIG_ABC and CONFIG_DEF
 - Based on RHEL4 kernel X.Y.Z

would give a better understanding what we have in our hands. Especially if 
the versioning is not related to the upstream kernel. If we need to apply 
an update (and reboot the server) we prefer to know what the change/impact 
is and how important the update is.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]