Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-20 The error manifests itself when trying to start a VM machine with a clean/vanilla install of debian sid + linux-image-2.6.32-5 + xen-hypervisor-4.0 from last Friday's package list. Since and 'upgrade' today still listed package 'linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64' as current, it should still be an existing bug if installing today.
Most obvious output is upon trying to 'xm create' a machine: ERROR Internal error: Could not open event channel interface (22 = Invalid argument) >From what I was able to track down, udev doesn't seem to be creating the 'evtchn' device correctly using linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb. I believe this is the package to file this bug against. It should be relatively easily reproducible with a clean install. Reverting to linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and updating initramfs fixes the issue. Reverting to xen-hypervisor-4.0-amd64_4.0.1~rc3-1_amd64 does _NOT_ make a difference. Hence, I believe it's in the kernel img where the problem lies. I am using 'linux-image-2.6.32-5-xen-amd64_2.6.32' as both dom0 and domU. A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 will produce this output > 'find /dev | grep evtchn' /dev/xen/evtchn /dev/evtchn /dev/.udev/db/misc:evtchn > 'find /sys | grep evtchn' (also produces useful output for comparison... didn't want to bloat the post with text) A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64 will produce different output, mainly it will only have a line simlar to: > 'find /dev | grep evtchn' /dev/.udev/db/??misc:evtchn?? where the ??misc:evtchn?? string may be slightly different. most importantly, it does _NOT_ create /dev/evtchn or /dev/xen/evtchn. also: > 'find /sys | grep evtchn' will produce output where the device strings have '!'s in them where they don't on the .18 kernel. I have a feeling these changes to the device names/drivers/whatever they are properly called are causing udev rules to fail. I have a suspicion it is a result of trying to fix the issue where the kernel/udev was complaining about "kernel-provided name 'evtchn' and NAME= 'xen/evtchn' disagree, please use SYMLINK+= or change the kernel to provide the proper name" which was an issue in the .18 kernel release. I have no absolute proof of this, I am just trying to provide some thoughts. I apologize I am reporting this bug only after downgrading to linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and 'fixing' the issue. I don't have the luxery of time to re-create the broken fix and dump exact output and sys-config. I need the system working. So, I hope I provided enough to troubleshoot. I didn't see similar bugs posted under linux-image, udev or xen hypervisor packages so I feel it's unique. Thanks again for creating the pvopts kernels!!! It is SO nice to have built packages back in the repos to use for dom0. Xen and the work to support it is an awesome thing. Please ask me if you need more feedback and I can dump output. The main packages/versions related to this bug should be: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64 xen-hypervisor-4.0-amd64_4.0.1~rc5-1_amd64 (as mentioned, rc3 also produces same bug) libudev0 160-1 libudev shared library udev 160-1 /dev/ and hotplug management daemon linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 downgrade 'fixes' issue. Hope this helps someone. - jmd -- Joseph M. Deming System Administrator MATRIX/History 415 Nat Sci Bldg East Lansing, MI 48824 (517) 884-2472 [email protected]
