[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#593245: marked as done (linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch)



Your message dated Tue, 23 Nov 2010 14:47:04 +0000
with message-id <1290523624.5514.72.camel@zakaz.uk.xensource.com>
and subject line Re: 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
has caused the Debian Bug report #593245,
regarding linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
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@bugs.debian.org
immediately.)


-- 
593245: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593245
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Title: 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.deming@matrix.msu.edu


--- End Message ---
--- Begin Message ---
On Tue, 2010-11-23 at 09:26 -0500, Joseph M. Deming wrote:
> 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.

Excellent, I am therefore closing this bug with this mail.

Thanks very much for the report and the feedback.

Ian.


>   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 Campbell<ijc@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-common        4.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
> >
> >    
> 
> 

-- 
Ian Campbell

She often gave herself very good advice (though she very seldom followed it).
		-- Lewis Carroll



--- End Message ---

Reply to: