[Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking

Gavin netmatters at gmail.com
Mon Feb 18 13:51:12 UTC 2013


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>


More information about the Pkg-xen-devel mailing list