Xen devel - Nov 2005 - Hotplug scripts not working... xen/ia64 domU stopped working

Somewhere between cset 8006 and cset 8112, the virtual block
device stopped working for Xen/ia64.  With cset 8112, I get:

Error: Device 769 (vbd) could not be connected. Hotplug scripts not
working.

Any suggestions where to start looking or will I need to do a binary
search?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

First binary search step: cset 8054 fails the same way (for Xen/ia64).
> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins) 
> Sent: Tuesday, November 29, 2005 9:44 PM
> To: Xen Mailing List
> Subject: Hotplug scripts not working... xen/ia64 domU stopped working
> 
> Somewhere between cset 8006 and cset 8112, the virtual block
> device stopped working for Xen/ia64.  With cset 8112, I get:
> 
> Error: Device 769 (vbd) could not be connected. Hotplug 
> scripts not working.
> 
> Any suggestions where to start looking or will I need to do a binary
> search?
> 
> Thanks,
> Dan
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Le Mercredi 30 Novembre 2005 06:50, Magenheimer, Dan (HP Labs Fort Collins) a 
écrit :
> First binary search step: cset 8054 fails the same way (for Xen/ia64).
Is it with xen-ia64-unstable.hg tree ?
My current tip is 7922!

Tristan.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Somewhere between cset 8006 and cset 8112, the virtual block
> device stopped working for Xen/ia64.  With cset 8112, I get:
> 
> Error: Device 769 (vbd) could not be connected. Hotplug scripts not
> working.
> 
> Any suggestions where to start looking or will I need to do a binary
> search?
Please use xen-bugtool (new in the latest changesets) to collect your logs so
that I can take a look.

Cheers,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> 
> > Somewhere between cset 8006 and cset 8112, the virtual block
> > device stopped working for Xen/ia64.  With cset 8112, I get:
> > 
> > Error: Device 769 (vbd) could not be connected. Hotplug scripts not
> > working.
> > 
> > Any suggestions where to start looking or will I need to do a binary
> > search?
> 
> Please use xen-bugtool (new in the latest changesets) to 
> collect your logs so
> that I can take a look.
Hmmmm... it appears xen-bugtool is born at 8073.  I can go
back to that but have already reproduced the problem at 8054.

HOWEVER... I am now having problems at 8006 which worked
yesterday.  I suspect that there are some Xen tools/files that
are not getting replaced.  (And xen-bugtool doesn''t work there
as one would expect... it is still in place because of the
previous install of 8112 but gives a python error.)

Is there a way to do a "make clean" on all Xen files outside
of the xen-unstable.hg directory to ensure no "old" (or in my case
newer) files/scripts from /etc, /bin/ etc are being accidentally
used?  I know others have experienced this kind of problem and
have "fixed" it by reinstalling their distro from scratch.
I had a disk trashed while I was on holiday and after reinstalling
RH3 from scratch, 8006 worked.  But after going to 8112 (hotplug
error), then 8054 (hotplug error), then 8029 (can''t mount
root disk), 8006 didn''t work (can''t mount root disk).  It
would be a pain if I have to reinstall RH3 again from scratch.

Alternately, perhaps I am using the wrong make command?  I am
doing a "make" in the xen-unstable directory, then 
using "make install-tools" (as root)... and of course ensuring
my xen, dom0, and domU images are in the right place.  Perhaps
install-tools is not always overwriting every tool so I am
getting a strange mix of versions (thus the make clean question
above)?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Magenheimer, Dan (HP Labs Fort Collins)
> Sent: 30 November 2005 14:18
> To: Ewan Mellor
> Cc: Xen Mailing List
> Subject: RE: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domU stopped working
> 
> > On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan (HP Labs 
> > Fort Collins) wrote:
> > 
> > > Somewhere between cset 8006 and cset 8112, the virtual 
> block device 
> > > stopped working for Xen/ia64.  With cset 8112, I get:
> > > 
> > > Error: Device 769 (vbd) could not be connected. Hotplug 
> scripts not 
> > > working.
> > > 
> > > Any suggestions where to start looking or will I need to 
> do a binary 
> > > search?
> > 
> > Please use xen-bugtool (new in the latest changesets) to 
> collect your 
> > logs so that I can take a look.
> 
> Hmmmm... it appears xen-bugtool is born at 8073.  I can go 
> back to that but have already reproduced the problem at 8054.
> 
> HOWEVER... I am now having problems at 8006 which worked 
> yesterday.  I suspect that there are some Xen tools/files 
> that are not getting replaced.  (And xen-bugtool doesn''t work 
> there as one would expect... it is still in place because of 
> the previous install of 8112 but gives a python error.)
> 
> Is there a way to do a "make clean" on all Xen files outside 
> of the xen-unstable.hg directory to ensure no "old" (or in my
case
> newer) files/scripts from /etc, /bin/ etc are being 
> accidentally used?  I know others have experienced this kind 
> of problem and have "fixed" it by reinstalling their distro 
> from scratch.
[snip]

I''d like to see a "uninstall.sh". I did for a short while
consider
writing one myself. I know that most people aren''t going to uninstall
Xen - it''s such a lovely product that no one in their right mind would
uninstall it, right? - but particularly for us developers, it would be
nice to have something that removes ALL remains of the Xen installation.
I had severe problems because I tried to install 64-bit Xen on top of a
32-bit installation and all sorts of bits and pieces got very confused.

I think it could actually be constructed based on the install directory
with some scripting - I''m not that good at writing shell-scripts, or I
would volunteer to do it myself. [I hacked something up where I just
took the names of directories listed under the install directory and
removed all contents of those directories, but that''s only going to
work
as long as the files are kept in the same place each time. Yet, it''s
quicker to do that than to run a complete re-install...]

--
Mats


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Switched back to cset 8122, ran make uninstall, make install-tools,
and copied proper dom0, domU, and xen images back into place, booted
xen/dom0 and tried to run domU.  Failed with the same hotplug message.
Then ran xen-bugtool and got:

Traceback (most recent call last):
  File "/usr/sbin/xen-bugtool", line 17, in ?
    sys.exit(bugtool.main())
  File "/usr/lib/python/xen/util/bugtool.py", line 73, in main
    bugball.append(string_iterator(''physinfo'',
prettyDict(xc,physinfo())))
xen.lowlevel.xc.error: (38, ''Function not implemented'')

Since I''ve never run xen-bugtool before, I don''t know if this
is a side effect of leftover dregs from other installs.  Also,
not sure if this (even with error) is supposed to put results
in a file somewhere?

Thanks,
Dan
> -----Original Message-----
> From: Ewan Mellor [mailto:ewan@xensource.com] 
> Sent: Wednesday, November 30, 2005 4:53 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Xen Mailing List
> Subject: Re: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domU stopped working
> 
> On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> 
> > Somewhere between cset 8006 and cset 8112, the virtual block
> > device stopped working for Xen/ia64.  With cset 8112, I get:
> > 
> > Error: Device 769 (vbd) could not be connected. Hotplug scripts not
> > working.
> > 
> > Any suggestions where to start looking or will I need to do a binary
> > search?
> 
> Please use xen-bugtool (new in the latest changesets) to 
> collect your logs so
> that I can take a look.
> 
> Cheers,
> 
> Ewan.
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

* Magenheimer, Dan (HP Labs Fort Collins) <dan.magenheimer@hp.com>
[2005-11-30 10:49]:
>     sys.exit(bugtool.main())
>   File "/usr/lib/python/xen/util/bugtool.py", line 73, in main
>     bugball.append(string_iterator(''physinfo'',
> prettyDict(xc,physinfo())))
               ^
The comma looks like a typo, but in the latest changeset, line 73 in my
tree looks like this:

   bugball.append(string_iterator(''physinfo'', 
prettyDict(xc.physinfo())))

Not sure where that comma came from.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Sorry, manual typo.  (No cut/paste in ultravnc and samba
was not responding after a couple tries so I just manually
typed the error message.) 
> -----Original Message-----
> From: Ryan Harper [mailto:ryanh@us.ibm.com] 
> Sent: Wednesday, November 30, 2005 9:54 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Ewan Mellor; Xen Mailing List
> Subject: Re: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domU stopped working
> 
> * Magenheimer, Dan (HP Labs Fort Collins) 
> <dan.magenheimer@hp.com> [2005-11-30 10:49]:
> >     sys.exit(bugtool.main())
> >   File "/usr/lib/python/xen/util/bugtool.py", line 73, in
main
> >     bugball.append(string_iterator(''physinfo'',
> > prettyDict(xc,physinfo())))
>                ^
> The comma looks like a typo, but in the latest changeset, 
> line 73 in my
> tree looks like this:
> 
>    bugball.append(string_iterator(''physinfo'',  
> prettyDict(xc.physinfo())))
> 
> Not sure where that comma came from.
> 
> 
> -- 
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> (512) 838-9253   T/L: 678-9253
> ryanh@us.ibm.com
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Nov 30, 2005 at 08:48:32AM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Switched back to cset 8122, ran make uninstall, make install-tools,
> and copied proper dom0, domU, and xen images back into place, booted
> xen/dom0 and tried to run domU.  Failed with the same hotplug message.
> Then ran xen-bugtool and got:
> 
> Traceback (most recent call last):
>   File "/usr/sbin/xen-bugtool", line 17, in ?
>     sys.exit(bugtool.main())
>   File "/usr/lib/python/xen/util/bugtool.py", line 73, in main
>     bugball.append(string_iterator(''physinfo'',
> prettyDict(xc,physinfo())))
> xen.lowlevel.xc.error: (38, ''Function not implemented'')
> 
> Since I''ve never run xen-bugtool before, I don''t know if
this
> is a side effect of leftover dregs from other installs.  Also,
> not sure if this (even with error) is supposed to put results
> in a file somewhere?
The physinfo call has been around forever.  I''d say that your kernel
and tools
are disagreeing on the size of a structure or something like that.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Nov 30, 2005 at 05:16:51PM +0000, Ewan Mellor wrote:
> On Wed, Nov 30, 2005 at 08:48:32AM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> 
> > Switched back to cset 8122, ran make uninstall, make install-tools,
> > and copied proper dom0, domU, and xen images back into place, booted
> > xen/dom0 and tried to run domU.  Failed with the same hotplug message.
> > Then ran xen-bugtool and got:
> > 
> > Traceback (most recent call last):
> >   File "/usr/sbin/xen-bugtool", line 17, in ?
> >     sys.exit(bugtool.main())
> >   File "/usr/lib/python/xen/util/bugtool.py", line 73, in
main
> >     bugball.append(string_iterator(''physinfo'',
> > prettyDict(xc,physinfo())))
> > xen.lowlevel.xc.error: (38, ''Function not
implemented'')
> > 
> > Since I''ve never run xen-bugtool before, I don''t
know if this
> > is a side effect of leftover dregs from other installs.  Also,
> > not sure if this (even with error) is supposed to put results
> > in a file somewhere?
> 
> The physinfo call has been around forever.  I''d say that your
kernel and tools
> are disagreeing on the size of a structure or something like that.
Actually, is physinfo even implemented on ia64?  (Does xm info work?)

Regarding the hotplug failure, please send your
/var/log/{debug,messages,syslog} and I''ll take a look.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

make uninstall removes all the files outside the xen directory, no? I was having
problems with hotplug not working and this was one of the steps I took.

-Himanshu

On Wed, Nov 30, 2005 at 08:56:42AM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Sorry, manual typo.  (No cut/paste in ultravnc and samba
> was not responding after a couple tries so I just manually
> typed the error message.) 
> 
> > -----Original Message-----
> > From: Ryan Harper [mailto:ryanh@us.ibm.com] 
> > Sent: Wednesday, November 30, 2005 9:54 AM
> > To: Magenheimer, Dan (HP Labs Fort Collins)
> > Cc: Ewan Mellor; Xen Mailing List
> > Subject: Re: [Xen-devel] Hotplug scripts not working... 
> > xen/ia64 domU stopped working
> > 
> > * Magenheimer, Dan (HP Labs Fort Collins) 
> > <dan.magenheimer@hp.com> [2005-11-30 10:49]:
> > >     sys.exit(bugtool.main())
> > >   File "/usr/lib/python/xen/util/bugtool.py", line 73,
in main
> > >     bugball.append(string_iterator(''physinfo'',
> > > prettyDict(xc,physinfo())))
> >                ^
> > The comma looks like a typo, but in the latest changeset, 
> > line 73 in my
> > tree looks like this:
> > 
> >    bugball.append(string_iterator(''physinfo'',  
> > prettyDict(xc.physinfo())))
> > 
> > Not sure where that comma came from.
> > 
> > 
> > -- 
> > Ryan Harper
> > Software Engineer; Linux Technology Center
> > IBM Corp., Austin, Tx
> > (512) 838-9253   T/L: 678-9253
> > ryanh@us.ibm.com
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
-- 
-------------------------------------------------------------------------
Himanshu Raj
PhD Student, GaTech (www.cc.gatech.edu/~rhim)
I prefer to receive attachments in an open, non-proprietary format.
-------------------------------------------------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > Switched back to cset 8122, ran make uninstall, make 
> install-tools,
> > > and copied proper dom0, domU, and xen images back into 
> place, booted
> > > xen/dom0 and tried to run domU.  Failed with the same 
> hotplug message.
> > > Then ran xen-bugtool and got:
> > > 
> > > Traceback (most recent call last):
> > >   File "/usr/sbin/xen-bugtool", line 17, in ?
> > >     sys.exit(bugtool.main())
> > >   File "/usr/lib/python/xen/util/bugtool.py", line 73,
in main
> > >     bugball.append(string_iterator(''physinfo'',
> > > prettyDict(xc,physinfo())))
> > > xen.lowlevel.xc.error: (38, ''Function not
implemented'')
> > > 
> > > Since I''ve never run xen-bugtool before, I
don''t know if this
> > > is a side effect of leftover dregs from other installs.  Also,
> > > not sure if this (even with error) is supposed to put results
> > > in a file somewhere?
> > 
> > The physinfo call has been around forever.  I''d say that 
> your kernel and tools
> > are disagreeing on the size of a structure or something like that.
Could be.  I''ll take a look to see if what data structures changed.
> Actually, is physinfo even implemented on ia64?  (Does xm info work?)
No apparently not.  It''s never been needed before now.  It can probably
be easily implemented.

Are you suspecting this is a related to my problem (e.g. the
hotplug issue) or just needed for xen-bugtool and xm info?
 
> Regarding the hotplug failure, please send your
> /var/log/{debug,messages,syslog} and I''ll take a look.
I don''t have a /var/log/debug or /var/log/syslog and /var/log/messages
is unrevealing.  Do you mean xend.log and xend-debug.log?  If so,
attached (along with my very simple xmdefconfig).

By the way, I''ve never had to deal with any of the hotplug stuff
on Xen/ia64... did some new requirement get added in the last few
days (post-8006)?

Dan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Petersson, Mats <mats.petersson@amd.com> wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> Magenheimer, Dan (HP Labs Fort Collins)
>> Sent: 30 November 2005 14:18
>> To: Ewan Mellor
>> Cc: Xen Mailing List
>> Subject: RE: [Xen-devel] Hotplug scripts not working... 
>> xen/ia64 domU stopped working
>> 
>> > On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan (HP
Labs
>> > Fort Collins) wrote:
>> > 
>> > > Somewhere between cset 8006 and cset 8112, the virtual 
>> block device 
>> > > stopped working for Xen/ia64.  With cset 8112, I get:
>> > > 
>> > > Error: Device 769 (vbd) could not be connected. Hotplug 
>> scripts not 
>> > > working.
>> > > 
>> > > Any suggestions where to start looking or will I need to 
>> do a binary 
>> > > search?
>> > 
>> > Please use xen-bugtool (new in the latest changesets) to 
>> collect your 
>> > logs so that I can take a look.
>> 
>> Hmmmm... it appears xen-bugtool is born at 8073.  I can go 
>> back to that but have already reproduced the problem at 8054.
>> 
>> HOWEVER... I am now having problems at 8006 which worked 
>> yesterday.  I suspect that there are some Xen tools/files 
>> that are not getting replaced.  (And xen-bugtool doesn''t work 
>> there as one would expect... it is still in place because of 
>> the previous install of 8112 but gives a python error.)
>> 
>> Is there a way to do a "make clean" on all Xen files outside 
>> of the xen-unstable.hg directory to ensure no "old" (or in my
case
>> newer) files/scripts from /etc, /bin/ etc are being 
>> accidentally used?  I know others have experienced this kind 
>> of problem and have "fixed" it by reinstalling their distro 
>> from scratch.
> [snip]
> 
> I''d like to see a "uninstall.sh". I did for a short
while consider
> writing one myself. I know that most people aren''t going to
uninstall
> Xen - it''s such a lovely product that no one in their right mind
would
> uninstall it, right? - but particularly for us developers, it would be
> nice to have something that removes ALL remains of the Xen installation.
> I had severe problems because I tried to install 64-bit Xen on top of a
> 32-bit installation and all sorts of bits and pieces got very confused.
> 
> I think it could actually be constructed based on the install directory
> with some scripting - I''m not that good at writing shell-scripts,
or I
> would volunteer to do it myself. [I hacked something up where I just
> took the names of directories listed under the install directory and
> removed all contents of those directories, but that''s only going
to work
> as long as the files are kept in the same place each time. Yet,
it''s
> quicker to do that than to run a complete re-install...]
Given that the current install.sh more or less copies what is in
install/ into /, I think that making uninstall.sh work based on what is
in install/ would be quite workable.  Though it might be good to make a
list of what install.sh installs, bassed on what is in install/ at the
time it runs, rather than using what is in install/ at the time that it
runs, as the two may differ.

On a related note, I have a proposed patch to make install.sh cope with
being run as non-root, and cope with customised umasks. When I say cope,
it actually runs just fine, but leaving, for instance, /lib owned
by user.user, mode 700, as happens when I run the existing version
of my self with my usual umask, 0077, is not entirely fun afterwards.

-- 
Horms


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Nov 30, 2005 at 01:13:49PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
>  > > > Switched back to cset 8122, ran make uninstall, make 
> > install-tools,
> > > > and copied proper dom0, domU, and xen images back into 
> > place, booted
> > > > xen/dom0 and tried to run domU.  Failed with the same 
> > hotplug message.
> > > > Then ran xen-bugtool and got:
> > > > 
> > > > Traceback (most recent call last):
> > > >   File "/usr/sbin/xen-bugtool", line 17, in ?
> > > >     sys.exit(bugtool.main())
> > > >   File "/usr/lib/python/xen/util/bugtool.py", line
73, in main
> > > >    
bugball.append(string_iterator(''physinfo'',
> > > > prettyDict(xc,physinfo())))
> > > > xen.lowlevel.xc.error: (38, ''Function not
implemented'')
> > > > 
> > > > Since I''ve never run xen-bugtool before, I
don''t know if this
> > > > is a side effect of leftover dregs from other installs. 
Also,
> > > > not sure if this (even with error) is supposed to put
results
> > > > in a file somewhere?
> > > 
> > > The physinfo call has been around forever.  I''d say that
> > your kernel and tools
> > > are disagreeing on the size of a structure or something like
that.
> 
> Could be.  I''ll take a look to see if what data structures
changed.
> 
> > Actually, is physinfo even implemented on ia64?  (Does xm info work?)
> 
> No apparently not.  It''s never been needed before now.  It can
probably
> be easily implemented.
That would be a good idea.  I can work around the problem, but bug tracking
will certainly be easier if the hardware details are reported correctly.
> Are you suspecting this is a related to my problem (e.g. the
> hotplug issue) or just needed for xen-bugtool and xm info?
Just the latter.
> > Regarding the hotplug failure, please send your
> > /var/log/{debug,messages,syslog} and I''ll take a look.
> 
> I don''t have a /var/log/debug or /var/log/syslog and
/var/log/messages
> is unrevealing.  Do you mean xend.log and xend-debug.log?  If so,
> attached (along with my very simple xmdefconfig).
No, I really meant /var/log/messages -- the hotplug scripts log there, and you
usually see hotplug or udev events going through there too.
> By the way, I''ve never had to deal with any of the hotplug stuff
> on Xen/ia64... did some new requirement get added in the last few
> days (post-8006)?
No extra requirement, no.  We''ve been using hotplug scripts for ages. 
There
have been changes to these scripts recently, so something might have broken,
but no extra requirements.

If you''re not seeing any hotplug script logging at all you are going to
have to
trace the hotplug event until you find out where it disappears.  Start with
cat /proc/sys/kernel/hotplug.  If that''s udevsend and udevinfo -V
reports
greater than 059 then you are using udev, so check that
/etc/udev/rules.d/xen-backend.rules is in place, otherwise you are using 
hotplug, so put logging into /sbin/hotplug (usually a script)
and /etc/hotplug/xen-backend.agent.  Either way, you''ll need logging in
/etc/xen/scripts/block.

HTH,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Sorry for the delay.  I reinstalled from scratch and started
searching from the last working version.  (See status below.)
> > I don''t have a /var/log/debug or /var/log/syslog and 
> /var/log/messages
> > is unrevealing.  Do you mean xend.log and xend-debug.log?  If so,
> > attached (along with my very simple xmdefconfig).
> 
> No, I really meant /var/log/messages -- the hotplug scripts 
> log there, and you
> usually see hotplug or udev events going through there too.
Definitely no hotplug or udev events going into /var/log/messages.
 
> If you''re not seeing any hotplug script logging at all you 
> are going to have to
> trace the hotplug event until you find out where it 
> disappears.  Start with
> cat /proc/sys/kernel/hotplug.  If that''s udevsend and 
> udevinfo -V reports 
> greater than 059 then you are using udev, so check that
> /etc/udev/rules.d/xen-backend.rules is in place, otherwise 
> you are using 
cat /proc/sys/kernel/hotplug shows /sbin/hotplug
> hotplug, so put logging into /sbin/hotplug (usually a script)
> and /etc/hotplug/xen-backend.agent.  Either way, you''ll need 
> logging in
> /etc/xen/scripts/block.
By "put logging into" do you mean adding a ''-x'' at
the end
of the first (bin/sh) line?  If so, where is the logging going?
(not to the console nor to /var/log/xend.log...)  Sorry...
it''s been awhile since I''ve done script debugging and
it''s
definitely a lot different than hypervisor debugging :-}

Status: cset 8006 and cset 8029 both work fine.  Cset 8054 fails
with the "Hotplug scripts not working" message.  This narrows
the field considerably.  Cset 8043 and 8049 look suspicious.
For 8043, I thought maybe there is a dependency on the newly
added arch_memory_op call, but flagged that for ia64 and it
doesn''t appear to be the case.  Cset 8049: This isn''t intended
to stop use of a disk-in-a-file via the loopback driver, is it?

The xend.log and /etc/xen/xmdefconfig are the same as the last.
I''m building 8048 now (takes about an hour).

Thanks for all the help.  I''m getting closer...
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> The xend.log and /etc/xen/xmdefconfig are the same as the last.
> I''m building 8048 now (takes about an hour). 
Confirmed that cset 8048 works, so the problem starts between
cset 8049 and 8054. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 01, 2005 at 01:54:05PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> > The xend.log and /etc/xen/xmdefconfig are the same as the last.
> > I''m building 8048 now (takes about an hour). 
> 
> Confirmed that cset 8048 works, so the problem starts between
> cset 8049 and 8054. 
Well it can only be 8049 then.  I''d back that out for now until we
figure out
what the problem is.  That cset is flawed anyway -- there''s new changes
in that
area on the way -- but all the problems that we''ve seen before should
still
be logging things.  We''ll revisit this one when those new changes come
in.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 01, 2005 at 12:49:02PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Sorry for the delay.  I reinstalled from scratch and started
> searching from the last working version.  (See status below.)
> 
> > > I don''t have a /var/log/debug or /var/log/syslog and 
> > /var/log/messages
> > > is unrevealing.  Do you mean xend.log and xend-debug.log?  If so,
> > > attached (along with my very simple xmdefconfig).
> > 
> > No, I really meant /var/log/messages -- the hotplug scripts 
> > log there, and you
> > usually see hotplug or udev events going through there too.
> 
> Definitely no hotplug or udev events going into /var/log/messages.
>  
> > If you''re not seeing any hotplug script logging at all you 
> > are going to have to
> > trace the hotplug event until you find out where it 
> > disappears.  Start with
> > cat /proc/sys/kernel/hotplug.  If that''s udevsend and 
> > udevinfo -V reports 
> > greater than 059 then you are using udev, so check that
> > /etc/udev/rules.d/xen-backend.rules is in place, otherwise 
> > you are using 
> 
> cat /proc/sys/kernel/hotplug shows /sbin/hotplug
> 
> > hotplug, so put logging into /sbin/hotplug (usually a script)
> > and /etc/hotplug/xen-backend.agent.  Either way, you''ll need 
> > logging in
> > /etc/xen/scripts/block.
> 
> By "put logging into" do you mean adding a ''-x''
at the end
> of the first (bin/sh) line?  If so, where is the logging going?
> (not to the console nor to /var/log/xend.log...)  Sorry...
> it''s been awhile since I''ve done script debugging and
it''s
> definitely a lot different than hypervisor debugging :-}
Doing that writes to stderr, which unfortunately is going straight down
/dev/null, because this is being run by the kernel''s hotplug
infrastruture.

You can either use echo "Message" >~/my-log to write to a log file
of your own,
or log err "Message" to write to syslog (once you have included
xen-hotplug-common.h).
> Status: cset 8006 and cset 8029 both work fine.  Cset 8054 fails
> with the "Hotplug scripts not working" message.  This narrows
> the field considerably.  Cset 8043 and 8049 look suspicious.
> For 8043, I thought maybe there is a dependency on the newly
> added arch_memory_op call, but flagged that for ia64 and it
> doesn''t appear to be the case.  Cset 8049: This isn''t
intended
> to stop use of a disk-in-a-file via the loopback driver, is it?
No, it''s intended to protect you from mounting the same file twice in
this way,
but not to stop you from doing it the once.  If this check was failing, you
would get a different error message anyway.  You might try using
''w!'' as the
mode in your vbd config file rather than ''w''.  This will
bypass the checks,
which at least would point the figure at that particular chunk of code.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > By "put logging into" do you mean adding a
''-x'' at the end
> > of the first (bin/sh) line?  If so, where is the logging going?
> > (not to the console nor to /var/log/xend.log...)  Sorry...
> > it''s been awhile since I''ve done script debugging
and it''s
> > definitely a lot different than hypervisor debugging :-}
> 
> Doing that writes to stderr, which unfortunately is going 
> straight down
> /dev/null, because this is being run by the kernel''s hotplug 
> infrastruture.
> 
> You can either use echo "Message" >~/my-log to write to a log 
> file of your own,
> or log err "Message" to write to syslog (once you have included
> xen-hotplug-common.h).
Any suggestions as to where in the file would be illuminating?
And where is "syslog"? (not in /var/log... it''s a RHEL3
system)
 
> > Status: cset 8006 and cset 8029 both work fine.  Cset 8054 fails
> > with the "Hotplug scripts not working" message.  This
narrows
> > the field considerably.  Cset 8043 and 8049 look suspicious.
> > For 8043, I thought maybe there is a dependency on the newly
> > added arch_memory_op call, but flagged that for ia64 and it
> > doesn''t appear to be the case.  Cset 8049: This
isn''t intended
> > to stop use of a disk-in-a-file via the loopback driver, is it?
> 
> No, it''s intended to protect you from mounting the same file 
> twice in this way,
> but not to stop you from doing it the once.  If this check 
> was failing, you
> would get a different error message anyway.  You might try 
> using ''w!'' as the
> mode in your vbd config file rather than ''w''.  This will 
> bypass the checks,
> which at least would point the figure at that particular 
> chunk of code.
I can confirm now that cset 8048 works and 8049 does not.
Using ''w!'' does not make any difference.  I don''t see
any
changes in the changeset that look particularly interesting
from an ia64 perspective.  Do you see anything new that might
reach into the hypervisor that didn''t before?  Or perhaps
something new with evtchn (which has some differences on ia64)?

Any help/suggestions would be appreciated as we''d really like
to get Xen/ia64 working again before 3.0.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 01, 2005 at 04:39:03PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> 
> > > By "put logging into" do you mean adding a
''-x'' at the end
> > > of the first (bin/sh) line?  If so, where is the logging going?
> > > (not to the console nor to /var/log/xend.log...)  Sorry...
> > > it''s been awhile since I''ve done script
debugging and it''s
> > > definitely a lot different than hypervisor debugging :-}
> > 
> > Doing that writes to stderr, which unfortunately is going 
> > straight down
> > /dev/null, because this is being run by the kernel''s hotplug 
> > infrastruture.
> > 
> > You can either use echo "Message" >~/my-log to write to a
log
> > file of your own,
> > or log err "Message" to write to syslog (once you have
included
> > xen-hotplug-common.h).
> 
> Any suggestions as to where in the file would be illuminating?
Just keep shuffling them forward until they stop working ;-)  I really have no
idea -- I''d just binary chop until I found out where the problem was. 
> And where is "syslog"? (not in /var/log... it''s a RHEL3
system)
/var/log/messages is normal for Redhat, I think.  This is usually configurable
with /etc/syslog.conf or /etc/syslog-ng.conf, but hardly anyone changes from the
default!
> I can confirm now that cset 8048 works and 8049 does not.
> Using ''w!'' does not make any difference.  I
don''t see any
> changes in the changeset that look particularly interesting
> from an ia64 perspective.  Do you see anything new that might
> reach into the hypervisor that didn''t before?  Or perhaps
> something new with evtchn (which has some differences on ia64)?
Are you using really long file names for these loopback-mounted disks?  Someone
reported a failure with filenames greater than 64 chars today.  There''s
nothing IA64-specific that I''m aware of.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 1 Dec 2005, Ewan Mellor wrote:
> Doing that writes to stderr, which unfortunately is going straight down
> /dev/null, because this is being run by the kernel''s hotplug
infrastruture.
exec 2>> /tmp/shell-debug.log

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Confirmed that cset 8048 works, so the problem starts between
> > cset 8049 and 8054. 
> 
> Well it can only be 8049 then.  I''d back that out for now 
> until we figure out
> what the problem is.  That cset is flawed anyway -- there''s 
> new changes in that
> area on the way -- but all the problems that we''ve seen 
> before should still
> be logging things.  We''ll revisit this one when those new 
> changes come in.
When I apply (-R) "hg diff -r 8048 -r 8049" to tip (8154),
a number of hunks fail (block, block-common.sh, and DevController)
so this is easier said than done, especially for a shell/python
novice :-(

Do you see any easy way to turn off the intent of the patch
so I can test-disable it on ia64?  I''m about 100 csets behind
now (against xen-unstable) and I''ll bet there are other
problem csets waiting to be found.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 01, 2005 at 06:53:54PM -0600, Adam Heath wrote:
> On Thu, 1 Dec 2005, Ewan Mellor wrote:
> 
> > Doing that writes to stderr, which unfortunately is going straight
down
> > /dev/null, because this is being run by the kernel''s hotplug
infrastruture.
> 
> exec 2>> /tmp/shell-debug.log
Now _that''s_ useful!

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2 Dec 2005, Ewan Mellor wrote:
> On Thu, Dec 01, 2005 at 06:53:54PM -0600, Adam Heath wrote:
>
> > On Thu, 1 Dec 2005, Ewan Mellor wrote:
> >
> > > Doing that writes to stderr, which unfortunately is going
straight down
> > > /dev/null, because this is being run by the kernel''s
hotplug infrastruture.
> >
> > exec 2>> /tmp/shell-debug.log
>
> Now _that''s_ useful!
One of my standard tricks for debugging shells run automatically by some other
system, is to add the following lines at the top:

=exec 2>> /tmp/shell-debug.log
echo $$
date
=
It''d be nice if one could change stderr to go to a pipe, in standard
posix
shell.  One *can* do that in more advanced shells(zsh and bash, for example).

The bash syntax for the above is:

=mypid=$$
set -x
exec 2> >(perl -e
''$|=1;while(<STDIN>){s,^,\Q$ARGV[0]\E(\Q$ARGV[1]\E):
,;print}'' -- ProgramName $mypid | tee /tmp/shell-debug.log)
date
echo $$
echo test
echo foo 1>&2
=
Gives this in /tmp/shell-debug.log, in addition to still sending to stderr(one
could send things to syslog as well, by modifying the above):

=
=adam@gradall:~/code/dpkg/arch$ bash /tmp/foo.sh
Thu Dec  1 20:12:44 CST 2005
21787
test
adam@gradall:~/code/dpkg/arch$ ProgramName(21787): + date
ProgramName(21787): + echo 21787
ProgramName(21787): + echo test
ProgramName(21787): + echo foo
ProgramName(21787): foo

adam@gradall:~/code/dpkg/arch$ cat /tmp/shell-debug.log
ProgramName(21787): + date
ProgramName(21787): + echo 21787
ProgramName(21787): + echo test
ProgramName(21787): + echo foo
ProgramName(21787): foo
=
The only downside is the delayed printing of the backgrounded processing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Problem identified but it''s a weird one!  I turned on logging
in /etc/xen/scripts/block and /etc/hotplug/xen-backend.agent
using Adam''s cool trick of redirecting stderr output (exec
2>>file),
and discovered I *was* getting a message that domain0 already
was using the loopback device.

So I again tried turning on w! in /etc/xen/xmdefconfig
and this time it worked!

However, when I turned off logging, the w! no longer makes
the problem go away, and there is a long pause before the
"Error: Device 769... Hotplug scripts not working" message.
(Logging need only be enabled in xen-backend.agent to
make the problem again go away.)

Some weird timing problem?

My /etc/xen/xmdefconfig is very short:
kernel = "/tmp/xenlinux"
memory = 256
nics=0
disk = [''phy:loop0,hda1,w'']  # <-change to w!

and after a fresh boot, I am simply doing:

# lomount -t ext2 -diskimage /var/xen/hda /mnt
# xend start
# xm create

I can see how it could be interpreted that loop0 is
being used both by domain0 and the newly created domain,
but isn''t this a common use model?

Dan

P.S. When I change my /etc/xen/xmdefconfig to
disk = [''file:/var/xen/hda,hda1,w'']
mounting the root disk fails with:
UDF-fs: No VRS found
> -----Original Message-----
> From: Ewan Mellor [mailto:ewan@xensource.com] 
> Sent: Thursday, December 01, 2005 5:51 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Xen Mailing List
> Subject: Re: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domU stopped working
> 
> On Thu, Dec 01, 2005 at 04:39:03PM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> 
> > 
> > > > By "put logging into" do you mean adding a
''-x'' at the end
> > > > of the first (bin/sh) line?  If so, where is the logging
going?
> > > > (not to the console nor to /var/log/xend.log...)  Sorry...
> > > > it''s been awhile since I''ve done script
debugging and it''s
> > > > definitely a lot different than hypervisor debugging :-}
> > > 
> > > Doing that writes to stderr, which unfortunately is going 
> > > straight down
> > > /dev/null, because this is being run by the kernel''s
hotplug
> > > infrastruture.
> > > 
> > > You can either use echo "Message" >~/my-log to write
to a log
> > > file of your own,
> > > or log err "Message" to write to syslog (once you have
included
> > > xen-hotplug-common.h).
> > 
> > Any suggestions as to where in the file would be illuminating?
> 
> Just keep shuffling them forward until they stop working ;-)  
> I really have no
> idea -- I''d just binary chop until I found out where the problem
was.
> 
> > And where is "syslog"? (not in /var/log... it''s a
RHEL3 system)
> 
> /var/log/messages is normal for Redhat, I think.  This is 
> usually configurable
> with /etc/syslog.conf or /etc/syslog-ng.conf, but hardly 
> anyone changes from the
> default!
> 
> > I can confirm now that cset 8048 works and 8049 does not.
> > Using ''w!'' does not make any difference.  I
don''t see any
> > changes in the changeset that look particularly interesting
> > from an ia64 perspective.  Do you see anything new that might
> > reach into the hypervisor that didn''t before?  Or perhaps
> > something new with evtchn (which has some differences on ia64)?
> 
> Are you using really long file names for these 
> loopback-mounted disks?  Someone
> reported a failure with filenames greater than 64 chars 
> today.  There''s
> nothing IA64-specific that I''m aware of.
> 
> Ewan.
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Dec 02, 2005 at 09:41:39AM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Problem identified but it''s a weird one!  I turned on logging
> in /etc/xen/scripts/block and /etc/hotplug/xen-backend.agent
> using Adam''s cool trick of redirecting stderr output (exec
2>>file),
> and discovered I *was* getting a message that domain0 already
> was using the loopback device.
> 
> So I again tried turning on w! in /etc/xen/xmdefconfig
> and this time it worked!
> 
> However, when I turned off logging, the w! no longer makes
> the problem go away, and there is a long pause before the
> "Error: Device 769... Hotplug scripts not working" message.
> (Logging need only be enabled in xen-backend.agent to
> make the problem again go away.)
> 
> Some weird timing problem?
Possibly.  I''ve checked some code in today to serialise checks here, so
that
may well make the problem go away, but since you are only using one block
device, it seems to me that there might be an underlying problem.  You ought to 
get a proper error message rather than "scripts not working".  I would
guess
that the script''s bailing out before managing to write the
"hotplug-status" node
in the store, but if that goes away when you''re not logging,
that''s a little
weird.

Anyway, I''d be inclined to try the new changesets (not yet pushed to
the public
tree) and see if that improves things. 
> My /etc/xen/xmdefconfig is very short:
> kernel = "/tmp/xenlinux"
> memory = 256
> nics=0
> disk = [''phy:loop0,hda1,w'']  # <-change to w!
> 
> and after a fresh boot, I am simply doing:
> 
> # lomount -t ext2 -diskimage /var/xen/hda /mnt
> # xend start
> # xm create
> 
> I can see how it could be interpreted that loop0 is
> being used both by domain0 and the newly created domain,
> but isn''t this a common use model?
Only if you want to corrupt your filesystem!  Writing to that file via /mnt
in dom0 and via /dev/hda1 in the guest ought to corrupt your fs nicely.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Anyway, I''d be inclined to try the new changesets (not yet 
> pushed to the public
> tree) and see if that improves things. 
Same problem and same workaround on tip (8169).  Please
email when your new changesets get pushed and I will
try them.
> > My /etc/xen/xmdefconfig is very short:
> > kernel = "/tmp/xenlinux"
> > memory = 256
> > nics=0
> > disk = [''phy:loop0,hda1,w'']  # <-change to w!
> > 
> > and after a fresh boot, I am simply doing:
> > 
> > # lomount -t ext2 -diskimage /var/xen/hda /mnt
> > # xend start
> > # xm create
> > 
> > I can see how it could be interpreted that loop0 is
> > being used both by domain0 and the newly created domain,
> > but isn''t this a common use model?
> 
> Only if you want to corrupt your filesystem!  Writing to that 
> file via /mnt
> in dom0 and via /dev/hda1 in the guest ought to corrupt your 
> fs nicely.
Not as long as the image is only used from domU, correct?

What is the proper use model?  As I noted previously,
disk = [''file:/var/xen/hda,hda1,w''] results in a Linux
error message ("UDF-fs: No VRS found"... and, no, I do
not have any CD''s in /etc/fstab!).  Am I spelling
this xmdefconfig entry incorrectly?  Or is there
a better way to use a disk-in-a-file as root disk for
a guest domain?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I wonder if what I am seeing is the same problem described in this
thread. I am unable to create domUs on an x86_64 box, something which I
had been able to do even this morning:

VmError: Device 2070 (vbd) could not be connected. Backend device not
found.

[2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting for devices
vif.
[2005-12-02 15:11:25 xend] DEBUG (DevController:125) Waiting for 0.
[2005-12-02 15:11:25 xend] DEBUG (DevController:398)
hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
[2005-12-02 15:11:25 xend] DEBUG (DevController:398)
hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
[2005-12-02 15:11:25 xend] DEBUG (DevController:415)
hotplugStatusCallback 1.
[2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting for devices
usb.
[2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting for devices
vbd.
[2005-12-02 15:11:25 xend] DEBUG (DevController:125) Waiting for 2070.
[2005-12-02 15:11:25 xend] DEBUG (DevController:398)
hotplugStatusCallback /local/domain/0/backend/vbd/1/2070/hotplug-
status.[2005-12-02 15:11:25 xend] DEBUG (DevController:415)
hotplugStatusCallback 3.
[2005-12-02 15:11:25 xend] ERROR (SrvBase:87) Request wait_for_devices
failed.
Traceback (most recent call last):
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/web/SrvBase.py", line 85,
in perform
    return op_method(op, req)
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/xend/server/SrvDomain.py",
line 72, in op_wait_for_devices
    return self.dom.waitForDevices()
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py",
line 1276, in waitForDevices
    self.waitForDevices_(c)
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py",
line 923, in waitForDevices_
    return self.getDeviceController(deviceClass).waitForDevices()
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevController.py",
line 121, in waitForDevices
    return map(self.waitForDevice, self.deviceIDs())
  File "/tmp/xen-
unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevController.py",
line 137, in waitForDevice
    raise VmError("Device %s (%s) could not be connected. "
VmError: Device 2070 (vbd) could not be connected. Backend device not
found.


On Fri, 2005-12-02 at 12:40 -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> > Anyway, I''d be inclined to try the new changesets (not yet 
> > pushed to the public
> > tree) and see if that improves things. 
> 
> Same problem and same workaround on tip (8169).  Please
> email when your new changesets get pushed and I will
> try them.
> 
> > > My /etc/xen/xmdefconfig is very short:
> > > kernel = "/tmp/xenlinux"
> > > memory = 256
> > > nics=0
> > > disk = [''phy:loop0,hda1,w'']  # <-change to
w!
> > > 
> > > and after a fresh boot, I am simply doing:
> > > 
> > > # lomount -t ext2 -diskimage /var/xen/hda /mnt
> > > # xend start
> > > # xm create
> > > 
> > > I can see how it could be interpreted that loop0 is
> > > being used both by domain0 and the newly created domain,
> > > but isn''t this a common use model?
> > 
> > Only if you want to corrupt your filesystem!  Writing to that 
> > file via /mnt
> > in dom0 and via /dev/hda1 in the guest ought to corrupt your 
> > fs nicely.
> 
> Not as long as the image is only used from domU, correct?
> 
> What is the proper use model?  As I noted previously,
> disk = [''file:/var/xen/hda,hda1,w''] results in a Linux
> error message ("UDF-fs: No VRS found"... and, no, I do
> not have any CD''s in /etc/fstab!).  Am I spelling
> this xmdefconfig entry incorrectly?  Or is there
> a better way to use a disk-in-a-file as root disk for
> a guest domain?
> 
> Thanks,
> Dan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Well, unfortunately, the recent hotplug fixes didn''t fix my
problem.  In fact they made it worse; the w! and logging
workarounds no longer work so I can''t boot a domU at all.
I always get the same "Hotplug scripts not working" message.

However, now with tip (8213), I can send you xen-bugtool output
so have attached that and log output from /sbin/hotplug.

Any help would be appreciated!

Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel