Mailing List Archive

> I get a:
> Error: Adding extent to vbd failed: device (vbd (uname
> file:/xen/slackware-linux-10/linu.img) (dev hda1) (mode w)), error 8

> My dom0-OS is NetBSD 3.0_BETA, btw. This may explain a lot,
> still I'd like to have as much detailed information as possible ;)

I'll bet you'll need to hack the /etc/xen/scripts/block-file script to
work on NetBSD unless the syntax for losetup is identical.

Ian

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

On Sun, Jun 12, 2005 at 09:27:48AM +0100, Ian Pratt wrote:
> > I get a:
> > Error: Adding extent to vbd failed: device (vbd (uname
> > file:/xen/slackware-linux-10/linu.img) (dev hda1) (mode w)), error 8
>
> > My dom0-OS is NetBSD 3.0_BETA, btw. This may explain a lot,
> > still I'd like to have as much detailed information as possible ;)
>
> I'll bet you'll need to hack the /etc/xen/scripts/block-file script to
> work on NetBSD unless the syntax for losetup is identical.


Ah, so those files are loopmounted, like in mount -o loop ...?
(Net,Open, Maybe DragonFly)BSD use a different system, with slightly
other syntaxes. Here is the diff I hacked quickly (just taking NetBSD
into account):

[diff]
6c6
< # loop device. We print the path to the loop device node to stdout.
---
> # loop/vnd device. We print the path to the loop/vnd device node to stdout.
10a11,21
> if test `uname -s` = "Linux"; then
> SETUPCMD="losetup"
> UNBINDSWITCH="-d"
> DEVICEFILES="/dev/loop*"
> fi
> if test `uname -s` = "NetBSD"; then
> SETUPCMD="vnconfig"
> UNBINDSWITCH="-u"
> DEVICEFILES="`ls /dev/vnd* | sed 's/\/dev\///' | awk '{ print substr($0,
0,4)}'| sort -u`"
> fi
>
13,14c24,25
< for dev in /dev/loop*; do
< if losetup $dev $2; then
---
> for dev in $DEVICEFILES; do
> if $SETUPCMD $dev $2; then
23c34
< losetup -d $2
---
> $SETUPCMD $UNBINDSWITCH $2
[/diff]

If you prefer a different diff(1) method, tell me :)

However, that gives me:
Error: Error creating domain: vbd: Segment not found: uname=file:/xen/slackware-linux-10/linux.img

I don't know how that "uname=" thing came into there


>
> Ian
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

> > > My dom0-OS is NetBSD 3.0_BETA, btw. This may explain a lot,
> > > still I'd like to have as much detailed information as possible ;)

I imagine the error is just a "command not found error" - it's not a normal
Xend error.

> > I'll bet you'll need to hack the /etc/xen/scripts/block-file script to
> > work on NetBSD unless the syntax for losetup is identical.
>
> Ah, so those files are loopmounted, like in mount -o loop ...?

Yes, basically. (They're bound to a loop device but not actually mounted).

> (Net,Open, Maybe DragonFly)BSD use a different system, with slightly
> other syntaxes. Here is the diff I hacked quickly (just taking NetBSD
> into account):

Ah, great. I thought it probably wouldn't work on BSD :-) I did wonder what
the NetBSD guys had done about it.

<snip>
> If you prefer a different diff(1) method, tell me :)

Thanks for the patch. We should get it merged once you can confirm
everything's working as expected!

> However, that gives me:
> Error: Error creating domain: vbd: Segment not found:
> uname=file:/xen/slackware-linux-10/linux.img
>
> I don't know how that "uname=" thing came into there

The "uname" format is the {file,phy,nbd}:/{path}:{other stuff} form we use to
describe the "source device" in dom0.

The "segment not found" message suggests that the device node output from the
block script was not found in /dev. That's probably because you're stripping
off the "/dev" prefix in order to fit with the BSD command syntax. Xend
probably needs the full path in order to find the device node - if you
prepend /dev to the name of the device before the script echos it then it
should work.

If you can get this working, then a patch would be very welcome.

Cheers,
Mark

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

On Sun, Jun 19, 2005 at 05:08:56PM +0100, Mark Williamson wrote:
> The "uname" format is the {file,phy,nbd}:/{path}:{other stuff} form we use to
> describe the "source device" in dom0.
>

ah ok. A question: Why the the error-message that cryptic :) ?
Isn't it (easily) possible to give out the involved line, or a short
description why it failed or at least replacing "segment" with "device"?
(The latter is another question, why is it a "segment"?)

Anyway...

> The "segment not found" message suggests that the device node output from the
> block script was not found in /dev. That's probably because you're stripping
> off the "/dev" prefix in order to fit with the BSD command syntax. Xend

Yes I do. See below, tho

> probably needs the full path in order to find the device node - if you
> prepend /dev to the name of the device before the script echos it then it
> should work.
>

Well, I have another config, this time it is just a "test"-case, it uses:
disk = ['phy:/dev/wd0a,0x3301,w' ]

(The NetBSD-guide noted that xen wants to look-up the second argument,
and make something so linux likes it better or whatever; However the guide
says that xen would try to lookup hde1 on netbsd (that is not there);
Said guide is http://www.NetBSD.org/Ports/xen/howto.html . Scroll down to
"Create Linux unprivileged domains". (Actually, is major << 8 + minor of
hde1 0x3301 :D ?))

However, that also gives me that error, so "uname=phy:/dev/wd0a". And trust
me, that is there ;)

> If you can get this working, then a patch would be very welcome.

Well I deleted the sed-part that made /dev/ disappear. This time I
get the old error, device (vbd (uname file:/xen/...) (dev hda1) (mode w)),
error 8

>
> Cheers,
> Mark
>

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

> ah ok. A question: Why the the error-message that cryptic :) ?
> Isn't it (easily) possible to give out the involved line, or a short
> description why it failed or at least replacing "segment" with "device"?
> (The latter is another question, why is it a "segment"?)

Yes, this error probably should be made a bit more descriptive. It probably
hasn't got done yet because it doesn't come up often - just that when it does
it really confuses people!

The message says "segment" for historical reasons: the block backend used to
implement a basic LVM-style concatenated device abstraction. The devices the
guest saw were made up of "segments" of real disks. Since the restructure
for Xen 2.0 this is not necessary, since we can use real LVM where this
capability is required.

> (The NetBSD-guide noted that xen wants to look-up the second argument,
> and make something so linux likes it better or whatever; However the guide
> says that xen would try to lookup hde1 on netbsd (that is not there);
> Said guide is http://www.NetBSD.org/Ports/xen/howto.html . Scroll down to
> "Create Linux unprivileged domains". (Actually, is major << 8 + minor of
> hde1 0x3301 :D ?))

At some point, Xend acquired code to convert handle Linux-style devices even
if there aren't corresponding device nodes present - so it might Just Work
with the Linux device name.

Your devid looks OK, though.

> However, that also gives me that error, so "uname=phy:/dev/wd0a". And trust
> me, that is there ;)

Interesting. That device isn't mounted or something is it? If it is, the
tools should stop you using it, although IIRC they should produce a more
useful error message in this case.

> > If you can get this working, then a patch would be very welcome.
>
> Well I deleted the sed-part that made /dev/ disappear. This time I
> get the old error, device (vbd (uname file:/xen/...) (dev hda1) (mode w)),
> error 8

Hmmm, weird. It might be worth poking in the Xen code and trying to figure
out where this error is coming from. Could it actually be an errno value?

Cheers,
Mark

> > Cheers,
> > Mark
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

On Mon, Jun 20, 2005 at 04:28:12PM +0100, Mark Williamson wrote:
> > However, that also gives me that error, so "uname=phy:/dev/wd0a". And trust
> > me, that is there ;)
>
> Interesting. That device isn't mounted or something is it? If it is, the
> tools should stop you using it, although IIRC they should produce a more
> useful error message in this case.
>

Nope, not mounted. However, if I do phy:0x301,... it works but gives me
the error-8 that I already described below.


> > > If you can get this working, then a patch would be very welcome.
> >
> > Well I deleted the sed-part that made /dev/ disappear. This time I
> > get the old error, device (vbd (uname file:/xen/...) (dev hda1) (mode w)),
> > error 8
>
> Hmmm, weird. It might be worth poking in the Xen code and trying to figure
> out where this error is coming from. Could it actually be an errno value?
>

strerror(8) is "Exec format error". I do not see a related, do you do?


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

On Wed, Jun 22, 2005 at 05:07:28PM +0200, Sascha Retzki wrote:
> > > Well I deleted the sed-part that made /dev/ disappear. This time I
> > > get the old error, device (vbd (uname file:/xen/...) (dev hda1) (mode w)),
> > > error 8
> >

I can reproduce that on Xen/Linux (finally got that to work).
a file:/ entry works for disk, but not phy:. The testcase I do is a
cdrom-drive, so the line is:

disk = ['file:/xen/slack/linux.img,hda,w' ,
'phy:/dev/hdd,hdd,r']

I tried to reverse the order, and to make that a one-liner, so I suspect
it is a parsing-problem. Anyway, all phy: stuff failing sounds a bit
strange ;-)

Sooo, anybody an idea why that fails? Ideas where it failes, or how
I could track down the latter (not much python skills, not much
kernel-skills ;-))

What is the second argument, btw? Is it the name of the device the domU
"sees"?

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