@Patrick
I was looking into your theory about the losetup twice.
I am trying to compare vs. the current block file in xen-unstable:
http://xenbits.xensource.com/xen-unstable.hg?file/78a29cf8476b/tools/examples/block
I am not so sure that that is the problem. Can you take a closer look?
Would
The issue is very simple:
in the /etc/xen/scripts/block script it creates the loopback device
twice
First it does it with losetup /dev/loopx /some-image
Then if you want read-only it does
losetup -r /dev/loopx /some-image
and this second one fails cause the first one already mounted it
So Could we please clarify a couple of things:
- Is the current Xen3.2 (the one in the repos) patched and working with the
tap:aio tip?
- Is there a working Xen3.2 on Ubuntu Hardy? (somewhere in a private repo)?
- What of thos patches should be OK, which of them should be applied,... any
Not yet,
As it seems the bug still persists and the only available solution is
the phy /dev/loop trick...
Hope it will be soon fixed, couse it is making the everyday hvm testing
work such a pain...
--
losetup fails when using the 'file:/', preventing the DomU from being created
Anyone out there familiar with this issue and capable of troubleshooting
it? Its a real showstopper for any kind of automation.
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you
Confirming: booting HVM from cdrom-iso as tap:aio: does not work! (As
mentioned before, losetup and phy: did the trick...)
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you are a
xen-tools needs to be patched to use tap:aio: instead of file:
it's not a massive changed, 1 line in xen-create-image,
file
** Attachment added: xen-create-image.patch
http://launchpadlibrarian.net/13988811/xen-create-image.patch
--
losetup fails when using the 'file:/', preventing the DomU
For the installation itself i'm not sure, by the time I discovered I had
to use tap:aio: I had already installed the OS using the /dev/loop
trick.
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug
Elie, when you use tap:aio: the mount of the iso for installing the os
was working well ?
Because I didn't work and I had to use the workaround of mounting them
in de Dom0 and passing it with phy:/dev/loop*
--
losetup fails when using the 'file:/', preventing the DomU from being created
For me using tap:aio: fixed it for both my PVM'ed centos and my HVM'ed
win2k3.
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
In Hardy using tap:aio: fixed this issue for PVM guests but with HVM
guests I get these errors.
I always get this in xen-hotplug.log:
xenstore-read: couldn't read path /local/domain/1/vm
xenstore-read: couldn't read path /local/domain/1/vm
for HVM guests i have to manually setup the loopbacks
It's annoying and poorly documented but it now seems necessary to use
tap:aio instead of file.
i.e. for your example:
disk = [ 'tap:aio:/images/win2k3disk.img,ioemu:hda,w',
'tap:aio:/images/win2k3iso.img,ioemu:hdc:cdrom,r']
This should work.
--
losetup fails when using the 'file:/',
I beg your pardon, I didn't read the first line of your bug report!
But yes I can confirm the same problems with losetup ... or rather with
the xen block daemon, which called losetup and then broke.
--
losetup fails when using the 'file:/', preventing the DomU from being created
I simply wanted to confirm this error, I did an minimal install from the
ubuntu 8.04 server edition beta iso (without any fancy extras except
openssh and xen).
and replaching
disk = ['file:/images/win2k3disk.img,ioemu:hda,w',
'file:/images/win2k3iso.img,ioemu:hdc:cdrom,r']
by
disk =
Hotplug
** Attachment added: xen-hotplug.log
http://launchpadlibrarian.net/13107939/xen-hotplug.log
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you are a member of Ubuntu
** Attachment added: beastie.cfg
http://launchpadlibrarian.net/13107920/beastie.cfg
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Qemu Log
** Attachment added: qemu-dm-9.log
http://launchpadlibrarian.net/13107933/qemu-dm-9.log
--
losetup fails when using the 'file:/', preventing the DomU from being created
https://bugs.launchpad.net/bugs/211726
You received this bug notification because you are a member of Ubuntu
Bugs,
Bizarelly, losetup fails - but the devices are there, e.g.:
[EMAIL PROTECTED]:~# losetup -a
/dev/loop0: [0807]:26738701 (/home/xen/domains/beastie/disk.img)
/dev/loop1: [0807]:26738703 (/home/xen/domains/beastie/freebsd7bootonly.iso)
niere_ in #xen on Freenode recommended manually running
18 matches
Mail list logo
