From owner at bugs.debian.org  Sat Feb  2 19:06:07 2013
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Sat, 02 Feb 2013 19:06:07 +0000
Subject: [Pkg-xen-devel] Processed: tagging as pending bugs that are closed
	by packages in NEW
References: <20130202190359.DB87180602B8@elida.v7w.com>
Message-ID: <handler.s.C.135983184310400.transcript@bugs.debian.org>

Processing commands for control at bugs.debian.org:

> # Saturday 2 February  19:03:31 UTC 2013
> # Tagging as pending bugs that are closed by packages in NEW
> # http://ftp-master.debian.org/new.html
> #
> # Source package in NEW: cliff-tablib
> tags 699594 + pending
Bug #699594 [wnpp] ITP: cliff-tablib -- tablib formatters for cliff
Added tag(s) pending.
> # Source package in NEW: python-tablib
> tags 699592 + pending
Bug #699592 [wnpp] ITP: python-tablib -- format agnostic tabular dataset library
Added tag(s) pending.
> # Source package in NEW: radium-compressor
> tags 699606 + pending
Bug #699606 [wnpp] ITP: radium-compressor -- audio compressor for JACK
Added tag(s) pending.
> # Source package in NEW: python-cinderclient
> tags 687518 + pending
Bug #687518 [wnpp] ITP: python-cinderclient -- python bindings to the OpenStack Volume API
Added tag(s) pending.
> # Source package in NEW: <a href="http://packages.qa.debian.org/libmsv">libmsv</a>
> tags 699497 + pending
Bug #699497 [libmsv0] libmsv0: libmsv fails to properly escape data passed to msv_query_agent
Added tag(s) pending.
> # Source package in NEW: <a href="http://packages.qa.debian.org/libmsv">libmsv</a>
> tags 699500 + pending
Bug #699500 [libmsv0] libmsv0: memory leaks and possible segfaults in msv_query_agent() and msv_check_msva()
Added tag(s) pending.
> # Source package in NEW: <a href="http://packages.qa.debian.org/libmsv">libmsv</a>
> tags 699506 + pending
Bug #699506 [libmsv0] libmsv0: most char* arguments to libmsv functions should accept const char* instead
Added tag(s) pending.
> # Source package in NEW: ceilometer
> tags 693406 + pending
Bug #693406 [wnpp] ITP: ceilometer -- openstack efficient metering counters system
Added tag(s) pending.
> # Source package in NEW: swift-plugin-s3
> tags 693137 + pending
Bug #693137 [wnpp] ITP: swift-plugin-s3 -- swift3 (S3 compatibility) middleware plugin for swift
Added tag(s) pending.
> # Source package in NEW: heat
> tags 695302 + pending
Bug #695302 [wnpp] ITP: heat -- service to orchestrate multiple composite cloud applications
Added tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
687518: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687518
693137: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693137
693406: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693406
695302: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695302
699497: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699497
699500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699500
699506: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699506
699592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699592
699594: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699594
699606: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699606
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


From vendas at lulaweb.net  Mon Feb  4 05:25:51 2013
From: vendas at lulaweb.net (Luiz Carlos)
Date: Mon, 04 Feb 2013 06:25:51 +0100
Subject: [Pkg-xen-devel] Primeiro Programa de Afiliado Que Fornece Nota
	Fiscal P/ Seus Afiliados e Com Custo Baixo.
Message-ID: <2b165daba9237b44b530e6fe60ece4a9@publicidade.lulaweb.com.br>

Seu cliente de e-mail n?o pode ler este e-mail.
Para visualiz?-lo on-line, por favor, clique aqui:
http://publicidade.lulaweb.com.br/display.php?M=3076&C=631bcff6f40110cb77e873d3691fd9ff&S=2&L=1&N=1


Para parar de receber nossos
e-mails:http://publicidade.lulaweb.com.br/unsubscribe.php?M=3076&C=631bcff6f40110cb77e873d3691fd9ff&L=1&N=2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130204/c0214ba0/attachment.html>

From davide.prina at gmail.com  Tue Feb  5 20:08:23 2013
From: davide.prina at gmail.com (Davide Prina)
Date: Tue, 05 Feb 2013 21:08:23 +0100
Subject: [Pkg-xen-devel] Bug#699845: libblktapctl0: wrong paragraph
	separation in package description
Message-ID: <511166B7.3010404@gmail.com>

Package: libblktapctl0
Severity: minor

Dear Maintainer,

in DDTSS I see:

****
coalescing of differencing disks.
  .
Libvhd is a
****

note the extra space before the dot '.' used as paragraph separation

Ciao
Davide

-- 
Dizionari: http://linguistico.sourceforge.net/wiki
Database: http://www.postgresql.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook


From ftpmaster at ftp-master.debian.org  Wed Feb  6 12:16:20 2013
From: ftpmaster at ftp-master.debian.org (Debian FTP Masters)
Date: Wed, 06 Feb 2013 12:16:20 +0000
Subject: [Pkg-xen-devel] Processing of xen_4.1.4-2_amd64.changes
Message-ID: <E1U33vI-0005n6-R9@franck.debian.org>

xen_4.1.4-2_amd64.changes uploaded successfully to localhost
along with the files:
  xen_4.1.4-2.dsc
  xen_4.1.4-2.debian.tar.gz
  xen-hypervisor-4.1-amd64_4.1.4-2_amd64.deb
  xen-system-amd64_4.1.4-2_amd64.deb
  xen-docs-4.1_4.1.4-2_all.deb
  xen-utils-common_4.1.4-2_all.deb
  libxen-dev_4.1.4-2_amd64.deb
  libxenstore3.0_4.1.4-2_amd64.deb
  libxen-ocaml-dev_4.1.4-2_amd64.deb
  libxen-4.1_4.1.4-2_amd64.deb
  libxen-ocaml_4.1.4-2_amd64.deb
  xenstore-utils_4.1.4-2_amd64.deb
  xen-utils-4.1_4.1.4-2_amd64.deb

Greetings,

	Your Debian queue daemon (running on host franck.debian.org)


From ftpmaster at ftp-master.debian.org  Wed Feb  6 12:18:01 2013
From: ftpmaster at ftp-master.debian.org (Debian FTP Masters)
Date: Wed, 06 Feb 2013 12:18:01 +0000
Subject: [Pkg-xen-devel] xen_4.1.4-2_amd64.changes ACCEPTED into unstable
Message-ID: <E1U33wv-0006mZ-Pg@franck.debian.org>



Accepted:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 06 Feb 2013 13:04:52 +0100
Source: xen
Binary: xen-docs-4.1 libxen-4.1 libxenstore3.0 libxen-dev xenstore-utils libxen-ocaml libxen-ocaml-dev xen-utils-common xen-utils-4.1 xen-hypervisor-4.1-amd64 xen-system-amd64 xen-hypervisor-4.1-i386 xen-system-i386
Architecture: source amd64 all
Version: 4.1.4-2
Distribution: unstable
Urgency: low
Maintainer: Debian Xen Team <pkg-xen-devel at lists.alioth.debian.org>
Changed-By: Bastian Blank <waldi at debian.org>
Description: 
 libxen-4.1 - Public libs for Xen
 libxen-dev - Public headers and libs for Xen
 libxen-ocaml - OCaml libraries for controlling Xen
 libxen-ocaml-dev - OCaml libraries for controlling Xen (devel package)
 libxenstore3.0 - Xenstore communications library for Xen
 xen-docs-4.1 - Documentation for Xen
 xen-hypervisor-4.1-amd64 - Xen Hypervisor on AMD64
 xen-hypervisor-4.1-i386 - Xen Hypervisor on i386
 xen-system-amd64 - Xen System on AMD64 (meta-package)
 xen-system-i386 - Xen System on i386 (meta-package)
 xen-utils-4.1 - XEN administrative tools
 xen-utils-common - Xen administrative tools - common files
 xenstore-utils - Xenstore utilities for Xen
Changes: 
 xen (4.1.4-2) unstable; urgency=low
 .
   * Use pre-device interrupt remapping mode per default. Fix removing old
     remappings.
     CVE-2013-0153
Checksums-Sha1: 
 0057c699eef7c7389da03604e21358aad88b5abf 2389 xen_4.1.4-2.dsc
 4b2ede2f8b6a5214aab4c48b76574bec9e10dff6 144157 xen_4.1.4-2.debian.tar.gz
 78f3b5978ce0f97f2326a473d593ffbdf31e560f 759700 xen-hypervisor-4.1-amd64_4.1.4-2_amd64.deb
 a37a3b9b539372e9eb9b40a89c1db8e88bd033e8 18068 xen-system-amd64_4.1.4-2_amd64.deb
 c1aae6305bdb6574a0fa7fa5d7bfa801f751e35e 1172018 xen-docs-4.1_4.1.4-2_all.deb
 1bf06608db900bf6af9397d225a7f7b6cfa2b587 79234 xen-utils-common_4.1.4-2_all.deb
 7b6aaba85eaa955232d2a4d232ce03edee6bd265 290966 libxen-dev_4.1.4-2_amd64.deb
 d6418671337c06e8f34044c1eee7c4d9dcd40951 29360 libxenstore3.0_4.1.4-2_amd64.deb
 975221dc56465188995ed710767492bb12aa8637 88756 libxen-ocaml-dev_4.1.4-2_amd64.deb
 76b52177b6e83aff4f834c6f02808b933d2976c4 139678 libxen-4.1_4.1.4-2_amd64.deb
 8e5d2df4a5569d94684c3dd072cc21d8919d6bb5 63178 libxen-ocaml_4.1.4-2_amd64.deb
 1a894c9ce0d097dd570bc66704b190296c85e790 26678 xenstore-utils_4.1.4-2_amd64.deb
 b93428d91b966927d1a9ab09bafb7be2a1188054 1608120 xen-utils-4.1_4.1.4-2_amd64.deb
Checksums-Sha256: 
 e83e454ea88901a56b19126b729dc71584f186449a195d7147913b4c25faee3d 2389 xen_4.1.4-2.dsc
 ca9e3e2033ad7419555eb54792eb9ee49b241c395f61de892783a99759d6bda0 144157 xen_4.1.4-2.debian.tar.gz
 efcad6b16a7f3123692c57469ed2d94e54a9adb3d11b770636ca119e0cab49eb 759700 xen-hypervisor-4.1-amd64_4.1.4-2_amd64.deb
 ce2da449dd9ede5031f7b39a6d2c2ef1b6e4ef6eb4b906fb6560888508ff3919 18068 xen-system-amd64_4.1.4-2_amd64.deb
 721ff98d2bec3eeb06870b05b3eb03b14d6debe8568be0c89c7b50d6f917bfd1 1172018 xen-docs-4.1_4.1.4-2_all.deb
 ffcc6fdddb5e98688716a22030f93cdd76d6a4320f511c267cbb090c09fc797b 79234 xen-utils-common_4.1.4-2_all.deb
 ae38c5bf6a41a21be7b7e4b27ca19e88ea88bbdaa7fddb3612621d74c6458a3f 290966 libxen-dev_4.1.4-2_amd64.deb
 9ab53643054d4a0d9efa5e46936c366588c64e3659a7a3a4066b198366588635 29360 libxenstore3.0_4.1.4-2_amd64.deb
 02a00c0075b847f4084ad622cfb8eb1db53887d801722d456bc49dcba5d7d25c 88756 libxen-ocaml-dev_4.1.4-2_amd64.deb
 bdb2959916a5a85f8b8a5945da4da8ece0f354a73512737dded87c667663df79 139678 libxen-4.1_4.1.4-2_amd64.deb
 e53fdd837b16420db3df05ac92730767393a3ab3f7bd7f2f8dfc6b5911bbcf3a 63178 libxen-ocaml_4.1.4-2_amd64.deb
 1a48aa4ae584d27893b2e2b10cfb58245aea0b0a22238b7e208ecf85c37b7706 26678 xenstore-utils_4.1.4-2_amd64.deb
 2154a4ddb42a440ab2caea948650a93df9221e2d0e7e1222117711b5c34736fc 1608120 xen-utils-4.1_4.1.4-2_amd64.deb
Files: 
 43fb0fd8bd67988577d7befcdceabdb2 2389 kernel optional xen_4.1.4-2.dsc
 2da1a3701d0b7bc305693c37f246ec2c 144157 kernel optional xen_4.1.4-2.debian.tar.gz
 b5852e0558e883e271fb76ec6237e2e6 759700 kernel optional xen-hypervisor-4.1-amd64_4.1.4-2_amd64.deb
 6e18daa2c59ce2e48c0e684ce5224527 18068 kernel optional xen-system-amd64_4.1.4-2_amd64.deb
 cc067846acdd19db0452e4c39f05ccd7 1172018 doc optional xen-docs-4.1_4.1.4-2_all.deb
 08d8cbe58f986ad2e2059413ebdc839b 79234 kernel optional xen-utils-common_4.1.4-2_all.deb
 b52a45170676638430736b640a2d7931 290966 libdevel optional libxen-dev_4.1.4-2_amd64.deb
 5ea3208b7b3907d7d81a53fe2522dc7e 29360 libs optional libxenstore3.0_4.1.4-2_amd64.deb
 b377b2cd7ddf2ff25e21aa1929333847 88756 ocaml optional libxen-ocaml-dev_4.1.4-2_amd64.deb
 36e5e48a7da8cbd294acd983dba73bb3 139678 libs optional libxen-4.1_4.1.4-2_amd64.deb
 fee5d16077002d598079801e1f8a6878 63178 ocaml optional libxen-ocaml_4.1.4-2_amd64.deb
 622f34437977e1f5675b5f3be9d03413 26678 admin optional xenstore-utils_4.1.4-2_amd64.deb
 49fb35c2ee1f27b8ac63ab2704e05fa6 1608120 kernel optional xen-utils-4.1_4.1.4-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlESSNAACgkQLkAIIn9ODhFmHACfVO0kQaojVdOtAUPzIJUT7y0u
qBwAoItkDDz+HJpg/O7EZ6JkBlE1qgMG
=1TBo
-----END PGP SIGNATURE-----


Thank you for your contribution to Debian.


From info at rockero.org  Thu Feb  7 14:07:22 2013
From: info at rockero.org (www.rockero.org)
Date: Thu, 7 Feb 2013 07:07:22 -0700
Subject: [Pkg-xen-devel] SONATA ARCTICA TOUR COLOMBIA 2013
Message-ID: <72af08b3dfea293c6b04bb5d32938306@www.rockero.org>



 <http://www.rockero.org/box/lt.php?id=ZUtQBFQDW1BXCR9TU1tPDlEFBAk%3D>



<body link="#FF9933" vlink="#FF9933" alink="#FF9933">
<div align="center" id="foot"> 
  <p><font size="-2"><line height="110%">
    <font face="Arial, Helvetica, sans-serif"><font color="#FFFF66"><font
color="#FF0000">Visita </font><font size="-2"><font face="Arial, Helvetica,
sans-serif"><font color="#FF6600">rockero.org</font></font></font><font
color="#FF0000"> La comunidad del rock!</font><br>
  </font></font></font><font size="-2"><line height="110%"><font
face="Arial, Helvetica, sans-serif"><font
color="#FFFF66"><em>(Remove?)</em></font><font color="#FF0000"> Si no
quieres recibir m?s emails nuestros ve a</font> <font
color="#FF6600">http://www.rockero.org/box/lt.php?id=ZUsdB1UKHlhUD1JQ></font></font>
<font size="-2"><font face="Arial, Helvetica, sans-serif"><br>
      <em><line height="110%"><font color="#FF0000"><font
color="#FFFF66">(Send to Friend?)</font></font></em><font color="#FF0000">
Env?a este mensaje a un amigo</font> <font color="#FF0000">haciendo click
en</font> <font
color="#FF6600">http://www.rockero.org/box/lt.php?id=ZUtQBFQDW1BXDR9TU1tPDlEFBAk%3D></font></font>
</div>



--
powered by phpList, www.phplist.com --


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130207/6af7596e/attachment.html>

From contact at 0204first.info  Fri Feb  8 08:00:47 2013
From: contact at 0204first.info (=?utf-8?Q?Zammit_Mathieu?=)
Date: Fri, 8 Feb 2013 09:00:47 +0100 (CET)
Subject: [Pkg-xen-devel] Positionnement sur Google
Message-ID: <17077-69-0-0000000911@sbr05.net>

D?sinscription ( "http://www.0204first.info/LINK-Liste-Noire.php?S_Mode=Unsubscribe&S_Push=NLS6-13-02-07&S_Email=pkg-xen-devel at lists.alioth.debian.org&S_Domain=wiki.debian.org" )
---------------------------

Bonjour,

Votre site internet wiki.debian.org ? retenu notre attention.


Nous poss?dons 17 sites sur diff?rentes th?matiques :

PR4 - www.formation-sketchup.fr ( "http://www.formation-sketchup.fr" ) (Formation, Informatique, Logiciel,...)
PR4 - www.formation-photoshop.org ( "http://www.formation-photoshop.org" ) (Formation, Informatique, Logiciel,...)
PR4 - abolitionistcrusade.org ( "http://abolitionistcrusade.org" ) (History,...)
PR4 - maintenance-info.org ( "http://maintenance-info.org" ) (Technique, Electricit?, M?canique, Enseignement,...)
PR3 - www.habilitation-electrique.org ( "http://www.habilitation-electrique.org" ) (Formation, S?curit?, Technologie,...)
PR3 - www.table-lampe-meuble-design.com ( "http://www.table-lampe-meuble-design.com" ) (Design, D?coration, Boutique,...)
PR3 - cours-electricite.info ( "http://cours-electricite.info" ) (Technique, Electricit?, Enseignement,...)
PR3 - la-lumiere.org ( "http://la-lumiere.org" ) (Physique, Enseignement,...)
PR3 - la-gravitation.info ( "http://la-gravitation.info" ) (Physique, Enseignement,...)
PR3 - diy-kart.info ( "http://diy-kart.info" ) (Bricolage, Technique,...)
PR2 - www.implant-dentaire-eu.com ( "http://www.implant-dentaire-eu.com" ) (Sant?/M?dical,...)
PR2 - lechauffageelec.org ( "http://lechauffageelec.org" ) (Technique, Electricit?, Enseignement,...)
Etc...


Nous aimerions vous proposer de l'?change de liens pour am?liorer nos positionnements respectifs dans les r?sultats de Google.


Seriez-vous int?ress? ?


A votre disposition, salutations sinc?res.

Mathieu ZAMMIT
N.L.S.
06.52.585.909
contact at 0204first.info ( "mailto:contact at 0204first.info" )


---------------------------
"Informatique et libert?s" du 06/01/1978, vous disposez d'un droit d'acc?s et de rectification aux informations qui vous concernent.

D?sinscription ( "http://www.0204first.info/LINK-Liste-Noire.php?S_Mode=Unsubscribe&S_Push=NLS5-13-02-04&S_Email=pkg-xen-devel at lists.alioth.debian.org&S_Domain=wiki.debian.org" )



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130208/af237bdc/attachment.html>

From owner at bugs.debian.org  Sun Feb 10 09:27:10 2013
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Sun, 10 Feb 2013 09:27:10 +0000
Subject: [Pkg-xen-devel] Processed: archiving 686764
References: <1360488195-3103-bts-waldi@debian.org>
Message-ID: <handler.s.C.136048820123451.transcript@bugs.debian.org>

Processing commands for control at bugs.debian.org:

> archive 686764
Bug #686764 {Done: Bastian Blank <waldi at debian.org>} [xen] xen: Multiple security issues
archived 686764 to archive/64 (from 686764)
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
686764: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686764
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


From daniel at pocock.com.au  Sun Feb 10 15:45:03 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Sun, 10 Feb 2013 16:45:03 +0100
Subject: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
Message-ID: <5117C07F.6000703@pocock.com.au>

control: severity +2 serious

I would call this an RC bug (serious), but not critical


It would be critical if the user lost data from some unrelated
application, etc


It is serious because

a) it makes the package and the whole system unusable for all but one
very specific network configuration (users with a /24)

b) using good old `xm' style Xen I never experienced any issue like
this, just using a /26 subnet with xm on squeeze is fine.

c) it will lead to a complete loss of connectivity for people accessing
a host remotely to set up XCP


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695221#10
refers to a workaround - nothing in the bug report qualifies as a
workaround (but I propose one below).  The reporter simply explained
that he could only make pif-reconfigure-ip work the way it should by
specifying a specific network mask (/24).  That in itself is not a
workaround, it is just an observation about what values work and what
values don't work.


I can confirm observing this identical issue, I configured a /29 netmask
and `ip addr' shows me that my server thinks it is on a /32.  This makes
the whole host unreachable.

I did a `find' in /etc and /var and I located the following file:

/var/lib/xcp/networkd.db

which contains the value {"interface_config":  ......"MY ADDRESS", 32]]]

The 32 is the bad subnet mask.  Using vi, I replaced it with 29  (for a
/29), rebooted, and it came up OK.  As I don't know XCP very well, I
don't want to suggest this is a valid workaround.  Could anyone with
more experience confirm if that file can be modified by hand in this
case?  Is there something else that could come along and clobber that
file?  Does xcp-networkd need to be stopped before modifying the file
safely?

If there is a workaround (what I describe above, or something else) for
this such that a /29 or some other valid netmask can be enabled, then
the bug could probably be downgraded to important but certainly not
normal, it is just too disruptive.

To extend the scope of what may qualify as a valid workaround:

a) is there some valid use case that avoids using pif-reconfigure-ip and
just let /etc/network/interfaces manage the IP?

b) should the user put a /24 subnet on a dummy interface and configure
eth0 or xenbr0 separately from XCP?

I also came across this:

http://lists.xen.org/archives/html/xen-api/2012-05/msg00104.html

which contradicts this:

http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution#Setup_the_network.2Finterfaces_file

Specifically, the mailing list posts suggests nothing should be in
/etc/network/interfaces, but the wiki suggests that the interface should
be described in /etc/network/interfaces (even though it will eventually
be reconfigured by xcp-networkd later in the boot process)


From owner at bugs.debian.org  Sun Feb 10 15:51:07 2013
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Sun, 10 Feb 2013 15:51:07 +0000
Subject: [Pkg-xen-devel] Processed: serious bug with networking
References: <5117C1B2.7060108@pocock.com.au>
Message-ID: <handler.s.C.136051142023036.transcript@bugs.debian.org>

Processing commands for control at bugs.debian.org:

> severity 695221 serious
Bug #695221 [xcp-xapi] xcp-xapi: xe pif-reconfigure-ip doesn't work with non 255.255.255.0 subnet netmask
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
695221: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695221
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


From zigo at debian.org  Mon Feb 11 02:48:18 2013
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 11 Feb 2013 10:48:18 +0800
Subject: [Pkg-xen-devel] Bug#695221:  Bug#695221: confirmed bug, serious
In-Reply-To: <5117C07F.6000703@pocock.com.au>
References: <5117C07F.6000703@pocock.com.au>
Message-ID: <51185BF2.7080406@debian.org>

I don't think it's useful to bikeshed about the severity of an issue but...

On 02/10/2013 11:45 PM, Daniel Pocock wrote:
> It is serious because
> 
> a) it makes the package and the whole system unusable for all but one
> very specific network configuration (users with a /24)

Using a /24 is all but a "very specific network configuration", it's in
fact the most common one.

> b) using good old `xm' style Xen I never experienced any issue like
> this, just using a /26 subnet with xm on squeeze is fine.

This is totally unrelated.

> c) it will lead to a complete loss of connectivity for people accessing
> a host remotely to set up XCP

Sure, but it doesn't match the "serious" definition:

makes the package in question unusable by most or all users, or causes
data loss, or introduces a security hole allowing access to the accounts
of users who use the package.

Besides this, I don't think it's reasonable to delay the release of
Wheezy just for this bug.

> I did a `find' in /etc and /var and I located the following file:
> 
> /var/lib/xcp/networkd.db
> 
> which contains the value {"interface_config":  ......"MY ADDRESS", 32]]]
> 
> The 32 is the bad subnet mask.  Using vi, I replaced it with 29  (for a
> /29), rebooted, and it came up OK.

That's interesting!

I've added Mike and Jon as Cc:, hoping that they will be able to tell
wtf is going on, and why the db is being wrong.

> As I don't know XCP very well, I
> don't want to suggest this is a valid workaround.  Could anyone with
> more experience confirm if that file can be modified by hand in this
> case?  Is there something else that could come along and clobber that
> file?  Does xcp-networkd need to be stopped before modifying the file
> safely?

Mike must know.

> If there is a workaround (what I describe above, or something else) for
> this such that a /29 or some other valid netmask can be enabled, then
> the bug could probably be downgraded to important but certainly not
> normal, it is just too disruptive.

Ultimately, this is the job of the maintainer of a given package to
decide the seriousness of a bug. To me, setting it to either normal or
important is exactly the same (eg: it is on my radar, and I really want
to have it fix), and discussing the seriousness doesn't help. Discussing
ways to fix it does.

> To extend the scope of what may qualify as a valid workaround:
> 
> a) is there some valid use case that avoids using pif-reconfigure-ip and
> just let /etc/network/interfaces manage the IP?

I don't think so. XAPI needs to know how you configure your PIF.

> b) should the user put a /24 subnet on a dummy interface and configure
> eth0 or xenbr0 separately from XCP?

I don't think so.

> I also came across this:
> 
> http://lists.xen.org/archives/html/xen-api/2012-05/msg00104.html
> 
> which contradicts this:
> 
> http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution#Setup_the_network.2Finterfaces_file
> 
> Specifically, the mailing list posts suggests nothing should be in
> /etc/network/interfaces, but the wiki suggests that the interface should
> be described in /etc/network/interfaces (even though it will eventually
> be reconfigured by xcp-networkd later in the boot process)

As much as I know, you do have to configure stuff in
/etc/network/interfaces. This is described in the README.Debian for
xcp-xapi, under section 4.2 of the file. Though the networking might be
different when using openvswitch, I'm not sure about this.

Thomas


From owner at bugs.debian.org  Mon Feb 11 02:51:08 2013
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Mon, 11 Feb 2013 02:51:08 +0000
Subject: [Pkg-xen-devel] Processed: Back to important
References: <51185C1D.6090806@debian.org>
Message-ID: <handler.s.C.136055094524880.transcript@bugs.debian.org>

Processing commands for control at bugs.debian.org:

> severity 695221 important
Bug #695221 [xcp-xapi] xcp-xapi: xe pif-reconfigure-ip doesn't work with non 255.255.255.0 subnet netmask
Severity set to 'important' from 'serious'
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
695221: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695221
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


From daniel at pocock.com.au  Mon Feb 11 08:22:33 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 11 Feb 2013 09:22:33 +0100
Subject: [Pkg-xen-devel] Bug#695221:  Bug#695221: confirmed bug, serious
In-Reply-To: <51185BF2.7080406@debian.org>
References: <5117C07F.6000703@pocock.com.au> <51185BF2.7080406@debian.org>
Message-ID: <5118AA49.4040008@pocock.com.au>

On 11/02/13 03:48, Thomas Goirand wrote:
> I don't think it's useful to bikeshed about the severity of an issue but...
>
>   

I can see you've put a lot of work into this package and I think people
will want to use it, especially when wheezy is released

That's why I'm reporting stuff like this and also providing suggested
solutions (e.g the possible workaround)

> On 02/10/2013 11:45 PM, Daniel Pocock wrote:
>   
>> It is serious because
>>
>> a) it makes the package and the whole system unusable for all but one
>> very specific network configuration (users with a /24)
>>     
> Using a /24 is all but a "very specific network configuration", it's in
> fact the most common one.
>
>   
<snip>
>> c) it will lead to a complete loss of connectivity for people accessing
>> a host remotely to set up XCP
>>     
> Sure, but it doesn't match the "serious" definition:
>
> makes the package in question unusable by most or all users, or causes
> data loss, or introduces a security hole allowing access to the accounts
> of users who use the package.
>
>   
I think that comes back to point (a) - if `most' or even a lot of users
are not using /24 (which is not clear to me), and if there is no
workaround, then maybe it is serious


> Besides this, I don't think it's reasonable to delay the release of
> Wheezy just for this bug.
>
>   

Having it marked RC may allow a patch into wheezy.  Maybe even a small
patch:

- updating the README

- changing pif-reconfigure-ip to give an error if the user tries a
netmask that is not supported, e.g.

"XCP only works on a Class C subnet with a netmask 255.255.255.0.  Your
changes have not been applied.
See bug 695221 or the README file."

These things would be small fixes but would make the user's first
experience of XCP less frustrating

The last thing you want is for people to get frustrated and start
thinking that they should try the Ubuntu version or the ISO installer:
http://www.xen.org/download/xcp/index_1.6.0.html#install

>> I did a `find' in /etc and /var and I located the following file:
>>
>> /var/lib/xcp/networkd.db
>>
>> which contains the value {"interface_config":  ......"MY ADDRESS", 32]]]
>>
>> The 32 is the bad subnet mask.  Using vi, I replaced it with 29  (for a
>> /29), rebooted, and it came up OK.
>>     
> That's interesting!
>
> I've added Mike and Jon as Cc:, hoping that they will be able to tell
> wtf is going on, and why the db is being wrong.
>
>   
>> As I don't know XCP very well, I
>> don't want to suggest this is a valid workaround.  Could anyone with
>> more experience confirm if that file can be modified by hand in this
>> case?  Is there something else that could come along and clobber that
>> file?  Does xcp-networkd need to be stopped before modifying the file
>> safely?
>>     
> Mike must know.
>
>   
>> If there is a workaround (what I describe above, or something else) for
>> this such that a /29 or some other valid netmask can be enabled, then
>> the bug could probably be downgraded to important but certainly not
>> normal, it is just too disruptive.
>>     
> Ultimately, this is the job of the maintainer of a given package to
> decide the seriousness of a bug. To me, setting it to either normal or
> important is exactly the same (eg: it is on my radar, and I really want
> to have it fix), and discussing the seriousness doesn't help. Discussing
> ways to fix it does.
>
>   
It's not quite the same, because the release team wouldn't accept a
patch/unblock request for a normal issue

I'm hoping that the fix for this might be quite trivial and therefore
acceptable to the release team.


From zigo at debian.org  Tue Feb 12 03:22:12 2013
From: zigo at debian.org (Thomas Goirand)
Date: Tue, 12 Feb 2013 11:22:12 +0800
Subject: [Pkg-xen-devel] Bug#695221:  Bug#695221: confirmed bug, serious
In-Reply-To: <5118AA49.4040008@pocock.com.au>
References: <5117C07F.6000703@pocock.com.au> <51185BF2.7080406@debian.org>
	<5118AA49.4040008@pocock.com.au>
Message-ID: <5119B564.1070008@debian.org>

On 02/11/2013 04:22 PM, Daniel Pocock wrote:
> Having it marked RC may allow a patch into wheezy.

Marking it RC is only delaying the release, that's it. I have already
fixed multiple bugs which were not marked as RC, and the release team
accepted the changes. Even after Wheezy is released, it is possible to
fix problems in the stable distribution.

> Maybe even a small patch:

A small patch is what we should all aim at. I'm sure the problem isn't
so complicated, and that we can fix it.

Of course, it would help if Mike and Jon were a bit more cooperative and
were trying to fix the issue, but it seems they are quite busy these
days (or maybe in holidays?).

> 
> - updating the README
> 
> - changing pif-reconfigure-ip to give an error if the user tries a
> netmask that is not supported, e.g.
> 
> "XCP only works on a Class C subnet with a netmask 255.255.255.0.  Your
> changes have not been applied.
> See bug 695221 or the README file."

Yeah, I think that is indeed a good idea to write this!

> These things would be small fixes but would make the user's first
> experience of XCP less frustrating
> 
> The last thing you want is for people to get frustrated and start
> thinking that they should try the Ubuntu version or the ISO installer:
> http://www.xen.org/download/xcp/index_1.6.0.html#install

Well, yes, I would like to have more Debian users, and that people use
less XCP from the ISO installer (eg: CentOS based). However, the Ubuntu
package of XCP is synced from Debian, so these are the exact same
package (with only a possible delay in having the Ubuntu package).
Nobody in Ubuntu works on the XCP packaging, the work is only been done
by myself in Debian.

>> Ultimately, this is the job of the maintainer of a given package to
>> decide the seriousness of a bug. To me, setting it to either normal or
>> important is exactly the same (eg: it is on my radar, and I really want
>> to have it fix), and discussing the seriousness doesn't help. Discussing
>> ways to fix it does.
>
> It's not quite the same, because the release team wouldn't accept a
> patch/unblock request for a normal issue

This statement is completely wrong. The criteria for the release team to
accept changes is not the severity of a bug only. If we find a way to
fix this problem, I'm quite sure that the release team will accept the
patch, regardless of the severity set in the BTS.

> I'm hoping that the fix for this might be quite trivial and therefore
> acceptable to the release team.

Yeah, that's more in line! If the fix is small, and even trivial, and
easy to review for them (which is quite likely to be the case,
considering that just fixing the db with an editor fixed it for you),
then they will accept it.

I'm also quite sure that they would accept any documentation change at
this point of the release.

Cheers,

Thomas


From woodgate2 at yahoo.com.hk  Fri Feb 15 16:31:46 2013
From: woodgate2 at yahoo.com.hk (Terry Woodgate)
Date: Fri, 15 Feb 2013 23:31:46 +0700
Subject: [Pkg-xen-devel] LOAN AND FINANCE
Message-ID: <E1U6OCQ-0007cJ-6a@8976.vn>

An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130215/496e3567/attachment.html>

From noreply at release.debian.org  Sun Feb 17 16:39:15 2013
From: noreply at release.debian.org (Debian testing watch)
Date: Sun, 17 Feb 2013 16:39:15 +0000
Subject: [Pkg-xen-devel] xen 4.1.4-2 MIGRATED to testing
Message-ID: <E1U77Gl-0006WF-5K@franck.debian.org>

FYI: The status of the xen source package
in Debian's testing distribution has changed.

  Previous version: 4.1.3-8
  Current version:  4.1.4-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.


From netmatters at gmail.com  Mon Feb 18 10:04:04 2013
From: netmatters at gmail.com (Gavin)
Date: Mon, 18 Feb 2013 12:04:04 +0200
Subject: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks
	domU networking
Message-ID: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>

Hi,

Firstly I apologise for the cross-post, however I don't expect to get as
quick a response from the package maintainers as I do from the Debian
community, and this issue affects a service that I've got scheduled to go
live at midnight this evening. :(

A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to version
4.1.3-8 on Debian Wheezy has caused all vm's on this host to not receive
their arp replies anymore and as such they cannot reach their gateways and
are now isolated from the network.

There was a more recent update as well (4.1.4-2) which I have now since
applied however this particular issue persists.

The arp replies are received by the host and passed all the way up to the
bridge (br200) being used by Xen, however they are not seen on the vif
(vif2.0) created for the particular vm.

If I statically add the arp entry to the vm all starts working, ie: vm is
no longer isolated and is now connected to the world, but we all know that
this is not an ideal workaround.

This was working perfectly before this update. :(

1) Please let me know if I should roll-back this particular xen update,
kernel and all, and what those steps may be, or if this is a known issue
with a particular workaround that I can apply.

2) Would moving to openvswitch be another possible workaround?

My config:-

Bonded ethernet connected to trunks on Cisco 3750 stack with connection as
follows:-

eth0 --> bond0
eth1 --> bond0 --> br200 --> vif2.0

/etc/network/interfaces:-

iface bond0 inet manual
        slaves eth0 eth1
        bond_mode 5
        bond-miimon 100
        bond-downdelay 200
        bond-updelay 200

auto br200
iface br200 inet static
        address 172.31.1.66
        gateway 172.31.1.65
        netmask 255.255.255.240
        bridge_ports bond0
        bridge_maxwait 0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

root at scjhb01:/home/gavin# brctl show
bridge name bridge id STP enabled interfaces
br200 8000.d4bed9f309a1 no bond0
vif2.0

root at scjhb01:/home/gavin# tcpdump -i bond0 'arp'
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:26:00.287489 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:00.287524 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:00.287669 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46
11:26:01.303484 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:01.303518 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:01.303674 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46
11:26:02.303484 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:02.303518 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:02.303579 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46


root at scjhb01:/home/gavin# tcpdump -i br200 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br200, link-type EN10MB (Ethernet), capture size 65535 bytes
11:26:15.367489 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:15.367514 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:15.367580 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46
11:26:16.383476 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:16.383511 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:16.383592 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46
11:26:17.383486 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:17.383520 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:17.383616 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui
Unknown), length 46


root at scjhb01:/home/gavin# tcpdump -i vif2.0 'arp'
tcpdump: WARNING: vif2.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif2.0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:26:31.463481 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:31.463521 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:32.463480 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:32.463521 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:33.463477 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:33.463515 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:34.479482 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:34.479523 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46
11:26:35.479478 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28
11:26:35.479515 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46

Thanks and Regards.
Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130218/b7ab704f/attachment.html>

From ijc at hellion.org.uk  Mon Feb 18 10:50:01 2013
From: ijc at hellion.org.uk (Ian Campbell)
Date: Mon, 18 Feb 2013 10:50:01 +0000
Subject: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy
 breaks domU networking
In-Reply-To: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>
References: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>
Message-ID: <1361184601.31407.144.camel@zakaz.uk.xensource.com>

On Mon, 2013-02-18 at 12:04 +0200, Gavin wrote:


> Firstly I apologise for the cross-post,

I've added xen-users since you also bounced this there.

>  however I don't expect to get as quick a response from the package
> maintainers as I do from the Debian community, and this issue affects
> a service that I've got scheduled to go live at midnight this
> evening. :(
> 
> 
> A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to
> version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to
> not receive their arp replies anymore and as such they cannot reach
> their gateways and are now isolated from the network.
> 
> 
> There was a more recent update as well (4.1.4-2) which I have now
> since applied however this particular issue persists.

Networking level stuff is all done by the dom0 (or driver domain) kernel
rather than the hypervisor so it is far more likely that a kernel level
change rather than a hypervisor change would be responsible. What kernel
version are you running? Did it also change?

> The arp replies are received by the host and passed all the way up to
> the bridge (br200) being used by Xen, however they are not seen on the
> vif (vif2.0) created for the particular vm.

Do you have any firewall or ebfilter entries which might have either
been discarded or reintroduced by the reboot? (i.e. a manual settings
modification which wasn't propagated to the startup scripts). Or perhaps
sysctl tweaks?

> 1) Please let me know if I should roll-back this particular xen
> update, kernel and all, and what those steps may be, or if this is a
> known issue with a particular workaround that I can apply.

I'd certainly be tempted to try the older kernel, assuming that was also
upgraded. It may even still be installed and in your grub menu already.

> 2) Would moving to openvswitch be another possible workaround? 

Without knowing what the underlying issue is it is hard to predict
whether it will also affect ovs.

> My config:-  

Looks correct to me.

Ian.






From netmatters at gmail.com  Mon Feb 18 11:40:38 2013
From: netmatters at gmail.com (Gavin)
Date: Mon, 18 Feb 2013 13:40:38 +0200
Subject: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy
 breaks domU networking
In-Reply-To: <1361184601.31407.144.camel@zakaz.uk.xensource.com>
References: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>
	<1361184601.31407.144.camel@zakaz.uk.xensource.com>
Message-ID: <CAN=HbLLwEE2DODxH6CoxEP-LcPH-XpciyyKL3jgO2qGLrxhrHw@mail.gmail.com>

On 18 February 2013 12:50, Ian Campbell <ijc at hellion.org.uk> wrote:

> On Mon, 2013-02-18 at 12:04 +0200, Gavin wrote:
>
>
> > Firstly I apologise for the cross-post,
>
> I've added xen-users since you also bounced this there.
>

Thanks. :-/  Thanks too for your quick reply.

>
> >  however I don't expect to get as quick a response from the package
> > maintainers as I do from the Debian community, and this issue affects
> > a service that I've got scheduled to go live at midnight this
> > evening. :(
> >
> >
> > A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to
> > version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to
> > not receive their arp replies anymore and as such they cannot reach
> > their gateways and are now isolated from the network.
> >
> >
> > There was a more recent update as well (4.1.4-2) which I have now
> > since applied however this particular issue persists.
>
> Networking level stuff is all done by the dom0 (or driver domain) kernel
> rather than the hypervisor so it is far more likely that a kernel level
> change rather than a hypervisor change would be responsible. What kernel
> version are you running? Did it also change?
>

This makes sense, although when I did the apt-get upgrade, there was no
kernel update, however there may have been packages/drivers that required a
kernel mod.

Here is the apt history which details what was upgraded when this broke:-

Upgrade: dnsmasq-base:amd64 (2.62-3, 2.62-3+deb7u1), tasksel-data:amd64
(3.14, 3.14+nmu1), xen-hypervisor-4.1-amd64:amd64 (4.1.3-7, 4.1.3-8),
xen-utils-common:amd64 (4.1.3-7, 4.1.3-8), perl:amd64 (5.14.2-16,
5.14.2-17), firmware-linux-free:amd64 (3.1, 3.2), perl-base:amd64
(5.14.2-16, 5.14.2-17), xen-utils-4.1:amd64 (4.1.3-7, 4.1.3-8),
libgnutls26:amd64 (2.12.20-2, 2.12.20-4), perl-modules:amd64 (5.14.2-16,
5.14.2-17), psmisc:amd64 (22.19-1, 22.19-1+deb7u1), python2.6:amd64
(2.6.8-0.2, 2.6.8-1.1), libxenstore3.0:amd64 (4.1.3-7, 4.1.3-8),
python2.6-minimal:amd64 (2.6.8-0.2, 2.6.8-1.1), coreutils:amd64 (8.13-3.4,
8.13-3.5), libvirt0:amd64 (0.9.12-5, 0.9.12-6), libcurl3:amd64 (7.26.0-1,
7.26.0-1+wheezy1), manpages:amd64 (3.42-1, 3.44-1), tasksel:amd64 (3.14,
3.14+nmu1), libperl5.14:amd64 (5.14.2-16, 5.14.2-17),
libsystemd-login0:amd64 (44-7, 44-8), libxen-4.1:amd64 (4.1.3-7, 4.1.3-8),
libcurl3-gnutls:amd64 (7.26.0-1, 7.26.0-1+wheezy1), host:amd64
(9.8.4.dfsg.P1-1, 9.8.4.dfsg.P1-4), libvirt-bin:amd64 (0.9.12-5, 0.9.12-6),
rinse:amd64 (2.0-1, 2.0.1-1), ca-certificates:amd64 (20120623, 20130119),
xenstore-utils:amd64 (4.1.3-7, 4.1.3-8)

The kernel I am using is: 3.2.0-2-amd64, also tried 3.2.0-4-amd64 on
another host with no success.

Would the upgrade above of xen-hypervisor-4.1-amd64 on this Debian system
not cause the Dom0 kernel to be changed in any way ??


> > The arp replies are received by the host and passed all the way up to
> > the bridge (br200) being used by Xen, however they are not seen on the
> > vif (vif2.0) created for the particular vm.
>
> Do you have any firewall or ebfilter entries which might have either
> been discarded or reintroduced by the reboot? (i.e. a manual settings
> modification which wasn't propagated to the startup scripts). Or perhaps
> sysctl tweaks?
>

Nope, not using iptables/ebtables, this was working 100% until the apt
upgrade above.

After this broke I did try and add the following to /etc/sysctl.conf but it
made no difference:-

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

It did add iptables rules but made no difference to this issue.


>
> > 1) Please let me know if I should roll-back this particular xen
> > update, kernel and all, and what those steps may be, or if this is a
> > known issue with a particular workaround that I can apply.
>
> I'd certainly be tempted to try the older kernel, assuming that was also
> upgraded. It may even still be installed and in your grub menu already.
>

The problem is now we are using grub2 and it appears that on boot grub
loads a Linux menu, then the Xen Menu with configs in /etc/grub.d/ so I'm
battling to figure out how to do this.

I also do not have physical access to this host at the moment so need to
set the boot order 'correctly' prior to a reboot.

>
> > 2) Would moving to openvswitch be another possible workaround?
>
> Without knowing what the underlying issue is it is hard to predict
> whether it will also affect ovs.
>

Agreed.

>
> > My config:-
>
> Looks correct to me.
>
> Ian.
>

Thanks Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130218/a0a2298a/attachment-0001.html>

From netmatters at gmail.com  Mon Feb 18 13:51:12 2013
From: netmatters at gmail.com (Gavin)
Date: Mon, 18 Feb 2013 15:51:12 +0200
Subject: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy
 breaks domU networking
In-Reply-To: <CAN=HbLLwEE2DODxH6CoxEP-LcPH-XpciyyKL3jgO2qGLrxhrHw@mail.gmail.com>
References: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>
	<1361184601.31407.144.camel@zakaz.uk.xensource.com>
	<CAN=HbLLwEE2DODxH6CoxEP-LcPH-XpciyyKL3jgO2qGLrxhrHw@mail.gmail.com>
Message-ID: <CAN=HbLLo9Jp7Wx3X3Gz1tKKQaxrPbgZoVtTv=4shdqvtMGcg3w@mail.gmail.com>

On 18 February 2013 13:40, Gavin <netmatters at gmail.com> wrote:

> On 18 February 2013 12:50, Ian Campbell <ijc at hellion.org.uk> wrote:
>
>>
>> Networking level stuff is all done by the dom0 (or driver domain) kernel
>> rather than the hypervisor so it is far more likely that a kernel level
>> change rather than a hypervisor change would be responsible. What kernel
>> version are you running? Did it also change?
>>
>
> This makes sense, although when I did the apt-get upgrade, there was no
> kernel update, however there may have been packages/drivers that required a
> kernel mod.
>
> Here is the apt history which details what was upgraded when this broke:-
>
> Upgrade: xen-hypervisor-4.1-amd64:amd64 (4.1.3-7, 4.1.3-8)
>
> The kernel I am using is: 3.2.0-2-amd64, also tried 3.2.0-4-amd64 on
> another host with no success.
>
> Would the upgrade above of xen-hypervisor-4.1-amd64 on this Debian system
> not cause the Dom0 kernel to be changed in any way ??
>
>>
>> > 1) Please let me know if I should roll-back this particular xen
>> > update, kernel and all, and what those steps may be, or if this is a
>> > known issue with a particular workaround that I can apply.
>>
>> I'd certainly be tempted to try the older kernel, assuming that was also
>> upgraded. It may even still be installed and in your grub menu already.
>>
>
> The problem is now we are using grub2 and it appears that on boot grub
> loads a Linux menu, then the Xen Menu with configs in /etc/grub.d/ so I'm
> battling to figure out how to do this.
>
> I also do not have physical access to this host at the moment so need to
> set the boot order 'correctly' prior to a reboot.
>

I managed to get iDRAC console access and on further inspection it appears
that grub first boots xen-4.1-amd64.gz and then the Linux kernel.

When I updated the Xen Hypervisor does it not also upgrade the
xen-4.1-amd64.gz file ??

Are there any better ways to trace where this arp reply is being lost apart
from just tcpdump ?

None of the log files are reporting back any errors and my googling just
does not seem to return any useful results.

<stumped! />
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130218/93f1b3f7/attachment.html>

From ijc at hellion.org.uk  Mon Feb 18 14:32:17 2013
From: ijc at hellion.org.uk (Ian Campbell)
Date: Mon, 18 Feb 2013 14:32:17 +0000
Subject: [Pkg-xen-devel] [Xen-users] Recent hypervisor update on Debian
 Wheezy breaks domU networking
In-Reply-To: <CAN=HbLLo9Jp7Wx3X3Gz1tKKQaxrPbgZoVtTv=4shdqvtMGcg3w@mail.gmail.com>
References: <CAN=HbL+V4FO7cEWVepsU-hD=Lw=+GE8-4yXbesQPzhiQi0dMFg@mail.gmail.com>
	<1361184601.31407.144.camel@zakaz.uk.xensource.com>
	<CAN=HbLLwEE2DODxH6CoxEP-LcPH-XpciyyKL3jgO2qGLrxhrHw@mail.gmail.com>
	<CAN=HbLLo9Jp7Wx3X3Gz1tKKQaxrPbgZoVtTv=4shdqvtMGcg3w@mail.gmail.com>
Message-ID: <1361197937.32047.13.camel@zakaz.uk.xensource.com>

On Mon, 2013-02-18 at 13:51 +0000, Gavin wrote:


> I managed to get iDRAC console access and on further inspection it
> appears that grub first boots xen-4.1-amd64.gz and then the Linux
> kernel.

Correct.

> When I updated the Xen Hypervisor does it not also upgrade the
> xen-4.1-amd64.gz file ?? 

Yes. Unless the version number changes in which case you get a new file
in addition to the older version, but that doesn't apply here.

> Are there any better ways to trace where this arp reply is being lost
> apart from just tcpdump ? 

tcpdump is what I would use.

> <stumped! />

If the kenrel hasn't changed and you are 100% sure the network
configuration before and after the reboot is the same then so am I.

All I can suggest is to reinstall the previous version of Xen.

Ian.



-- 
Ian Campbell
Current Noise: Karma To Burn - Thirty Five

America, how can I write a holy litany in your silly mood?
		-- Allen Ginsberg



From netmatters at gmail.com  Mon Feb 18 16:32:07 2013
From: netmatters at gmail.com (Gavin)
Date: Mon, 18 Feb 2013 18:32:07 +0200
Subject: [Pkg-xen-devel] [SOLVED] Re: [Xen-users] Recent hypervisor update
 on Debian Wheezy breaks domU networking
Message-ID: <CAN=HbL+TL8K4jQ+SaJXD8sCFdr7pDOPLGsNUoGv5LSeMduYemw@mail.gmail.com>

On 18 February 2013 16:32, Ian Campbell <ijc at hellion.org.uk> wrote:

> On Mon, 2013-02-18 at 13:51 +0000, Gavin wrote:
>
> > <stumped! />
>
> If the kernel hasn't changed and you are 100% sure the network
> configuration before and after the reboot is the same then so am I.
>
> All I can suggest is to reinstall the previous version of Xen.
>

Thanks very much for all your assistance Ian, the problem was with the
network.

We introduced  a second switch into the stack and it seems like it was our
bond interface to the switch that caused this particular issue.

We were using bond mode 5 since that works for us elsewhere and did not
think that this could be the problem since we were seeing the arp-replies
reach the host bridge interface.

As per Xen recommendations I tried mode 7 but that too did not work.

Once configured to use bond mode 1 (active-backup) this all started working
again.

Apologies for the run-around, the false accusations and also the
cross-posting, have a few hours before going live with this platform and
was under a fair amount of pressure.

All good now!!  :)

Regards,
Gavin

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130218/529f605b/attachment.html>

From mike.mcclurg at gmail.com  Mon Feb 18 18:02:35 2013
From: mike.mcclurg at gmail.com (Mike McClurg)
Date: Mon, 18 Feb 2013 18:02:35 +0000
Subject: [Pkg-xen-devel] Bug#695221:  Bug#695221: confirmed bug, serious
In-Reply-To: <5119B564.1070008@debian.org>
References: <5117C07F.6000703@pocock.com.au> <51185BF2.7080406@debian.org>
	<5118AA49.4040008@pocock.com.au> <5119B564.1070008@debian.org>
Message-ID: <CALru5wUigNbo3Q9Y5vEL2MgEj1YUQazxfEPMXYLRdoe8CLKQVw@mail.gmail.com>

Hi all,

Sorry for top posting. I spoke with Rob, the author of xcp-networkd, who
thinks that he's fixed this bug in a later upstream release. We'll take a
look at the repo tomorrow and see if we can find the commit that fixes this
issue.

Mike


On Tue, Feb 12, 2013 at 3:22 AM, Thomas Goirand <zigo at debian.org> wrote:

> On 02/11/2013 04:22 PM, Daniel Pocock wrote:
> > Having it marked RC may allow a patch into wheezy.
>
> Marking it RC is only delaying the release, that's it. I have already
> fixed multiple bugs which were not marked as RC, and the release team
> accepted the changes. Even after Wheezy is released, it is possible to
> fix problems in the stable distribution.
>
> > Maybe even a small patch:
>
> A small patch is what we should all aim at. I'm sure the problem isn't
> so complicated, and that we can fix it.
>
> Of course, it would help if Mike and Jon were a bit more cooperative and
> were trying to fix the issue, but it seems they are quite busy these
> days (or maybe in holidays?).
>
> >
> > - updating the README
> >
> > - changing pif-reconfigure-ip to give an error if the user tries a
> > netmask that is not supported, e.g.
> >
> > "XCP only works on a Class C subnet with a netmask 255.255.255.0.  Your
> > changes have not been applied.
> > See bug 695221 or the README file."
>
> Yeah, I think that is indeed a good idea to write this!
>
> > These things would be small fixes but would make the user's first
> > experience of XCP less frustrating
> >
> > The last thing you want is for people to get frustrated and start
> > thinking that they should try the Ubuntu version or the ISO installer:
> > http://www.xen.org/download/xcp/index_1.6.0.html#install
>
> Well, yes, I would like to have more Debian users, and that people use
> less XCP from the ISO installer (eg: CentOS based). However, the Ubuntu
> package of XCP is synced from Debian, so these are the exact same
> package (with only a possible delay in having the Ubuntu package).
> Nobody in Ubuntu works on the XCP packaging, the work is only been done
> by myself in Debian.
>
> >> Ultimately, this is the job of the maintainer of a given package to
> >> decide the seriousness of a bug. To me, setting it to either normal or
> >> important is exactly the same (eg: it is on my radar, and I really want
> >> to have it fix), and discussing the seriousness doesn't help. Discussing
> >> ways to fix it does.
> >
> > It's not quite the same, because the release team wouldn't accept a
> > patch/unblock request for a normal issue
>
> This statement is completely wrong. The criteria for the release team to
> accept changes is not the severity of a bug only. If we find a way to
> fix this problem, I'm quite sure that the release team will accept the
> patch, regardless of the severity set in the BTS.
>
> > I'm hoping that the fix for this might be quite trivial and therefore
> > acceptable to the release team.
>
> Yeah, that's more in line! If the fix is small, and even trivial, and
> easy to review for them (which is quite likely to be the case,
> considering that just fixing the db with an editor fixed it for you),
> then they will accept it.
>
> I'm also quite sure that they would accept any documentation change at
> this point of the release.
>
> Cheers,
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130218/ca234edf/attachment-0001.html>

From isidoro at mis-consults.com.es  Wed Feb 20 08:56:16 2013
From: isidoro at mis-consults.com.es (Barr. Ernesto L. Isidoro [Hispanic Chambers])
Date: Wed, 20 Feb 2013 09:56:16 +0100
Subject: [Pkg-xen-devel] This Is Our Last Notice To You.
Message-ID: <3256645588481679330204@justina-da80b57>

An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130220/bc7ff6cf/attachment.html>

From 90 at 4.exbusines.com  Fri Feb 22 02:26:54 2013
From: 90 at 4.exbusines.com (Hat box Supply)
Date: Fri, 22 Feb 2013 02:26:54 +0000
Subject: [Pkg-xen-devel] =?gb2312?b?SGF0IGJveCBTdXBwbHnT68T6ubLP7cHLz+A=?=
	=?gb2312?b?suGhow==?=
Message-ID: <047d7b86f310b94c7d04d646ec4f@google.com>

Dear friends,

How are you doing?
Are you looking for a good cooperation partner in China for leather hat box?
If so, bingo! Just contact with us!

Who we are?---A manufacturer of leather storage items in China, we called  
Focus Innovation Gifts Company
History??The Company has been set up since 2004, owing rich experience in  
this area

The reason you will choose us:
1. Competitive price, so the buyer can win more in the market,
2. 100% quality assurance, the goods are 100% inspected before shipment
3.Sample can be provided as per customer request
4.Good service and communication, our sales team with rich experience in  
foreign trade, can
talk by phone in English
5. prompt delivery and Excellent service


Best Regards,
Miss Stephanie
Warmly Tips? Our MOQ is 500pcs/item, if you are looking for a manufacturer  
to provide customer hat box, whether you are a wholesaler or retailer , if  
the quantity can reach our MOQ, why not contact wit us?



Pls view below pictures for our products:
Leather hat box?

https://picasaweb.google.com/lh/sredir?uname=102408115266403620672&target=ALBUM&id=5846889991826052689&authkey=Gv1sRgCMPut7Sitvrl4wE&invite=CLnP6sAH&feat=email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130222/a4231185/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picasaweblogo-zh_CN.gif
Type: image/gif
Size: 1646 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130222/a4231185/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.jpg
Type: image/jpeg
Size: 5695 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130222/a4231185/attachment.jpg>

From hex445 at gmail.com  Fri Feb 22 21:50:53 2013
From: hex445 at gmail.com (T)
Date: Fri, 22 Feb 2013 22:50:53 +0100
Subject: [Pkg-xen-devel] Bug#701213: Hvm domU doesn't boot after dom0 reboot
	under Debian Wheezy
Message-ID: <CACnni4g5qsCx-q1t-notDs6sScj2qkqoVe9mL=nbhHeTSeoXXw@mail.gmail.com>

Package: xen-hypervisor-4.1-amd64
Version: 4.1.4-2

Hi,

Hvm domU does not starts up afer dom0 reboot.

Bridge br0 is set up manually.

Dom0: Debian Wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
DomU: Debian Squeeze 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC
2012 x86_64 GNU/Linux
config:
===<========
kernel = '/usr/lib/xen-4.1/boot/hvmloader'
builder = 'hvm'
vcpus = '1'
memory = '512'
maxmem = '512'
disk = ['phy:/dev/vg0/hvm1.disk,hda,w']

name = 'hvm1'

vif = [ 'mac=xx:xx:xx:xx:xx:xx, bridge=br0, model=e1000' ]

boot = 'c'
acpi = '1'
apic = '1'
xen_platform_pci='1'
sdl = '0'
vnc = '0'
#vnclisten = '0.0.0.0'
usb = '1'
usbdevice = 'host:12d1:1003'

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
===>=====

/var/log/xen/qemu-dm-hvm1.log:
domid: 8
-c config qemu network with xen bridge for
vif8.0-emu br0
RTNETLINK answers: Device or resource busy
device vif8.0-emu is already a member of a bridge; can't enslave it to
bridge br0.
/etc/xen/scripts/qemu-ifup: could not launch network script
Could not initialize device 'tap'

Starting hvm domU manually works as expected.

--
T


From doko at debian.org  Sat Feb 23 11:20:07 2013
From: doko at debian.org (Matthias Klose)
Date: Sat, 23 Feb 2013 11:20:07 +0000
Subject: [Pkg-xen-devel] Bug#701248: blktap: ftbfs with GCC-4.8
Message-ID: <E1U9D9D-0001yF-OO@ravel.debian.org>

Package: src:blktap
Version: 2.0.90-1
Severity: important
Tags: sid jessie
User: debian-gcc at lists.debian.org
Usertags: ftbfs-gcc-4.8

The package fails to build in a test rebuild on at least amd64 with
gcc-4.8/g++-4.8, but succeeds to build with gcc-4.7/g++-4.7. The
severity of this report may be raised before the jessie release.

  tapdisk-logfile.c:166:23: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to dereference it? [-Werror=sizeof-pointer-memaccess]

The full build log can be found at:
http://people.debian.org/~doko/logs-20130217/gcc48/blktap_2.0.90-1_unstable_gcc48.log
The last lines of the build log are at the end of this report.

To build with GCC 4.8, either set CC=gcc-4.8 CXX=g++-4.8 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t experimental install g++ g++-4.7 g++-4.8 libc6-dev

The test rebuild was done with eglibc-2.17 and GCC-4.8, so some issues
might be caused by the updated glibc.

[...]
cc1: all warnings being treated as errors
make[4]: *** [tapdisk-logfile.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-disktype.lo -MD -MP -MF .deps/tapdisk-disktype.Tpo -c tapdisk-disktype.c  -fPIC -DPIC -o tapdisk-disktype.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-loglimit.lo -MD -MP -MF .deps/tapdisk-loglimit.Tpo -c tapdisk-loglimit.c  -fPIC -DPIC -o tapdisk-loglimit.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-storage.lo -MD -MP -MF .deps/tapdisk-storage.Tpo -c tapdisk-storage.c  -fPIC -DPIC -o tapdisk-storage.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-driver.lo -MD -MP -MF .deps/tapdisk-driver.Tpo -c tapdisk-driver.c  -fPIC -DPIC -o tapdisk-driver.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-stats.lo -MD -MP -MF .deps/tapdisk-stats.Tpo -c tapdisk-stats.c  -fPIC -DPIC -o tapdisk-stats.o >/dev/null 2>&1
mv -f .deps/tapdisk-disktype.Tpo .deps/tapdisk-disktype.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-log.lo -MD -MP -MF .deps/tapdisk-log.Tpo -c tapdisk-log.c  -fPIC -DPIC -o tapdisk-log.o >/dev/null 2>&1
mv -f .deps/tapdisk-loglimit.Tpo .deps/tapdisk-loglimit.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-interface.lo -MD -MP -MF .deps/tapdisk-interface.Tpo -c tapdisk-interface.c  -fPIC -DPIC -o tapdisk-interface.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-utils.lo -MD -MP -MF .deps/tapdisk-utils.Tpo -c tapdisk-utils.c  -fPIC -DPIC -o tapdisk-utils.o >/dev/null 2>&1
mv -f .deps/tapdisk-storage.Tpo .deps/tapdisk-storage.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT scheduler.lo -MD -MP -MF .deps/scheduler.Tpo -c scheduler.c  -fPIC -DPIC -o scheduler.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-filter.lo -MD -MP -MF .deps/tapdisk-filter.Tpo -c tapdisk-filter.c  -fPIC -DPIC -o tapdisk-filter.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT io-optimize.lo -MD -MP -MF .deps/io-optimize.Tpo -c io-optimize.c  -fPIC -DPIC -o io-optimize.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-syslog.lo -MD -MP -MF .deps/tapdisk-syslog.Tpo -c tapdisk-syslog.c  -fPIC -DPIC -o tapdisk-syslog.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-server.lo -MD -MP -MF .deps/tapdisk-server.Tpo -c tapdisk-server.c  -fPIC -DPIC -o tapdisk-server.o >/dev/null 2>&1
mv -f .deps/tapdisk-driver.Tpo .deps/tapdisk-driver.Plo
mv -f .deps/tapdisk-stats.Tpo .deps/tapdisk-stats.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-image.lo -MD -MP -MF .deps/tapdisk-image.Tpo -c tapdisk-image.c  -fPIC -DPIC -o tapdisk-image.o >/dev/null 2>&1
mv -f .deps/tapdisk-log.Tpo .deps/tapdisk-log.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-queue.lo -MD -MP -MF .deps/tapdisk-queue.Tpo -c tapdisk-queue.c  -fPIC -DPIC -o tapdisk-queue.o >/dev/null 2>&1
mv -f .deps/tapdisk-interface.Tpo .deps/tapdisk-interface.Plo
mv -f .deps/tapdisk-utils.Tpo .deps/tapdisk-utils.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT lock.lo -MD -MP -MF .deps/lock.Tpo -c lock.c  -fPIC -DPIC -o lock.o >/dev/null 2>&1
mv -f .deps/tapdisk-filter.Tpo .deps/tapdisk-filter.Plo
mv -f .deps/scheduler.Tpo .deps/scheduler.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-control.lo -MD -MP -MF .deps/tapdisk-control.Tpo -c tapdisk-control.c  -fPIC -DPIC -o tapdisk-control.o >/dev/null 2>&1
mv -f .deps/io-optimize.Tpo .deps/io-optimize.Plo
mv -f .deps/tapdisk-syslog.Tpo .deps/tapdisk-syslog.Plo
mv -f .deps/tapdisk-server.Tpo .deps/tapdisk-server.Plo
mv -f .deps/tapdisk-image.Tpo .deps/tapdisk-image.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-vbd.lo -MD -MP -MF .deps/tapdisk-vbd.Tpo -c tapdisk-vbd.c  -fPIC -DPIC -o tapdisk-vbd.o >/dev/null 2>&1
mv -f .deps/tapdisk-queue.Tpo .deps/tapdisk-queue.Plo
mv -f .deps/lock.Tpo .deps/lock.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../include -Wall -Werror -g -O2 -MT tapdisk-blktap.lo -MD -MP -MF .deps/tapdisk-blktap.Tpo -c tapdisk-blktap.c  -fPIC -DPIC -o tapdisk-blktap.o >/dev/null 2>&1
mv -f .deps/tapdisk-control.Tpo .deps/tapdisk-control.Plo
mv -f .deps/tapdisk-vbd.Tpo .deps/tapdisk-vbd.Plo
mv -f .deps/tapdisk-blktap.Tpo .deps/tapdisk-blktap.Plo
make[4]: Leaving directory `/??PKGBUILDDIR??/drivers'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/??PKGBUILDDIR??'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/??PKGBUILDDIR??'
make[1]: *** [override_dh_auto_build] Error 2
make: *** [build-arch] Error 2
make[1]: Leaving directory `/??PKGBUILDDIR??'
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


From doko at debian.org  Sat Feb 23 11:35:47 2013
From: doko at debian.org (Matthias Klose)
Date: Sat, 23 Feb 2013 11:35:47 +0000
Subject: [Pkg-xen-devel] Bug#701445: xcp-vncterm: ftbfs with eglibc-2.17
Message-ID: <E1U9DON-000444-1h@ravel.debian.org>

Package: src:xcp-vncterm
Version: 0.1-2
Severity: important
Tags: sid jessie
User: debian-glibc at lists.debian.org
Usertags: ftbfs-glibc-2.17

The package fails to build in a test rebuild on at least amd64 with
eglibc-2.17, but succeeds to build with eglibc-2.13. The
severity of this report may be raised before the jessie release.

The test rebuild was done together with GCC-4.8, so some issues
might be caused by the updated GCC as well.

  main.c:545:19: error: storage size of 'rlim' isn't known

The full build log can be found at:
http://people.debian.org/~doko/logs-20130217/gcc48/xcp-vncterm_0.1-2_unstable_gcc48.log
The last lines of the build log are at the end of this report.

To install eglibc from experimental,

  apt-get -t experimental install libc6-dev

To build with GCC 4.8, either set CC=gcc-4.8 CXX=g++-4.8 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t experimental install g++ g++-4.7 g++-4.8 libc6-dev


[...]
rm -f TAGS
make[1]: Leaving directory `/??PKGBUILDDIR??'
   dh_clean
 debian/rules build-arch
dh build-arch 
   dh_testdir -a
   dh_auto_configure -a
   dh_auto_build -a
make[1]: Entering directory `/??PKGBUILDDIR??'
make -C libvnc
make[2]: Entering directory `/??PKGBUILDDIR??/libvnc'
cc  -I/??PKGBUILDDIR??/libvnc/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -Wall -Werror -g -O1 -Wp,-MD,./.d3des.o.d -c -o d3des.o d3des.c
cc  -I/??PKGBUILDDIR??/libvnc/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -Wall -Werror -g -O1 -Wp,-MD,./.buffer.o.d -c -o buffer.o buffer.c
cc  -I/??PKGBUILDDIR??/libvnc/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -Wall -Werror -g -O1 -Wp,-MD,./.vnc.o.d -c -o vnc.o vnc.c
cc  -I/??PKGBUILDDIR??/libvnc/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -Wall -Werror -g -O1 -Wp,-MD,./.textterm.o.d -c -o textterm.o textterm.c
ar rcs libvnc.a d3des.o buffer.o vnc.o textterm.o
make[2]: Leaving directory `/??PKGBUILDDIR??/libvnc'
gcc -o main.o -I/??PKGBUILDDIR??/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE  -Wall -g -O1  -Wp,-MD,./.main.o.d -c main.c
main.c: In function 'sigxfsz_handler':
main.c:545:19: error: storage size of 'rlim' isn't known
     struct rlimit rlim;
                   ^
main.c:547:5: warning: implicit declaration of function 'getrlimit' [-Wimplicit-function-declaration]
     getrlimit(RLIMIT_FSIZE, &rlim);
     ^
main.c:547:15: error: 'RLIMIT_FSIZE' undeclared (first use in this function)
     getrlimit(RLIMIT_FSIZE, &rlim);
               ^
main.c:547:15: note: each undeclared identifier is reported only once for each function it appears in
main.c:549:5: warning: implicit declaration of function 'setrlimit' [-Wimplicit-function-declaration]
     setrlimit(RLIMIT_FSIZE, &rlim);
     ^
main.c:545:19: warning: unused variable 'rlim' [-Wunused-variable]
     struct rlimit rlim;
                   ^
main.c: In function 'main':
main.c:932:27: error: storage size of 'rlim' isn't known
             struct rlimit rlim;
                           ^
main.c:940:23: error: 'RLIMIT_FSIZE' undeclared (first use in this function)
             setrlimit(RLIMIT_FSIZE, &rlim);
                       ^
main.c:932:27: warning: unused variable 'rlim' [-Wunused-variable]
             struct rlimit rlim;
                           ^
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/??PKGBUILDDIR??'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


From atomo64 at gmail.com  Sun Feb 24 12:50:39 2013
From: atomo64 at gmail.com (Raphael Geissert)
Date: Sun, 24 Feb 2013 13:50:39 +0100
Subject: [Pkg-xen-devel] Bug#701554: xcp-xapi: bashism in /bin/sh script
Message-ID: <201302241350.40281.atomo64@gmail.com>

Package: xcp-xapi
Version: 1.3.2-14
Severity: important
User: debian-release at lists.debian.org
Usertags: goal-dash

Hello maintainer,

While performing an archive wide checkbashisms (from the 'devscripts' 
package) check I've found your package containing a /bin/sh script making 
use of a bashism.

checkbashisms' output:
>possible bashism in ./usr/lib/xcp/lib/host-restore line 26 (trap with ERR|
>DEBUG|RETURN):
>      trap - EXIT ERR
>possible bashism in ./usr/lib/xcp/lib/host-restore line 31 (trap with ERR|
>DEBUG|RETURN):
>trap error EXIT ERR

Not using bash (or a Debian Policy conformant shell interpreter which 
doesn't provide such an extra feature) as /bin/sh is likely to lead to 
errors or unexpected behaviours.

You can find hints about how to fix bashisms at:
https://wiki.ubuntu.com/DashAsBinSh

Thank you,
Raphael Geissert


From christian.suenkenberg at student.kit.edu  Mon Feb 25 17:44:20 2013
From: christian.suenkenberg at student.kit.edu (Christian =?UTF-8?Q?S=C3=BCnkenberg?=)
Date: Mon, 25 Feb 2013 18:44:20 +0100
Subject: [Pkg-xen-devel] Bug#684661: Workaround, patch and full trace
Message-ID: <512BA2F4.6070108@student.kit.edu>

Hi,

I've also recently hit this bug und it should be fixed by [1],
also see the original analysis at [2].

Passing "allow_unsafe" as a Hypervisor option circumvents the crash.

A serial boot log is attached.

[1]: http://lists.xen.org/archives/html/xen-devel/2012-10/msg01856.html
[2]: http://lists.xen.org/archives/html/xen-devel/2012-10/msg01396.html

Regards,
Christian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bootlog-xen-4.1-opteron-175-iommu-crash.log
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130225/780d04f3/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5002 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130225/780d04f3/attachment-0001.bin>

From owner at bugs.debian.org  Mon Feb 25 18:27:09 2013
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Mon, 25 Feb 2013 18:27:09 +0000
Subject: [Pkg-xen-devel] Bug#684661: marked as done (Xen panic on boot)
References: <20130225182257.GA4379@waldi.eu.org> <5027CAFE.6020506@gmx.net>
Message-ID: <handler.684661.D684661.13618165819540.ackdone@bugs.debian.org>

Your message dated Mon, 25 Feb 2013 19:22:57 +0100
with message-id <20130225182257.GA4379 at waldi.eu.org>
and subject line Re: [Pkg-xen-devel] Bug#684661: Xen panic on boot
has caused the Debian Bug report #684661,
regarding Xen panic on boot
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 owner at bugs.debian.org
immediately.)


-- 
684661: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684661
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems
-------------- next part --------------
An embedded message was scrubbed...
From: Stephan Beyer <s-beyer at gmx.net>
Subject: Xen panic on boot
Date: Sun, 12 Aug 2012 17:25:50 +0200
Size: 2500
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130225/01309b52/attachment.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: Bastian Blank <waldi at debian.org>
Subject: Re: [Pkg-xen-devel] Bug#684661: Xen panic on boot
Date: Mon, 25 Feb 2013 19:22:57 +0100
Size: 2021
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130225/01309b52/attachment-0001.mht>

From lukas at schwaighofer.name  Mon Feb 25 21:47:49 2013
From: lukas at schwaighofer.name (Lukas Schwaighofer)
Date: Mon, 25 Feb 2013 22:47:49 +0100
Subject: [Pkg-xen-devel] Bug#701672: xen-utils-4.1: add xfs support to pygrub
Message-ID: <20130225214749.8519.71053.reportbug@tank>

Package: xen-utils-4.1
Version: 4.1.4-2
Severity: wishlist
Tags: patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Dear Maintainer,

Please consider adding xfs support to pygrub in xen-utils-4.1. The
version from xen-utils-4.2 from upstream supports xfs and the required
changes are minimal. I am attaching a patch which was constructed by
squashing the following commits together:

5fa9d87e8f1adada24fcaa4f3a8a905defda54cf
393375e7271d4a5576ad740a304f9874d6958990
69698ae65775e8f7a2b789400421cb38dbacced0
321e74e4bc96b34c687b17d5dcb2734f2651eabb

I rebuilt the package on my amd64 system after applying the patch and
it's working for me.

Thanks
Lukas Schwaighofer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRK9wFAAoJEMqNQAGevU6TkdMQAKvnbHKKAJ2BcPPSN3xGc7PF
KwrdP0uHK00ryr0XIzll/1P5BXVkCaExlpK4We9DmbRuo2rJCgb2He8W3/Hm+oPs
aaT2l2ZDyNCtbk7I8rznW8rWM7weG1x1XAt4U/JLxUfQI0CZCwmjDyCYrF2A+XVZ
PgnvfO+MMJz/6O7CpFbpsbOftw7M2OVcX9Wko3hkVO6pNm6Sxhhr+CJqOkQFt0Pu
HPPwrVBGfZ57997p9n0aHVx/R0km81cELg5KB7JuN3ZGhEboe1E5eDfW3l5XsLBG
DFMpnEJ/1IE2JwLQLW9VWtQ6GqhvZ9ROlUCQjbOxQ7lAPh3g4qmDdDUMsheZzgkH
aeuwpyJdBET/V7w1eEHGKrdlUFQ3zuU5Cv1FG+24gOUm8U6/WSJ7E14po3nh6+Rt
jRqgQ2il7prbHTorydtYZApVewbB7SqrtAn0Cf7C2gjWR57SbLtaNehmreNMsGe8
FRI33n9TkTMXpZmjp915YcWcVdcz1CIQTEil+OeQO8olcSvsafu3AA4PUOwSRXrX
44HLxTiQvrzVszRGKTvDJLbUrJF1p3hyW4A0OExTt53jvw+ip5bl/WnjjV4oZGSO
fiiP6+Tn0St0gal+ejOCB3t5E/b8giIrGNjGPCoqQKMEc1ZXmdNVZf+fhKSjTno7
NDR/3mNjhORpmxo+5z8Z
=hYlQ
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pygrub-xfs-support.patch
Type: text/x-diff
Size: 34521 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130225/c3d8bf61/attachment-0001.patch>

From ij at 2013.bluespice.org  Tue Feb 26 17:42:11 2013
From: ij at 2013.bluespice.org (Ingo Juergensmann)
Date: Tue, 26 Feb 2013 18:42:11 +0100
Subject: [Pkg-xen-devel] Bug#701744: [xen] Update to hypervisor 4.0.1-5.6 or
	linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes networking
	(VIF) failures
Message-ID: <512CF3F3.4070202@2013.bluespice.org>

Package: xen
Version: 4.0.1-5.5
Severity: critical

--- Please enter the report below this line. ---

Hi!

Since the update last weekind in stable/squeeze I'm experiencing 
problems with running Xen on amd64 and multiple domUs losing their 
network connection/VIFs.

 From 
http://blog.windfluechter.net/content/blog/2013/02/26/1597-xen-problems-vms-2632-5-xen-amd64

Unfortunately this update appears to be problematic on my Xen hosting 
server. This night it happened the second time that some of the virtual 
network interfaces disappeared or turned out to be non-working. For 
example I have two VMs: one running the webserver and one running the 
databases. Between these two VMs there's a bridge on the dom0 and both 
VMs have a VIF to that (internal) bridge. What happens is that this 
bridge becomes inaccessible from within the webserver VM.

Sadly there's not much to see in the log files. I just spotted this on 
dom0:

     Feb 26 01:01:29 gate kernel: [12697.907512] vif3.1: Frag is bigger 
than frame.
     Feb 26 01:01:29 gate kernel: [12697.907550] vif3.1: fatal error; 
disabling device
     Feb 26 01:01:29 gate kernel: [12697.919921] xenbr1: port 3(vif3.1) 
entering disabled state
     Feb 26 01:22:00 gate kernel: [13928.644888] vif2.1: Frag is bigger 
than frame.
     Feb 26 01:22:00 gate kernel: [13928.644920] vif2.1: fatal error; 
disabling device
     Feb 26 01:22:00 gate kernel: [13928.663571] xenbr1: port 2(vif2.1) 
entering disabled state
     Feb 26 01:40:44 gate kernel: [15052.629280] vif7.1: Frag is bigger 
than frame.
     Feb 26 01:40:44 gate kernel: [15052.629314] vif7.1: fatal error; 
disabling device
     Feb 26 01:40:44 gate kernel: [15052.641725] xenbr1: port 6(vif7.1) 
entering disabled state

This corresponds to the number of VMs having lost their internal 
connection to the bridge. On the webserver VM I see this output:

     Feb 26 01:59:01 vserv1 kernel: [16113.539767] IPv6: sending 
pkt_too_big to self
     Feb 26 01:59:01 vserv1 kernel: [16113.539794] IPv6: sending 
pkt_too_big to self
     Feb 26 02:30:54 vserv1 kernel: [18026.407517] IPv6: sending 
pkt_too_big to self
     Feb 26 02:30:54 vserv1 kernel: [18026.407546] IPv6: sending 
pkt_too_big to self
     Feb 26 02:30:54 vserv1 kernel: [18026.434761] IPv6: sending 
pkt_too_big to self
     Feb 26 02:30:54 vserv1 kernel: [18026.434787] IPv6: sending 
pkt_too_big to self
     Feb 26 03:39:16 vserv1 kernel: [22128.768214] IPv6: sending 
pkt_too_big to self
     Feb 26 03:39:16 vserv1 kernel: [22128.768240] IPv6: sending 
pkt_too_big to self
     Feb 26 04:39:51 vserv1 kernel: [25764.250170] IPv6: sending 
pkt_too_big to self
     Feb 26 04:39:51 vserv1 kernel: [25764.250196] IPv6: sending 
pkt_too_big to self

Rebooting the VMs will result in a non-working VM as it will get paused 
on creation and Xen scripts complain about not working hotplug scripts 
and Xen logs shows this:

     [2013-02-25 13:06:34 5470] DEBUG (XendDomainInfo:101)
     XendDomainInfo.create(['vm', ['name', 'vserv1'], ['memory', '2048'],
     ['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_crash',
     'restart'], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'],
     ['vcpus', '2'], ['oos', 1], ['bootloader', 
'/usr/lib/xen-4.0/bin/pygrub'],
     ['bootloader_args', ''], ['image', ['linux', ['root', '/dev/xvdb '],
     ['videoram', 4], ['tsc_mode', 0], ['nomigrate', 0]]], 
['s3_integrity', 1],
     ['device', ['vbd', ['uname', 'phy:/dev/lv/vserv1-boot'], ['dev', 
'xvda'],
     ['mode', 'w']]], ['device', ['vbd', ['uname', 
'phy:/dev/lv/vserv1-disk'],
     ['dev', 'xvdb'], ['mode', 'w']]], ['device', ['vbd', ['uname',
     'phy:/dev/lv/vserv1-swap'], ['dev', 'xvdc'], ['mode', 'w']]], 
['device',
     ['vbd', ['uname', 'phy:/dev/lv/vserv1mirror'], ['dev', 'xvdd'], 
['mode',
     'w']]]])
     [2013-02-25 13:06:34 5470] DEBUG (XendDomainInfo:2508)
     XendDomainInfo.constructDomain
     [2013-02-25 13:06:34 5470] DEBUG (balloon:220) Balloon: 2100000 KiB 
free;
     need 16384; done.
     [2013-02-25 13:06:34 5470] DEBUG (XendDomain:464) Adding Domain: 39
     [2013-02-25 13:06:34 5470] DEBUG (XendDomainInfo:2818)
     XendDomainInfo.initDomain: 39 256
     [2013-02-25 13:06:34 5781] DEBUG (XendBootloader:113) Launching 
bootloader
     as ['/usr/lib/xen-4.0/bin/pygrub', '--args=root=/dev/xvdb  ',
     '--output=/var/run/xend/boot/xenbl.6040', '/dev/lv/vserv1-boot'].
     [2013-02-25 13:06:39 5470] DEBUG (XendDomainInfo:2845)
     _initDomain:shadow_memory=0x0, memory_static_max=0x80000000,
     memory_static_min=0x0.
     [2013-02-25 13:06:39 5470] INFO (image:182) buildDomain os=linux dom=39
     vcpus=2
     [2013-02-25 13:06:39 5470] DEBUG (image:721) domid	    = 39
     [2013-02-25 13:06:39 5470] DEBUG (image:722) memsize	    = 2048
     [2013-02-25 13:06:39 5470] DEBUG (image:723) image	    =
     /var/run/xend/boot/boot_kernel.xj7W_t
     [2013-02-25 13:06:39 5470] DEBUG (image:724) store_evtchn   = 1
     [2013-02-25 13:06:39 5470] DEBUG (image:725) console_evtchn = 2
     [2013-02-25 13:06:39 5470] DEBUG (image:726) cmdline	    =
     root=UUID=ed71a39f-fd2e-4035-8557-493686baa151 ro root=/dev/xvdb
     [2013-02-25 13:06:39 5470] DEBUG (image:727) ramdisk	    =
     /var/run/xend/boot/boot_ramdisk.QavuAo
     [2013-02-25 13:06:39 5470] DEBUG (image:728) vcpus	    = 2
     [2013-02-25 13:06:39 5470] DEBUG (image:729) features	    =
     [2013-02-25 13:06:39 5470] DEBUG (image:730) flags	    = 0
     [2013-02-25 13:06:39 5470] DEBUG (image:731) superpages     = 0
     [2013-02-25 13:06:40 5470] INFO (XendDomainInfo:2367) createDevice: 
vbd :
     {'uuid': '04d99772-cf27-aecf-2d1b-c73eaf657410', 'bootable': 1, 
'driver':
     'paravirtualised', 'dev': 'xvda', 'uname': 'phy:/dev/lv/vserv1-boot',
     'mode': 'w'}
     [2013-02-25 13:06:40 5470] DEBUG (DevController:95) DevController: 
writing
     {'virtual-device': '51712', 'device-type': 'disk', 'protocol':
     'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend':
     '/local/domain/0/backend/vbd/39/51712'} to
     /local/domain/39/device/vbd/51712.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:97) DevController: 
writing
     {'domain': 'vserv1', 'frontend': '/local/domain/39/device/vbd/51712',
     'uuid': '04d99772-cf27-aecf-2d1b-c73eaf657410', 'bootable': '1', 'dev':
     'xvda', 'state': '1', 'params': '/dev/lv/vserv1-boot', 'mode': 'w',
     'online': '1', 'frontend-id': '39', 'type': 'phy'} to
     /local/domain/0/backend/vbd/39/51712.
     [2013-02-25 13:06:40 5470] INFO (XendDomainInfo:2367) createDevice: 
vbd :
     {'uuid': 'e46cb89f-3e54-41d2-53bd-759ed6c690d2', 'bootable': 0, 
'driver':
     'paravirtualised', 'dev': 'xvdb', 'uname': 'phy:/dev/lv/vserv1-disk',
     'mode': 'w'}
     [2013-02-25 13:06:40 5470] DEBUG (DevController:95) DevController: 
writing
     {'virtual-device': '51728', 'device-type': 'disk', 'protocol':
     'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend':
     '/local/domain/0/backend/vbd/39/51728'} to
     /local/domain/39/device/vbd/51728.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:97) DevController: 
writing
     {'domain': 'vserv1', 'frontend': '/local/domain/39/device/vbd/51728',
     'uuid': 'e46cb89f-3e54-41d2-53bd-759ed6c690d2', 'bootable': '0', 'dev':
     'xvdb', 'state': '1', 'params': '/dev/lv/vserv1-disk', 'mode': 'w',
     'online': '1', 'frontend-id': '39', 'type': 'phy'} to
     /local/domain/0/backend/vbd/39/51728.
     [2013-02-25 13:06:40 5470] INFO (XendDomainInfo:2367) createDevice: 
vbd :
     {'uuid': 'e2d61860-7448-1843-3935-6b63c5d2878e', 'bootable': 0, 
'driver':
     'paravirtualised', 'dev': 'xvdc', 'uname': 'phy:/dev/lv/vserv1-swap',
     'mode': 'w'}
     [2013-02-25 13:06:40 5470] DEBUG (DevController:95) DevController: 
writing
     {'virtual-device': '51744', 'device-type': 'disk', 'protocol':
     'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend':
     '/local/domain/0/backend/vbd/39/51744'} to
     /local/domain/39/device/vbd/51744.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:97) DevController: 
writing
     {'domain': 'vserv1', 'frontend': '/local/domain/39/device/vbd/51744',
     'uuid': 'e2d61860-7448-1843-3935-6b63c5d2878e', 'bootable': '0', 'dev':
     'xvdc', 'state': '1', 'params': '/dev/lv/vserv1-swap', 'mode': 'w',
     'online': '1', 'frontend-id': '39', 'type': 'phy'} to
     /local/domain/0/backend/vbd/39/51744.
     [2013-02-25 13:06:40 5470] INFO (XendDomainInfo:2367) createDevice: 
vbd :
     {'uuid': 'd314a46e-1ce9-0e8d-b009-3f08e29735f5', 'bootable': 0, 
'driver':
     'paravirtualised', 'dev': 'xvdd', 'uname': 'phy:/dev/lv/vserv1mirror',
     'mode': 'w'}
     [2013-02-25 13:06:40 5470] DEBUG (DevController:95) DevController: 
writing
     {'virtual-device': '51760', 'device-type': 'disk', 'protocol':
     'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend':
     '/local/domain/0/backend/vbd/39/51760'} to
     /local/domain/39/device/vbd/51760.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:97) DevController: 
writing
     {'domain': 'vserv1', 'frontend': '/local/domain/39/device/vbd/51760',
     'uuid': 'd314a46e-1ce9-0e8d-b009-3f08e29735f5', 'bootable': '0', 'dev':
     'xvdd', 'state': '1', 'params': '/dev/lv/vserv1mirror', 'mode': 'w',
     'online': '1', 'frontend-id': '39', 'type': 'phy'} to
     /local/domain/0/backend/vbd/39/51760.
     [2013-02-25 13:06:40 5470] DEBUG (XendDomainInfo:3400) Storing VM 
details:
     {'on_xend_stop': 'ignore', 'shadow_memory': '0', 'uuid':
     '04541225-6d3c-3cae-a4c4-0b6d4ccfac7a', 'on_reboot': 'restart',
     'start_time': '1361794000.37', 'on_poweroff': 'destroy', 
'bootloader_args':
     '', 'on_xend_start': 'ignore', 'on_crash': 'restart', 
'xend/restart_count':
     '0', 'vcpus': '2', 'vcpu_avail': '3', 'bootloader':
     '/usr/lib/xen-4.0/bin/pygrub', 'image': "(linux (kernel ) (args
     'root=/dev/xvdb  ') (superpages 0) (tsc_mode 0) (videoram 4) (pci ())
     (nomigrate 0) (notes (HV_START_LOW 18446603336221196288) (FEATURES
     '!writable_page_tables|pae_pgdir_above_4gb') (VIRT_BASE
     18446744071562067968) (GUEST_VERSION 2.6) (PADDR_OFFSET 0) 
(GUEST_OS linux)
     (HYPERCALL_PAGE 18446744071578882048) (LOADER generic) 
(SUSPEND_CANCEL 1)
     (PAE_MODE yes) (ENTRY 18446744071584289280) (XEN_VERSION xen-3.0)))",
     'name': 'vserv1'}
     [2013-02-25 13:06:40 5470] DEBUG (XendDomainInfo:1804) Storing domain
     details: {'console/ring-ref': '2143834', 'image/entry':
     '18446744071584289280', 'console/port': '2', 'store/ring-ref': 
'2143835',
     'image/loader': 'generic', 'vm':
     '/vm/04541225-6d3c-3cae-a4c4-0b6d4ccfac7a',
     'control/platform-feature-multiprocessor-suspend': '1',
     'image/hv-start-low': '18446603336221196288', 'image/guest-os': 
'linux',
     'cpu/1/availability': 'online', 'image/virt-base': 
'18446744071562067968',
     'memory/target': '2097152', 'image/guest-version': '2.6', 
'image/pae-mode':
     'yes', 'description': '', 'console/limit': '1048576', 
'image/paddr-offset':
     '0', 'image/hypercall-page': '18446744071578882048',
     'image/suspend-cancel': '1', 'cpu/0/availability': 'online',
     'image/features/pae-pgdir-above-4gb': '1',
     'image/features/writable-page-tables': '0', 'console/type': 
'xenconsoled',
     'name': 'vserv1', 'domid': '39', 'image/xen-version': 'xen-3.0',
     'store/port': '1'}
     [2013-02-25 13:06:40 5470] DEBUG (DevController:95) DevController: 
writing
     {'protocol': 'x86_64-abi', 'state': '1', 'backend-id': '0', 'backend':
     '/local/domain/0/backend/console/39/0'} to
     /local/domain/39/device/console/0.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:97) DevController: 
writing
     {'domain': 'vserv1', 'frontend': '/local/domain/39/device/console/0',
     'uuid': 'c8819aed-c78f-02b8-0ef7-1600abd15add', 'frontend-id': '39',
     'state': '1', 'location': '2', 'online': '1', 'protocol': 'vt100'} to
     /local/domain/0/backend/console/39/0.
     [2013-02-25 13:06:40 5470] DEBUG (XendDomainInfo:1891)
     XendDomainInfo.handleShutdownWatch
     [2013-02-25 13:06:40 5470] DEBUG (DevController:139) Waiting for 
devices
     vif2.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:139) Waiting for 
devices
     vif.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:139) Waiting for 
devices
     vscsi.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:139) Waiting for 
devices
     vbd.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:144) Waiting for 51712.
     [2013-02-25 13:06:40 5470] DEBUG (DevController:628) 
hotplugStatusCallback
     /local/domain/0/backend/vbd/39/51712/hotplug-status.

 From my point of view, either Xen hypervisor or the kernel seems to be 
broken, but it's hard to tell for me.


I suspect the problem within the Xen kernel part of VIF code as a reboot 
of the dom0 solves this problem temporarily without touching the domUs. 
But within some hours (<6 hrs) the issue re-appears.
Although I assume that xend is responsible for adding/removing VIFs a 
restart of xend doesn't help at all. That's why I assume a kernel 
problem within the dom0.

I'm running 8 domUs at the moment, each of them is connected to the 
outer world through xenbr0 and connected to the internal world through 
xenbr1 and RFC1918 addresses. I'm running a mixed setup of routed and 
bridged config:

(vif-script vif-bridge)
(network-script network-route)

But the server ran several years with that setup without any problems, 
so I don't think that's an issue.

For now I'm forced to go back to a working kernel as I need to keep the 
server up and running.

--- System information. ---
Architecture: amd64
Kernel:       Linux 2.6.32-5-xen-amd64

gate:~# dpkg -l | grep xen
ii  libxenstore3.0                      4.0.1-5.6 
Xenstore communications library for Xen
ii  linux-image-2.6.32-5-xen-amd64      2.6.32-48 
Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64            4.0.1-5.6 
The Xen Hypervisor on AMD64
ii  xen-linux-system-2.6-xen-amd64      2.6.32+29 
Xen system with Linux 2.6 for 64-bit PCs (meta-package)
ii  xen-linux-system-2.6.32-5-xen-amd64 2.6.32-48 
Xen system with Linux 2.6.32 on 64-bit PCs (meta-package)
ii  xen-tools                           4.2-1 
Tools to manage Xen virtual servers
ii  xen-utils-4.0                       4.0.1-5.6 
XEN administrative tools
ii  xen-utils-common                    4.0.0-1 
XEN administrative tools - common files
ii  xenstore-utils                      4.0.1-5.6 
Xenstore utilities for Xen
ii  xenwatch                            0.5.4-2 
Virtualization utilities, mostly for Xen


-- 
Ciao...            //      Fon: 0381-2744150
       Ingo       \X/       http://blog.windfluechter.net
Please don't share this address with Facebook or Google!
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc


From ijc at hellion.org.uk  Tue Feb 26 18:19:35 2013
From: ijc at hellion.org.uk (Ian Campbell)
Date: Tue, 26 Feb 2013 18:19:35 +0000
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <512CF3F3.4070202@2013.bluespice.org>
References: <512CF3F3.4070202@2013.bluespice.org>
Message-ID: <1361902775.11431.29.camel@dagon.hellion.org.uk>

On Tue, 2013-02-26 at 18:42 +0100, Ingo Juergensmann wrote:
> 
> Since the update last weekind in stable/squeeze I'm experiencing 
> problems with running Xen on amd64 and multiple domUs losing their 
> network connection/VIFs. 

The hypervisors involvement in the specifics of the networking is pretty
minimal -- a kernel bug is much more likely IMHO.

In particular the messages you are seeing look a lot like those which
would result from
http://wiki.xen.org/wiki/Security_Announcements#XSA_39_Linux_netback_DoS_via_malicious_guest_ring..

So, was the hypervisor upgrade also accompanied by a kernel update, in
either the dom0 or guest domains? If so what versions were involved and
where?

Thanks,
Ian
-- 
Ian Campbell


pain, n.:
	One thing, at least it proves that you're alive!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130226/85801bbb/attachment.pgp>

From ij at 2013.bluespice.org  Tue Feb 26 18:59:30 2013
From: ij at 2013.bluespice.org (Ingo =?UTF-8?Q?J=C3=BCrgensmann?=)
Date: Tue, 26 Feb 2013 19:59:30 +0100
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <1361902775.11431.29.camel@dagon.hellion.org.uk>
References: <512CF3F3.4070202@2013.bluespice.org>
	<1361902775.11431.29.camel@dagon.hellion.org.uk>
Message-ID: <F37D9616-DF4B-4EE3-8397-51ABECC65CEF@2013.bluespice.org>

Am 26.02.2013 um 19:19 schrieb Ian Campbell <ijc at hellion.org.uk>:

>> Since the update last weekind in stable/squeeze I'm experiencing 
>> problems with running Xen on amd64 and multiple domUs losing their 
>> network connection/VIFs. 
> The hypervisors involvement in the specifics of the networking is pretty
> minimal -- a kernel bug is much more likely IMHO.
> In particular the messages you are seeing look a lot like those which
> would result from
> http://wiki.xen.org/wiki/Security_Announcements#XSA_39_Linux_netback_DoS_via_malicious_guest_ring..
> So, was the hypervisor upgrade also accompanied by a kernel update, in
> either the dom0 or guest domains? If so what versions were involved and
> where?


Yes, it was a full update, both on dom0 as well as on domUs. I always try to keep kernels on dom0 and domU the same version. 

The blog posts lists the packages that were updated last weekend: 

gate:~# dir /var/cache/apt/archives/
base-files_6.0squeeze7_amd64.deb                 libxenstore3.0_4.0.1-5.6_amd64.deb
bind9-host_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb   linux-base_2.6.32-48_all.deb
dbus_1.2.24-4+squeeze2_amd64.deb                 linux-image-2.6.32-5-amd64_2.6.32-48_amd64.deb
dbus-x11_1.2.24-4+squeeze2_amd64.deb             linux-image-2.6.32-5-xen-amd64_2.6.32-48_amd64.deb
firmware-linux-free_2.6.32-48_all.deb            lock
gzip_1.3.12-9+squeeze1_amd64.deb                 openssh-client_1%3a5.5p1-6+squeeze3_amd64.deb
host_1%3a9.7.3.dfsg-1~squeeze9_all.deb           openssh-server_1%3a5.5p1-6+squeeze3_amd64.deb
libbind9-60_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb  openssl_0.9.8o-4squeeze14_amd64.deb
libcups2_1.4.4-7+squeeze3_amd64.deb              partial
libdbus-1-3_1.2.24-4+squeeze2_amd64.deb          perl_5.10.1-17squeeze5_amd64.deb
libdbus-glib-1-2_0.88-2.1+squeeze1_amd64.deb     perl-base_5.10.1-17squeeze5_amd64.deb
libdns69_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb     perl-modules_5.10.1-17squeeze5_all.deb
libisc62_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb     ssh_1%3a5.5p1-6+squeeze3_all.deb
libisccc60_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb   tzdata_2012g-0squeeze1_all.deb
libisccfg62_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb  xen-hypervisor-4.0-amd64_4.0.1-5.6_amd64.deb
libldap-2.4-2_2.4.23-7.3_amd64.deb               xen-linux-system-2.6.32-5-xen-amd64_2.6.32-48_amd64.deb
liblwres60_1%3a9.7.3.dfsg-1~squeeze9_amd64.deb   xenstore-utils_4.0.1-5.6_amd64.deb
libperl5.10_5.10.1-17squeeze5_amd64.deb          xen-utils-4.0_4.0.1-5.6_amd64.deb
libssl0.9.8_0.9.8o-4squeeze14_amd64.deb

The same kernel versions were updated in the domUs.

-- 
Ciao...            //      Fon: 0381-2744150
      Ingo       \X/       http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc


From news at ecopis.us  Wed Feb 27 04:53:19 2013
From: news at ecopis.us (=?UTF-8?B?5aSn5LyX5rG96L2m?=)
Date: Wed, 27 Feb 2013 04:53:19 -0000
Subject: [Pkg-xen-devel] =?utf-8?b?5aSn5LyX6L+b5Y+j5rG96L2m77ya5a625peP?=
 =?utf-8?b?6b2Q5LiK6Zi177yM5Zac6LWi4oCc5a624oCd5bm05Y2O?=
Message-ID: <552818545.3776072.1361940733172.JavaMail.news@ecopis.us>

___________________________________________
??:????????????????????

___________________________________________
????????????
___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130227/542978ba/attachment-0001.html>

From ij at 2013.bluespice.org  Thu Feb 28 06:47:52 2013
From: ij at 2013.bluespice.org (Ingo =?UTF-8?Q?J=C3=BCrgensmann?=)
Date: Thu, 28 Feb 2013 07:47:52 +0100
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <1361902775.11431.29.camel@dagon.hellion.org.uk>
References: <512CF3F3.4070202@2013.bluespice.org>
	<1361902775.11431.29.camel@dagon.hellion.org.uk>
Message-ID: <4E6F92D5-0B79-48E2-9275-FDFAB2B1CD9E@2013.bluespice.org>

Am 26.02.2013 um 19:19 schrieb Ian Campbell <ijc at hellion.org.uk>:

> So, was the hypervisor upgrade also accompanied by a kernel update, in
> either the dom0 or guest domains? If so what versions were involved and
> where?


Additionally to the last mail: 
After running two days stable with the downgraded packages, I've now upgraded the hypervisor package to xen-hypervisor-4.0-amd64_4.0.1-5.6_amd64.deb again and rebooted. 
If the machine runs stable with that, I'd say the kernel package is broken. And if the issues popping up again now, it's the hypervisor. All domUs are still running the updated kernel packages (pre DSA-2632-1), the dom0 the downgraded kernel package.  

-- 
Ciao...            //      Fon: 0381-2744150
      Ingo       \X/       http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc


From ijc at hellion.org.uk  Thu Feb 28 10:28:27 2013
From: ijc at hellion.org.uk (Ian Campbell)
Date: Thu, 28 Feb 2013 10:28:27 +0000
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <4E6F92D5-0B79-48E2-9275-FDFAB2B1CD9E@2013.bluespice.org>
References: <512CF3F3.4070202@2013.bluespice.org>
	<1361902775.11431.29.camel@dagon.hellion.org.uk>
	<4E6F92D5-0B79-48E2-9275-FDFAB2B1CD9E@2013.bluespice.org>
Message-ID: <1362047307.23384.68.camel@dagon.hellion.org.uk>

On Thu, 2013-02-28 at 07:47 +0100, Ingo J?rgensmann wrote:
> Am 26.02.2013 um 19:19 schrieb Ian Campbell <ijc at hellion.org.uk>:
> 
> > So, was the hypervisor upgrade also accompanied by a kernel update, in
> > either the dom0 or guest domains? If so what versions were involved and
> > where?
> 
> 
> Additionally to the last mail: 
> After running two days stable with the downgraded packages, I've now
> upgraded the hypervisor package to
> xen-hypervisor-4.0-amd64_4.0.1-5.6_amd64.deb again and rebooted. 
> If the machine runs stable with that, I'd say the kernel package is
> broken. And if the issues popping up again now, it's the hypervisor.

I am 99% positive it will turn out to be the kernel, but please do let
us know.

> All domUs are still running the updated kernel packages (pre
> DSA-2632-1), the dom0 the downgraded kernel package.  

When you reach a conclusion (assuming it is the one I expect!) please
can you confirm the fixed+broken kernel package versions so I can
reassign as appropriate.

Unfortunately I'm about to go travelling for a week but I have asked one
of my colleagues to try and take a look at this.

Ian.
-- 
Ian Campbell


A beginning is the time for taking the most delicate care that balances are
correct.
		-- Princess Irulan, "Manual of Maud'Dib"


From ij at 2013.bluespice.org  Thu Feb 28 19:30:30 2013
From: ij at 2013.bluespice.org (Ingo =?UTF-8?Q?J=C3=BCrgensmann?=)
Date: Thu, 28 Feb 2013 20:30:30 +0100
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <1362047307.23384.68.camel@dagon.hellion.org.uk>
References: <512CF3F3.4070202@2013.bluespice.org>
	<1361902775.11431.29.camel@dagon.hellion.org.uk>
	<4E6F92D5-0B79-48E2-9275-FDFAB2B1CD9E@2013.bluespice.org>
	<1362047307.23384.68.camel@dagon.hellion.org.uk>
Message-ID: <E4613024-407C-4F01-8074-915047EBD999@2013.bluespice.org>

Am 28.02.2013 um 11:28 schrieb Ian Campbell <ijc at hellion.org.uk>:

> I am 99% positive it will turn out to be the kernel, but please do let
> us know.

Shortly before 18:00 today I reinstalled linux-image-2.6.32-5-xen-amd64_2.6.32-48_amd64.deb as kernel and it took only 2.5 hours to trigger the issue. 
The hypervisor is xen-hypervisor-4.0-amd64 4.0.1-5.4 at this time.  

>> All domUs are still running the updated kernel packages (pre
>> DSA-2632-1), the dom0 the downgraded kernel package.  
> When you reach a conclusion (assuming it is the one I expect!) please
> can you confirm the fixed+broken kernel package versions so I can
> reassign as appropriate.
> Unfortunately I'm about to go travelling for a week but I have asked one
> of my colleagues to try and take a look at this.


I will now upgrade to DSA-2632-1 kernels and see whether that works or has the same issues. Will keep you updated. 

-- 
Ciao...            //      Fon: 0381-2744150
      Ingo       \X/       http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc


From ij at 2013.bluespice.org  Thu Feb 28 20:24:46 2013
From: ij at 2013.bluespice.org (Ingo =?UTF-8?Q?J=C3=BCrgensmann?=)
Date: Thu, 28 Feb 2013 21:24:46 +0100
Subject: [Pkg-xen-devel] Bug#701744: Bug#701744: [xen] Update to hypervisor
	4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes
	networking (VIF) failures
In-Reply-To: <1362047307.23384.68.camel@dagon.hellion.org.uk>
References: <512CF3F3.4070202@2013.bluespice.org>
	<1361902775.11431.29.camel@dagon.hellion.org.uk>
	<4E6F92D5-0B79-48E2-9275-FDFAB2B1CD9E@2013.bluespice.org>
	<1362047307.23384.68.camel@dagon.hellion.org.uk>
Message-ID: <4B7210C9-3286-464C-BE6D-489C28111C14@2013.bluespice.org>

Am 28.02.2013 um 11:28 schrieb Ian Campbell <ijc at hellion.org.uk>:

>> All domUs are still running the updated kernel packages (pre
>> DSA-2632-1), the dom0 the downgraded kernel package.  

linux-image-2.6.32-5-xen-amd64 2.6.32-48squeeze1 triggered the problem within 30 mins. ;-)

> When you reach a conclusion (assuming it is the one I expect!) please
> can you confirm the fixed+broken kernel package versions so I can
> reassign as appropriate.

Conclusion: it's the kernel... ;-) 

Working: 
- kernel: linux-image-2.6.32-5-xen-amd64_2.6.32-46_amd64.deb
- hypervisor: xen-hypervisor-4.0-amd64_4.0.1-5.4_amd64.deb, xen-hypervisor-4.0-amd64_4.0.1-5.6_amd64.deb

Not Working kernels:
- linux-image-2.6.32-5-xen-amd64_2.6.32-48_amd64.deb
- linux-image-2.6.32-5-xen-amd64_2.6.32-48squeeze1_amd64.deb

So, I'm going back to linux-image-2.6.32-5-xen-amd64_2.6.32-46_amd64.deb... 

-- 
Ciao...            //      Fon: 0381-2744150
      Ingo       \X/       http://blog.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc