| Re: Re: [Users] OpenVZ kernel RPM name [message #8243 is a reply to message #8128] |
Sat, 11 November 2006 12:11   |
Dag Wieers
Messages: 9
Registered: October 2006
|
Junior Member |
|
|
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@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@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
