Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
Ian Campbell i...@hellion.org.uk writes: The version of xen-utils-common may also have some bearing on this since it is the package which provides /lib/udev/rules.d/xend.rules Here in working case I have $ dpkg-query -W xen* xen-hypervisor-amd64 xen-linux-system-2.6.32-5+bug580889.1-xen-amd64 xen-tools xen-utils-common4.0.0-1 xenstore-utils 4.0.1-1 It's also worth checking for stale entries in /etc/udev/rules.d (or whatever the previous path was) which might be interfering. $ md5sum /lib/udev/rules.d/*xen* cea42daba332764f255dadec112f64c5 /lib/udev/rules.d/xen-backend.rules 5a306f5dba657c3c962c158782e848fb /lib/udev/rules.d/xend.rules -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84aal0fmlw@sauna.l.org
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
Ack, response yesterday didn't get through apparently. I am the OP and as far as I know this issue was addressed within 2-3 weeks of my original post. I can't isolate exactly which patch fixed things up, all I know is that there were several changes to linux-image-2.6.32-5 around that time and I think the fix was in there, but I can't say surely that it wasn't a fix to the xen codebase that also helped. What I can say is that, currently running 2.6.32-26 this issue no longer presents itself and I have been able to start machines normally, without any held-back patches since around late August, early September. On 2.6.32-26 this is my output: find /dev|grep evt /dev/.udev/db/misc:xen/evtchn /dev/xen/evtchn find /sys | grep evtchn /sys/devices/virtual/misc/xen!evtchn /sys/devices/virtual/misc/xen!evtchn/uevent /sys/devices/virtual/misc/xen!evtchn/dev /sys/devices/virtual/misc/xen!evtchn/subsystem /sys/devices/virtual/misc/xen!evtchn/power /sys/devices/virtual/misc/xen!evtchn/power/wakeup /sys/class/misc/xen!evtchn /sys/module/xen_evtchn /sys/module/xen_evtchn/holders /sys/module/xen_evtchn/initstate /sys/module/xen_evtchn/refcnt /sys/module/xen_evtchn/sections /sys/module/xen_evtchn/sections/.note.gnu.build-id /sys/module/xen_evtchn/sections/.text /sys/module/xen_evtchn/sections/.exit.text /sys/module/xen_evtchn/sections/.init.text /sys/module/xen_evtchn/sections/.rodata /sys/module/xen_evtchn/sections/.parainstructions /sys/module/xen_evtchn/sections/.rodata.str1.1 /sys/module/xen_evtchn/sections/__bug_table /sys/module/xen_evtchn/sections/.data /sys/module/xen_evtchn/sections/.gnu.linkonce.this_module /sys/module/xen_evtchn/sections/.bss /sys/module/xen_evtchn/sections/.symtab /sys/module/xen_evtchn/sections/.strtab /sys/module/xen_evtchn/notes /sys/module/xen_evtchn/notes/.note.gnu.build-id As I said all has seemed long-since fixed up. For the record, I run Sid, so I can't verify Squeeze for sure, but it would likely be fixed up also. We will be applying our monthly updates on Wednesday (tomorrow) and that will take us up to 2.6.32-27, if you wish for any more feedback let me know. - jmd On 11/23/2010 03:52 AM, Timo Juhani Lindfors wrote: Ian Campbelli...@hellion.org.uk writes: The version of xen-utils-common may also have some bearing on this since it is the package which provides /lib/udev/rules.d/xend.rules Here in working case I have $ dpkg-query -W xen* xen-hypervisor-amd64 xen-linux-system-2.6.32-5+bug580889.1-xen-amd64 xen-tools xen-utils-common4.0.0-1 xenstore-utils 4.0.1-1 It's also worth checking for stale entries in /etc/udev/rules.d (or whatever the previous path was) which might be interfering. $ md5sum /lib/udev/rules.d/*xen* cea42daba332764f255dadec112f64c5 /lib/udev/rules.d/xen-backend.rules 5a306f5dba657c3c962c158782e848fb /lib/udev/rules.d/xend.rules -- Joseph M. Deming System Administrator MATRIX/History 415 Nat Sci Bldg East Lansing, MI 48824 (517) 884-2472 joseph.dem...@matrix.msu.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cebcf00.2030...@matrix.msu.edu
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
On Thu, 2010-11-18 at 10:05 +0200, Timo Juhani Lindfors wrote: With $ dpkg-query -W linux-image-$(uname -r) linux-image-2.6.32-5-xen-amd64 2.6.32-27 The version of xen-utils-common may also have some bearing on this since it is the package which provides /lib/udev/rules.d/xend.rules It's also worth checking for stale entries in /etc/udev/rules.d (or whatever the previous path was) which might be interfering. This bug dates back to August and IIRC there was a bunch of fiddling with this sort stuff around that time, both on the kernel and xen-utils side of things (maybe udev too) so it would be interesting to know if this could be reproduced with up to date Squeeze/Sid or not. Ian. -- Ian Campbell The egg cream is psychologically the opposite of circumcision -- it *pleasurably* reaffirms your Jewishness. -- Mel Brooks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290445130.31507.6563.ca...@zakaz.uk.xensource.com
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
With $ dpkg-query -W linux-image-$(uname -r) linux-image-2.6.32-5-xen-amd64 2.6.32-27 I see $ find /dev|grep evt /dev/.udev/db/misc:xen/evtchn /dev/xen/evtchn Does everything work if you create evtchn manually with mknod /dev/xen/evtchn c 10 57? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84oc9nm4zi@sauna.l.org
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
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 joseph.dem...@matrix.msu.edu
