From: Philipp Hahn <hahn@univention.de>
To: xen-devel@lists.xensource.com
Subject: Re: Fw: [PATCH] blktap2: blktap2 and pygrub (xen-unstable)
Date: Thu, 11 Nov 2010 14:31:03 +0100 [thread overview]
Message-ID: <201011111431.08622.hahn@univention.de> (raw)
In-Reply-To: <AANLkTi=CRsqNV1K0L2QM+_4sfFLL1Ns-0q+-e2O7hoUR@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]
Hello,
Am Montag 08 November 2010 13:40:29 schrieb Łukasz Oleś:
> 2010/11/1 Łukasz Oleś <lukaszoles@gmail.com>:
> > On Monday 16 August 2010 18:35:10 Stefano Stabellini wrote:
> >> On Sun, 1 Aug 2010, Boris Derzhavets wrote:
> >> > Forwarding to you original patch requested.
> >> > It works for me.
For me to, but I observed some kind of race condition probably between udev
creating the device node and pygrub acessing it: The first start of my domain
failed with "Disk isn't accessible", while subsequent starts worked fine. I
could reproduce this after doing a reboot: 1st start failed, further starts
worked fine.
After adding the following hack it even worked on a freshly rebooted system.
(For my case the loop always exited on the second iteration.)
--- a/xen-4.0.1/tools/python/xen/xend/XendBootloader.py 2010-11-01
15:33:59.000000000 +0100
+++ b/xen-4.0.1/tools/python/xen/xend/XendBootloader.py 2010-11-11
13:36:13.000000000 +0100
@@ -15,6 +15,7 @@
import os, select, errno, stat, signal, tty
import random
import shlex
+import time
from xen.xend import sxp
from xen.util import mkdir, oshelp
@@ -35,13 +36,18 @@
@param blargs Arguments to pass to the bootloader."""
if not os.access(blexec, os.X_OK):
- msg = "Bootloader isn't executable"
+ msg = "Bootloader '%s' isn't executable" % blexec
log.error(msg)
raise VmError(msg)
- if not os.access(disk, os.R_OK):
+
+ retries = 10
+ while not os.access(disk, os.R_OK):
- msg = "Disk isn't accessible"
+ msg = "Disk '%s' isn't accessible" % disk
log.error(msg)
- raise VmError(msg)
+ time.sleep(1)
+ retries -= 1
+ if retries <= 0:
+ raise VmError(msg)
if os.uname()[0] == "NetBSD" and disk.startswith('/dev/'):
disk = disk.replace("/dev/", "/dev/r")
BYtE
Philipp
--
Philipp Hahn Open Source Software Engineer hahn@univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
prev parent reply other threads:[~2010-11-11 13:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-01 19:12 Fw: [PATCH] blktap2: blktap2 and pygrub (xen-unstable) Boris Derzhavets
2010-08-16 16:35 ` Stefano Stabellini
2010-10-31 23:21 ` Łukasz Oleś
2010-11-08 12:40 ` Łukasz Oleś
2010-11-11 13:31 ` Philipp Hahn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011111431.08622.hahn@univention.de \
--to=hahn@univention.de \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.