Your message dated Wed, 04 Mar 2009 12:36:10 +0100
with message-id <49ae67aa.8070...@aurel32.net>
and subject line Re: Bug#518133: libc6-xen: nosegneg not selected when running 
in OpenVZ under Xen
has caused the Debian Bug report #518133,
regarding libc6-xen: nosegneg not selected when running in OpenVZ under Xen
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
518133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518133
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-xen
Version: 2.7-18
Severity: normal

Hello,

this bug report is about improving libc6's "I'm under Xen" - detection. The 
situation
"OpenVZ guest below Xen domU as OpenVZ host" should be detected, and libc6-xen 
should
be used in this situation. This has been working fine under Etch, but fails to 
work
in a mixed Etch host / Lenny guest environment.

Here are the details:

I rent a Xen domU guest from some hosting company.

That Xen guest is running a kernel supplied by myself, from some package
ovzkernel-xen_2.6.18-54.1_i386.deb, 32 bit. I did not get that kernel from any
official Debian source. I think I originally obtained it from
http://download.openvz.org/debian/ , but I'm not absoultely sure. If so, the 
kernel
is no longer available there. Privately, I still have that .deb archive I 
originally
used to install the kernel.

That Xen guest runs Debian Etch, with libc6-xen version 2.3.6.ds1-13etch9+b1, 
and
shows no problems.

I use that Etch installation as an OpenVZ host.

So virtualization on top of virtualization, Xen guest = OpenVZ host. (Roughly, 
the
Xen virtualization is for economics, the OpenVZ virtualization is for security. 
It's
been working out very nicely for me thus far.)

Most of my OpenVZ guest instances also run under Debian Etch at this point in 
time,
again with no problems.

I want to update this entire setup to Lenny.

For my first stab at that, I upgraded just one OpenVZ guest to Lenny. This is 
guest
156. I have, of course, been installing the new libc6-xen version 2.7-18 in 
156. As
far as visible from within, the OpenVZ guest seems to be running fine.

But one level below, at the OpenVZ host machine, I keep seeing log messages

... kernel: 4gb seg fixup, process ... (pid ...), cs:ip ...

I interpret this as Xen is complaining that the libc6-xen is not being used, 
but the
plain vanilla libc6 is.

Checking the process ids, I found that the processes that use the wrong libc6 
always
belong to the Lenny VZ guest 156.  Shutting down 156 makes the problem 
disappear.
(But, obviously, the services 156 is intended to provide also disappear).

I doublechecked with "ls -u", and indeed, 156 is using the wrong version of 
libc. The
correct ones have not been read for several weeks:

vzhost:/var/lib/vz/private/156/lib# ls -ltu i686/nosegneg/libc*so libc*so
-rwxr-xr-x 1 root root 1294572 2009-03-04 10:43 libc-2.7.so
-rw-r--r-- 1 root root   38296 2009-03-04 10:39 libcrypt-2.7.so
-rwxr-xr-x 1 root root 1425828 2009-02-20 14:11 i686/nosegneg/libc-2.7.so
-rw-r--r-- 1 root root  185816 2009-02-20 14:11 i686/nosegneg/libcidn-2.7.so
-rw-r--r-- 1 root root   38296 2009-02-20 14:11 i686/nosegneg/libcrypt-2.7.so
-rw-r--r-- 1 root root  185816 2009-02-20 14:11 libcidn-2.7.so

This problem does not occur with the Etch libc6-xen version. For comparison, my 
Etch
VZ guest 153 has that version, and it is being used. On that machine, it is the 
plain
vanilla libc version that has not been read for several weeks:

vzhost:/var/lib/vz/private/153/lib# ls -ltu libc*so tls/i686/cmov/libc*so
-rw-r--r-- 1 root root 1253680 2009-03-04 11:18 tls/i686/cmov/libc-2.3.6.so
-rw-r--r-- 1 root root   21868 2009-03-04 10:58 tls/i686/cmov/libcrypt-2.3.6.so
-rwxr-xr-x 1 root root 1147548 2009-02-11 22:51 libc-2.3.6.so
-rw-r--r-- 1 root root  181684 2009-02-11 22:51 libcidn-2.3.6.so
-rw-r--r-- 1 root root   21868 2009-02-11 22:51 libcrypt-2.3.6.so
-rw-r--r-- 1 root root  185780 2009-02-11 22:51 tls/i686/cmov/libcidn-2.3.6.so

Regards, and thank you for providing fine software,

Andreas

The following information is about 156:

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-53.1.19.el5.028stab053.14xen (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6-xen depends on:
ii  libc6                         2.7-18     GNU C Library: Shared libraries

libc6-xen recommends no packages.

libc6-xen suggests no packages.

-- no debconf information

-- 
Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH
andreas.krue...@dv-ratio.com
GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546  14C1 EA19 AADC FD44 5EB7

DV-RATIO NORDWEST GmbH
Tel:  +49 (0)211 / 577 996-0
Fax: +49 (0)211 / 559 1617
http://www.dv-ratio.com <http://www.dv-ratio.com>
Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf
Registergericht Düsseldorf HRB 34330
USt-IdNr.:  DE811321837
Steuer-Nr.: 809/44031
Geschäftsführung: Günter Gerstmann
Prokura: Trudbert Vetter, Uwe Wolfram

25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit"



Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message ---
Dr. Andreas Krüger a écrit :
> Package: libc6-xen
> Version: 2.7-18
> Severity: normal
> 
> Hello,
> 
> this bug report is about improving libc6's "I'm under Xen" - detection. The 
> situation
> "OpenVZ guest below Xen domU as OpenVZ host" should be detected, and 
> libc6-xen should
> be used in this situation. This has been working fine under Etch, but fails 
> to work
> in a mixed Etch host / Lenny guest environment.
> 
> Here are the details:
> 
> I rent a Xen domU guest from some hosting company.
> 
> That Xen guest is running a kernel supplied by myself, from some package
> ovzkernel-xen_2.6.18-54.1_i386.deb, 32 bit. I did not get that kernel from any
> official Debian source. I think I originally obtained it from
> http://download.openvz.org/debian/ , but I'm not absoultely sure. If so, the 
> kernel
> is no longer available there. Privately, I still have that .deb archive I 
> originally
> used to install the kernel.
> 
> That Xen guest runs Debian Etch, with libc6-xen version 2.3.6.ds1-13etch9+b1, 
> and
> shows no problems.
> 
> I use that Etch installation as an OpenVZ host.
> 
> So virtualization on top of virtualization, Xen guest = OpenVZ host. 
> (Roughly, the
> Xen virtualization is for economics, the OpenVZ virtualization is for 
> security. It's
> been working out very nicely for me thus far.)
> 
> Most of my OpenVZ guest instances also run under Debian Etch at this point in 
> time,
> again with no problems.
> 
> I want to update this entire setup to Lenny.
> 
> For my first stab at that, I upgraded just one OpenVZ guest to Lenny. This is 
> guest
> 156. I have, of course, been installing the new libc6-xen version 2.7-18 in 
> 156. As
> far as visible from within, the OpenVZ guest seems to be running fine.
> 
> But one level below, at the OpenVZ host machine, I keep seeing log messages
> 
> ... kernel: 4gb seg fixup, process ... (pid ...), cs:ip ...
> 
> I interpret this as Xen is complaining that the libc6-xen is not being used, 
> but the
> plain vanilla libc6 is.
> 
> Checking the process ids, I found that the processes that use the wrong libc6 
> always
> belong to the Lenny VZ guest 156.  Shutting down 156 makes the problem 
> disappear.
> (But, obviously, the services 156 is intended to provide also disappear).

The pseudo-hardware capability exported by the kernel was wrong in old
kernels, and libc6-xen from etch was configured to run on those kernels.
libc6-xen from lenny is configured to run on newer kernel, like the
lenny one.

You should either ask the company providing you kernel to fix the pseudo
hwcap nosegneg value, or edit /etc/ld.so.conf.d/libc6-xen.conf and
replace 'hwcap 1 nosegneg' by 'hwcap 0 nosegneg'.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurel...@aurel32.net                 http://www.aurel32.net


--- End Message ---

Reply via email to