Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #69012 > unrolled thread

sid on openvz

Back to article view | Back to linux.debian.devel

Contents

  sid on openvz James Cloos <cloos@jhcloos.com> - 2015-12-03 23:40 +0100
    Re: sid on openvz Paul Wise <pabs@debian.org> - 2015-12-04 07:10 +0100
      Re: sid on openvz Emmanuel Bourg <ebourg@apache.org> - 2015-12-04 09:40 +0100
      Re: sid on openvz Vincent Danjean <vdanjean.ml@free.fr> - 2015-12-04 16:30 +0100
    Re: sid on openvz Aurelien Jarno <aurelien@aurel32.net> - 2015-12-04 10:10 +0100
      Re: sid on openvz Steve Langasek <vorlon@debian.org> - 2015-12-04 23:10 +0100
        Re: sid on openvz Ben Hutchings <ben@decadent.org.uk> - 2015-12-04 23:40 +0100
      Re: sid on openvz md@Linux.IT (Marco d'Itri) - 2015-12-05 08:40 +0100
        Re: sid on openvz Aurelien Jarno <aurelien@aurel32.net> - 2015-12-07 12:30 +0100
          Re: sid on openvz md@Linux.IT (Marco d'Itri) - 2015-12-07 16:00 +0100
            Re: sid on openvz Dimitri John Ledkov <xnox@debian.org> - 2015-12-07 18:20 +0100
      Re: sid on openvz James Cloos <cloos@jhcloos.com> - 2015-12-11 15:40 +0100

#69012 — sid on openvz

The latest glibc update breaks most sid installs on (typically leased)
openvz platforms because it requires a newer kernel version that most
openvz vendors advertize.

Most openvz run on kernels based on 2.6.32, often with significant
updates.  These platforms are an important segment, given how affordable
they are.  And Debian "stable" is often too archaic for many needs which
fit nicely on a small inexpensive server.

There should be a way to continue to use sid on these platforms.

Adding a hold on libc6 only causes other problems, since so much now
depends on 2.21 and apt will drop them if libc6 is held on 2.19.

Is there another option to avoid the breakage?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [next] | [standalone]

#69015

On Fri, Dec 4, 2015 at 6:33 AM, James Cloos wrote:

> The latest glibc update breaks most sid installs on (typically leased)
> openvz platforms because it requires a newer kernel version that most
> openvz vendors advertize.

Is it possible for these vendors to switch to a newer version of Linux?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#69017

> Is it possible for these vendors to switch to a newer version of Linux?

A new version of OpenVZ based on the RHEL 7 kernel (3.10) is being
developed but isn't expected soon unfortunately. This led the Proxmox
team to replace OpenVZ with LXC for its containers.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#69025

Le 04/12/2015 07:06, Paul Wise a écrit :
> On Fri, Dec 4, 2015 at 6:33 AM, James Cloos wrote:
> 
>> The latest glibc update breaks most sid installs on (typically leased)
>> openvz platforms because it requires a newer kernel version that most
>> openvz vendors advertize.
> 
> Is it possible for these vendors to switch to a newer version of Linux?

Perhaps they will be more willing to do it when consumers wont be able
to install the distribution they want on their VM.
  In France, a big hosting entreprise (OVH) offers virtual hosts for
2€ / month. These are VM on an old linux OpenVZ:
$ uname -r
2.6.32-042stab111.12
  I'm not sure when/if this offer will be upgraded.

  Regards,
    Vincent

-- 
Vincent Danjean       GPG key ID 0xD17897FA         vdanjean@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

[toc] | [prev] | [next] | [standalone]

#69018

On 2015-12-03 17:33, James Cloos wrote:
> The latest glibc update breaks most sid installs on (typically leased)
> openvz platforms because it requires a newer kernel version that most
> openvz vendors advertize.
> 
> Most openvz run on kernels based on 2.6.32, often with significant
> updates.  These platforms are an important segment, given how affordable
> they are.  And Debian "stable" is often too archaic for many needs which
> fit nicely on a small inexpensive server.

If you consider Debian "stable" as too archaic, I am missing words to
qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?

> There should be a way to continue to use sid on these platforms.
> 
> Adding a hold on libc6 only causes other problems, since so much now
> depends on 2.21 and apt will drop them if libc6 is held on 2.19.
> 
> Is there another option to avoid the breakage?

One solution is to use jessie plus backports. This will be supported up
to at least May 2018, probably May 2020.

The minimum required version in the glibc is something configurable at
build time (to some extents, the absolute minimum is 2.6.32 for glibc
2.21). This configure how much compatibility glue is used to workaround
the missing syscalls. This compatibility glue is bloating the libc, and
usually also have bugs which triggers for old kernels, but also
sometimes for new kernels. For example recently someone wanted to push
the minimum version to 3.15 to fix an issue with pthread_cond_broadcast
on ARM.

That's the reason why historically we have always required for a glibc
from release N, at least the kernel from release N-2. This means for
stretch, the kernel from wheezy, ie 3.2. Supporting bleeding edge
software with an archaic kernel is not something easy to do, and other
parts of the distribution simply don't, especially since the switch to
systemd.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[toc] | [prev] | [next] | [standalone]

#69029

[Multipart message — attachments visible in raw view] — view raw

Hi Aurélien,

On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote:
> On 2015-12-03 17:33, James Cloos wrote:
> > The latest glibc update breaks most sid installs on (typically leased)
> > openvz platforms because it requires a newer kernel version that most
> > openvz vendors advertize.

> > Most openvz run on kernels based on 2.6.32, often with significant
> > updates.  These platforms are an important segment, given how affordable
> > they are.  And Debian "stable" is often too archaic for many needs which
> > fit nicely on a small inexpensive server.

> If you consider Debian "stable" as too archaic, I am missing words to
> qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?

I was going to write something similar, with references to what other
distributions are shipping; but in the course of investigating, I found that
RHEL7 and SLES11 both shipped 2.6.32 kernels that are supported until 2020
and 2019 respectively.

I don't think you have any obligation to support sid chroots on top of these
OSes - it still runs on the oldest supported Ubuntu LTS release, so that's
fine with me ;) - but I thought it was a fact worth mentioning.  Yes, these
kernels are archaic, but they're (unfortunately) not obsolete in all
contexts.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[toc] | [prev] | [next] | [standalone]

#69030

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2015-12-04 at 14:04 -0800, Steve Langasek wrote:
> Hi Aurélien,
> 
> On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote:
> > On 2015-12-03 17:33, James Cloos wrote:
> > > The latest glibc update breaks most sid installs on (typically leased)
> > > openvz platforms because it requires a newer kernel version that most
> > > openvz vendors advertize.
> 
> > > Most openvz run on kernels based on 2.6.32, often with significant
> > > updates.  These platforms are an important segment, given how affordable
> > > they are.  And Debian "stable" is often too archaic for many needs which
> > > fit nicely on a small inexpensive server.
> 
> > If you consider Debian "stable" as too archaic, I am missing words to
> > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?
> 
> I was going to write something similar, with references to what other
> distributions are shipping; but in the course of investigating, I found that
> RHEL7 and SLES11 both shipped 2.6.32 kernels that are supported until 202
0
> and 2019 respectively.
[...]

RHEL 6 has 2.6.32 (with about 10,000 patches on top); RHEL 7 has 3.10
(although I've heard that it's closer to 3.12).

SLES11 SP1 had 2.6.32, but later service packs updated the kernel to
3.0 and I don't believe SP1 is really supported any more.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

[toc] | [prev] | [next] | [standalone]

#69032

[Multipart message — attachments visible in raw view] — view raw

On Dec 03, James Cloos <cloos@jhcloos.com> wrote:

> Most openvz run on kernels based on 2.6.32, often with significant
> updates.  These platforms are an important segment, given how affordable
> they are.  And Debian "stable" is often too archaic for many needs which
> fit nicely on a small inexpensive server.
> 
> There should be a way to continue to use sid on these platforms.
I agree.

On Dec 04, Paul Wise <pabs@debian.org> wrote:

> > The latest glibc update breaks most sid installs on (typically leased)
> > openvz platforms because it requires a newer kernel version that most
> > openvz vendors advertize.
> Is it possible for these vendors to switch to a newer version of Linux?
Not at this time, there is just no viable replacement: I expect that 
it will take a few years for the replacement to mature to the level of 
the current 2.6.32 OpenVZ/Virtuozzo kernel.
(The problem is not just implementing the virtualization features with
namespaces but also replacing the resources accounting system.)

On Dec 04, Vincent Danjean <vdanjean.ml@free.fr> wrote:

> Perhaps they will be more willing to do it when consumers wont be able
> to install the distribution they want on their VM.
As an hosting provider I can say with some authority that this is not 
how it works: nobody is going to replace their OpenVZ/Virtuozzo 
infrastructure just because newer Debian releases will not work: they 
will just stop supporting newer Debian releases until they will switch 
to namespaces-based virtualization (2-5 years?).

On Dec 04, Aurelien Jarno <aurelien@aurel32.net> wrote:

> If you consider Debian "stable" as too archaic, I am missing words to
> qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?
Unlike Debian, Red Hat keeps backporting new features in the kernels 
used by their stable distributions and then will support security fixes 
for a very long time. So these kernels are not in any way comparable to 
the Debian 2.6.32 ones.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#69077

[Multipart message — attachments visible in raw view] — view raw

On 2015-12-05 08:33, Marco d'Itri wrote:
> On Dec 03, James Cloos <cloos@jhcloos.com> wrote:
> 
> > Most openvz run on kernels based on 2.6.32, often with significant
> > updates.  These platforms are an important segment, given how affordable
> > they are.  And Debian "stable" is often too archaic for many needs which
> > fit nicely on a small inexpensive server.
> > 
> > There should be a way to continue to use sid on these platforms.
> I agree.
> 
> On Dec 04, Paul Wise <pabs@debian.org> wrote:
> 
> > > The latest glibc update breaks most sid installs on (typically leased)
> > > openvz platforms because it requires a newer kernel version that most
> > > openvz vendors advertize.
> > Is it possible for these vendors to switch to a newer version of Linux?
> Not at this time, there is just no viable replacement: I expect that 
> it will take a few years for the replacement to mature to the level of 
> the current 2.6.32 OpenVZ/Virtuozzo kernel.
> (The problem is not just implementing the virtualization features with
> namespaces but also replacing the resources accounting system.)
> 
> On Dec 04, Vincent Danjean <vdanjean.ml@free.fr> wrote:
> 
> > Perhaps they will be more willing to do it when consumers wont be able
> > to install the distribution they want on their VM.
> As an hosting provider I can say with some authority that this is not 
> how it works: nobody is going to replace their OpenVZ/Virtuozzo 
> infrastructure just because newer Debian releases will not work: they 
> will just stop supporting newer Debian releases until they will switch 
> to namespaces-based virtualization (2-5 years?).
> 
> On Dec 04, Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> > If you consider Debian "stable" as too archaic, I am missing words to
> > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?
> Unlike Debian, Red Hat keeps backporting new features in the kernels 
> used by their stable distributions and then will support security fixes 
> for a very long time. So these kernels are not in any way comparable to 
> the Debian 2.6.32 ones.

Have there also backported recent glibc or systemd to these systems and
do they support such a configuration? This is what we are talking about
here.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[toc] | [prev] | [next] | [standalone]

#69082

[Multipart message — attachments visible in raw view] — view raw

On Dec 07, Aurelien Jarno <aurelien@aurel32.net> wrote:

> Have there also backported recent glibc or systemd to these systems and
> do they support such a configuration? This is what we are talking about
> here.
The *hosts* still use Centos 6, but so far more recent guests releases, 
even using systemd, are working fine.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#69084

On 7 December 2015 at 14:50, Marco d'Itri <md@linux.it> wrote:
> On Dec 07, Aurelien Jarno <aurelien@aurel32.net> wrote:
>
>> Have there also backported recent glibc or systemd to these systems and
>> do they support such a configuration? This is what we are talking about
>> here.
> The *hosts* still use Centos 6, but so far more recent guests releases,
> even using systemd, are working fine.
>

Well, for some value of work... Systemd doesn't get cgroups empty
notifications in such containers and doesn't clean up cgroups for
exited processes. I wonder, if uncleaned up cgroups in systemd tree
can cause problems or not.

-- 
Regards,

Dimitri.

[toc] | [prev] | [next] | [standalone]

#69153

>>>>> "AJ" == Aurelien Jarno <aurelien@aurel32.net> writes:

AJ> If you consider Debian "stable" as too archaic, I am missing words to
AJ> qualify a 2.6.32 kernel released in 2009. Prehistoric maybe?

Indeed, but we don't have any choice there.

And it isn't Linus' 2.6.32, its openvz's port of rh's port of 2.6.32.
So it isn't as out of date as the main version number suggests.

>> There should be a way to continue to use sid on these platforms.

AJ> One solution is to use jessie plus backports. This will be supported up
AJ> to at least May 2018, probably May 2020.

I'm (slowly) switching my openvzs to that, but not being able ever to
upgrade from jessie (and trusty for the U users, given that they've
pulled 2.21 into xenial) is a problem, even with backports.

AJ> The minimum required version in the glibc is something configurable at
AJ> build time (to some extents, the absolute minimum is 2.6.32 for glibc
AJ> 2.21).

The ideal solution, then, would be a separate libc package compiled to
work with openvz's kernel.  Maybe called libc-openvz.  And it would be
great if apt could install it by default whenever it sees /proc/vz.
This would be similar to the libc6-i686:i386, libc-xen and libc-pic
packages (and any others that I missed).

Given that it is already done for xen guests, it shouldn't be an issue
also to do so for openvz guests.

[Appologies for being slow to respond; 4.4-rc4 proved much less stable
than rc3 on my workstation.]

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web