I have a problem creating domU. Below is the error: --- ... RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Xen virtual console successfully installed as tty1 Event-channel device installed. xen_blk: Initialising virtual block device driver xen_blk: Timeout connecting to device! xen_net: Initialising virtual ethernet driver. NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "hda1" or unknown-block(2,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) --- The xen changeset is: Fri Sep 23 04:59:31 2005 43edce5b75d62213991842e441f8f11a29081a Here is my config file (I use command: "xm create -c tty.xen") -- kernel = "/boot/vmlinuz-2.6-xenU" memory = 64 maxmem = 90 name = "ttylinux" disk = [''file:/home/nah/rootfs.tty,hda1,w''] root = "/dev/hda1 ro" -- Anybody could tell me what is wrong? Many thanks. Hieu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 23, 2005 at 11:15:14PM +0900, NAHieu wrote:> I have a problem creating domU. Below is the error: > --- > ... > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > Xen virtual console successfully installed as tty1 > Event-channel device installed. > xen_blk: Initialising virtual block device driver > xen_blk: Timeout connecting to device! > xen_net: Initialising virtual ethernet driver. > NET: Registered protocol family 2 > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP established hash table entries: 4096 (order: 3, 32768 bytes) > TCP bind hash table entries: 4096 (order: 2, 16384 bytes) > TCP: Hash tables configured (established 4096 bind 4096) > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Root-NFS: No NFS server available, giving up. > VFS: Unable to mount root fs via NFS, trying floppy. > VFS: Cannot open root device "hda1" or unknown-block(2,0) > Please append a correct "root=" boot option > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)Jon Mason made a post yesterday where he tracked the problem down (for him) to the changeset "Move block device bind/unbind into hotplug scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc). I was running into the same problem, and so based on his detective work tried installing hotplug (actually hotplug and udev, but the first might be enough) in domain-0. Domain creation now works for me. Check to see if you have hotplug installed in your domain-0, and if not, whether installing it makes a difference. --Michael Vrable _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 23, 2005 at 10:37:59AM -0700, Michael Vrable wrote:> Jon Mason made a post yesterday where he tracked the problem down (for > him) to the changeset "Move block device bind/unbind into hotplug > scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc). I was running into > the same problem, and so based on his detective work tried installing > hotplug (actually hotplug and udev, but the first might be enough) in > domain-0. Domain creation now works for me. > > Check to see if you have hotplug installed in your domain-0, and if not, > whether installing it makes a difference.Actually, more testing shows that for me (minimal Debian sarge installation), udev does seems to be needed as well, hotplug alone doesn''t work. --Michael Vrable _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 23, 2005 at 10:43:11AM -0700, Michael Vrable wrote:> On Fri, Sep 23, 2005 at 10:37:59AM -0700, Michael Vrable wrote: > > Jon Mason made a post yesterday where he tracked the problem down (for > > him) to the changeset "Move block device bind/unbind into hotplug > > scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc). I was running into > > the same problem, and so based on his detective work tried installing > > hotplug (actually hotplug and udev, but the first might be enough) in > > domain-0. Domain creation now works for me. > > > > Check to see if you have hotplug installed in your domain-0, and if not, > > whether installing it makes a difference. > > Actually, more testing shows that for me (minimal Debian sarge > installation), udev does seems to be needed as well, hotplug alone > doesn''t work.Okay, hotplug _does_ work, if I reboot before testing. (Apparently, having udev installed switches /proc/sys/kernel/hotplug to point to /sbin/udevsend, but after a reboot hotplug by itself works.) --Michael Vrable _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 23/09/05, Michael Vrable <mvrable@cs.ucsd.edu> wrote:> Jon Mason made a post yesterday where he tracked the problem down (for > him) to the changeset "Move block device bind/unbind into hotplug > scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc). I was running into > the same problem, and so based on his detective work tried installing > hotplug (actually hotplug and udev, but the first might be enough) in > domain-0. Domain creation now works for me. > > Check to see if you have hotplug installed in your domain-0, and if not, > whether installing it makes a difference.I have the same error, I had ''hotplug-base'' installed, just added ''hotplug'' (these are gentoo ebuild names, hotplug-base installs /sbin/hotplug and hotplug is /etc/hotplug scripts). It made no difference, virtual block device still fails out. After a reboot /proc/sys/kernel/hotplug points to /sbin/udevsend, I don''t know what it should be for xen to work? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 23 Sep 2005, at 23:39, Chris Bainbridge wrote:> I have the same error, I had ''hotplug-base'' installed, just added > ''hotplug'' (these are gentoo ebuild names, hotplug-base installs > /sbin/hotplug and hotplug is /etc/hotplug scripts). It made no > difference, virtual block device still fails out. After a reboot > /proc/sys/kernel/hotplug points to /sbin/udevsend, I don''t know what > it should be for xen to work?On my box /proc/sys/kernel/hotplug points at /sbin/hotplug, which runs a script in /etc/hotplug.d/defaults which then runs the appropriate agent script (/etc/hotplug/xen-backend.agent). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24/09/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> On my box /proc/sys/kernel/hotplug points at /sbin/hotplug, which runs > a script in /etc/hotplug.d/defaults which then runs the appropriate > agent script (/etc/hotplug/xen-backend.agent).Ok, udevsend is the default hotplug event handler in Gentoo.. apparently /sbin/hotplug used to be, but has been deprecated ">From udev-047, udevd is capable of handling hotplug events from modules, as well as devices, and knows to call the appropriate hotplug rc script related to the module. (at module load, a hotplug event is generated by the kernel, and calls whatever is defined as the hotplug handler)." I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it works! Woohoo! I can now mount the virtual device. So... there is something wrong with either xen or udevsend that should be fixed. I have no experience with hotplug, but if someone can point me in the right direction I''ll try to debug. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24 Sep 2005, at 11:54, Chris Bainbridge wrote:> I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it > works! Woohoo! I can now mount the virtual device. So... there is > something wrong with either xen or udevsend that should be fixed. I > have no experience with hotplug, but if someone can point me in the > right direction I''ll try to debug.As I understand it, there are two standard locations for hotplug scripts. One is a directory called /etc/hotplug.d/<name>, the other is a file called /etc/hotplug/<name>.agent. We moved our script to the latter location, as we found that to work across debian, suse and redhat distros (unlike /etc/hotplug.d). You''ll probably find that udevsend is a shell script -- take a look and see if it tries to do any hotplug stuff. I guess it''s possible it is looking in /etc/hotplug.d. If so it really ought to be updated. Alternatively, some distros have /sbin/hotplug search in /etc/hotplug.d, but they add a script to /etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That gives you the benefit of searching in both locations. Anyway, I think it''s gentoo''s udevsend that is at fault here. Every other distro we know of searches /etc/hotplug/ these days. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
My problem has been fixed: I overwrited /etc/xen/scripts with the new scripts from tools/examples found in the tree. Now domU can be created. Many thanks, Hieu On 9/24/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 24 Sep 2005, at 11:54, Chris Bainbridge wrote: > > > I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it > > works! Woohoo! I can now mount the virtual device. So... there is > > something wrong with either xen or udevsend that should be fixed. I > > have no experience with hotplug, but if someone can point me in the > > right direction I''ll try to debug. > > As I understand it, there are two standard locations for hotplug > scripts. One is a directory called /etc/hotplug.d/<name>, the other is > a file called /etc/hotplug/<name>.agent. > > We moved our script to the latter location, as we found that to work > across debian, suse and redhat distros (unlike /etc/hotplug.d). You''ll > probably find that udevsend is a shell script -- take a look and see if > it tries to do any hotplug stuff. > > I guess it''s possible it is looking in /etc/hotplug.d. If so it really > ought to be updated. Alternatively, some distros have /sbin/hotplug > search in /etc/hotplug.d, but they add a script to > /etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That > gives you the benefit of searching in both locations. > > Anyway, I think it''s gentoo''s udevsend that is at fault here. Every > other distro we know of searches /etc/hotplug/ these days. > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24/09/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > I guess it''s possible it is looking in /etc/hotplug.d. If so it really > ought to be updated. Alternatively, some distros have /sbin/hotplug > search in /etc/hotplug.d, but they add a script to > /etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That > gives you the benefit of searching in both locations. > > Anyway, I think it''s gentoo''s udevsend that is at fault here. Every > other distro we know of searches /etc/hotplug/ these days.Gentoo has a udev rule that runs /sbin/udev_run_hotplugd (from /etc/udev/rules.d/50-udev.rules): # be backward compatible for a while with the /etc/dev.d and /etc/hotplug.d/ systems # run /etc/hotplug.d/ stuff only if we came from a hotplug event, not for udevstart ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd" The path /etc/hotplug.d is hardcoded into udev_run_hotplugd - it doesn''t search anywhere else. I don''t understand why it doesn''t run the agent scripts in /etc/hotplug. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24 Sep 2005, at 21:00, Chris Bainbridge wrote:> # be backward compatible for a while with the /etc/dev.d and > /etc/hotplug.d/ systems > # run /etc/hotplug.d/ stuff only if we came from a hotplug event, not > for udevstart > ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd" > > The path /etc/hotplug.d is hardcoded into udev_run_hotplugd - it > doesn''t search anywhere else. I don''t understand why it doesn''t run > the agent scripts in /etc/hotplug.Many distros have a file /etc/hotplug.d/defaults/default.hotplug. It runs on every hotplug event and runs the appropriate ''agent'' script in /etc/hotplug/. You might want to try stealing that script from a non-gentoo box (I''ve temporarily placed a copy at http://www.cl.cam.ac.uk/~kaf24/default.hotplug). If it works, you should probably try and get it added to the appropriate gentoo package. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26 Sep 2005, at 13:47, Greg KH wrote:> It does just that. Look at /etc/hotplug.d/default/ directory and see > the file "default.hotplug"? That is what this file does. > > Soon, for Gentoo, that file will go away (well, actually the udev rule > to run that will go away first) and then you will need to use udev > rules > to handle everything for hotplug. Other distros have already switched > over to this method with very good results.Greg, At the moment, installing our script at /etc/hotplug/xen-backend.agent ''just works'' for us. Are we going to need to do anything more, or relocate our script, to get our script called on udev-only systems? And would there be any danger of our script being called twice on some systems (once via udev; once via hotplug)? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26 Sep 2005, at 15:14, Greg KH wrote:> That''s been "depreciated" for quite some time now. I would recommend > you switch to moving your script to /etc/hotplug.d/xen/ or > /etc/hotplug.d/default/ (depending on how your hotplug event is being > created. Which reminds me, how is it? Pointers to code anywhere?)We originally placed the script in /etc/hotplug.d/xen, but found that didn''t work on some distros. Can''t remember which ones, nor how old they were. We should perhaps detect such systems and treat them specially in our install script, and move the script back to /etc/hotplug.d by default. Our main hotplug event function is in drivers/xen/xenbus/xenbus_probe.c, I think (it''s used by our network driver at least). Actually xenbus registers all our virtual devices with sysfs, and I guess that generates some hotplug events automatically? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> At the moment, installing our script at /etc/hotplug/xen-backend.agent > ''just works'' for us.Doesn''t work on SUSE Linux 10.0 as well, as all the agents are gone here as well. The huge stack of shell scripts was replaced with a few udev rules, so it''s easier to see what''s going on and it also is much faster. I''ve attached my current configuration. ifup-xen goes to /sbin, the rules file into /etc/udev/rules.d. With those two files in place auto-adding interfaces to the bridge WorksForMe[tm]. The script is sort of a hack though, quickly created from the vif-bridge script, with no way to configure stuff at the moment. cheers, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Sep 26, 2005 at 03:41:38PM +0100, Keir Fraser wrote:> > On 26 Sep 2005, at 15:14, Greg KH wrote: > > >That''s been "depreciated" for quite some time now. I would recommend > >you switch to moving your script to /etc/hotplug.d/xen/ or > >/etc/hotplug.d/default/ (depending on how your hotplug event is being > >created. Which reminds me, how is it? Pointers to code anywhere?) > > We originally placed the script in /etc/hotplug.d/xen, but found that > didn''t work on some distros. Can''t remember which ones, nor how old > they were. We should perhaps detect such systems and treat them > specially in our install script, and move the script back to > /etc/hotplug.d by default.Yes, some very old distros did not have the multiplexed /sbin/hotplug program which would run stuff in /etc/hotplug.d/, but they should be all gone now :)> Our main hotplug event function is in > drivers/xen/xenbus/xenbus_probe.cHave an online source browser anywhere?>, I think (it''s used by our network driver at least). Actually xenbus >registers all our virtual devices with sysfs, and I guess that >generates some hotplug events automatically?Yes, it will. You should _never_ call /sbin/hotplug on your own. The one last holdout in the kernel is the input subsystem, and that will be fixed very soon. thanks, greg k-h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Our main hotplug event function is in >> drivers/xen/xenbus/xenbus_probe.c > > Have an online source browser anywhere?http://lxr.xensource.com/lxr-unstable/source/drivers/xen/xenbus/ xenbus_probe.c?v=linux-2.6.12-xen-xen-unstable>> , I think (it''s used by our network driver at least). Actually xenbus >> registers all our virtual devices with sysfs, and I guess that >> generates some hotplug events automatically? > > Yes, it will. You should _never_ call /sbin/hotplug on your own. The > one last holdout in the kernel is the input subsystem, and that will be > fixed very soon.Looks like we don''t call it directly. I think our ''hotplug'' function just adds useful extra variables to the environment and leaves it to sysfs to do the actual upcalls. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/09/05, Gerd Knorr <kraxel@suse.de> wrote:> > I''ve attached my current configuration. ifup-xen goes to /sbin, the > rules file into /etc/udev/rules.d. With those two files in place > auto-adding interfaces to the bridge WorksForMe[tm].Can you post your udev rules/scripts for virtual block devices? Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Sep 26, 2005 at 04:41:16PM +0100, Keir Fraser wrote:> > >>Our main hotplug event function is in > >>drivers/xen/xenbus/xenbus_probe.c > > > >Have an online source browser anywhere? > > http://lxr.xensource.com/lxr-unstable/source/drivers/xen/xenbus/ > xenbus_probe.c?v=linux-2.6.12-xen-xen-unstableThanks for the link.> >>, I think (it''s used by our network driver at least). Actually xenbus > >>registers all our virtual devices with sysfs, and I guess that > >>generates some hotplug events automatically? > > > >Yes, it will. You should _never_ call /sbin/hotplug on your own. The > >one last holdout in the kernel is the input subsystem, and that will be > >fixed very soon. > > Looks like we don''t call it directly. I think our ''hotplug'' function > just adds useful extra variables to the environment and leaves it to > sysfs to do the actual upcalls.Yes, that is exactly what happens. thanks, greg k-h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I have enabled debug in udev and hotplug. From the udevsend man page:
udevd takes care of the kernel supplied sequence number and arranges
the events for execution in the correct order. Missing sequences delay
the execution of the following events until a timeout is reached.
Is it possible that the events aren''t being supplied in the correct
order by xen, or there is some race condition, that would cause xen to
timeout before the event arrives?
Here is a log of /sbin/hotplug, which works:
Sep 27 15:55:32 xenmaster store_evtchn = 19
Sep 27 15:55:32 xenmaster default.hotplug[2352]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug HOME=/
SHLVL=2 INTERFACE=xen-br0 DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 15:55:32 xenmaster default.hotplug[2352]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:55:32 xenmaster net.agent[2352]: add event not handled
Sep 27 15:55:32 xenmaster default.hotplug[2376]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=xen-br0
DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 15:55:32 xenmaster default.hotplug[2376]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:55:32 xenmaster net.agent[2376]: add event not handled
Sep 27 15:57:00 xenmaster default.hotplug[2398]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug
XENBUS_PATH=backend/vbd/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/769
HOME=/ SHLVL=2 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2398]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2403]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331
_=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2403]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2422]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=online mac=aa:00:00:00:00:11
PWD=/etc/hotplug domain=ubuntu bridge=xen-br0
XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1 HOME=/
SHLVL=2 PHYSDEVDRIVER=vif DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=334
_=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2420]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug HOME=/
SHLVL=2 INTERFACE=vif1.1 DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2420]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2422]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster xen-backend.agent[2422]: in
xen-backend.agent (ACTION=online XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster xen-backend.agent[2403]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 15:57:00 xenmaster device vif1.1 entered promiscuous mode
Sep 27 15:57:00 xenmaster xen-br0: port 1(vif1.1) entering learning state
Sep 27 15:57:00 xenmaster xen-br0: topology change detected, propagating
Sep 27 15:57:00 xenmaster xen-br0: port 1(vif1.1) entering forwarding state
Sep 27 15:57:00 xenmaster default.hotplug[2417]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug
XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1 HOME=/
SHLVL=2 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2417]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster net.agent[2420]: add event not handled
Sep 27 15:57:00 xenmaster xen-backend.agent[2417]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster default.hotplug[2453]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332
_=/bin/env)
Sep 27 15:57:00 xenmaster xen-backend.agent[2398]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 15:57:00 xenmaster default.hotplug[2453]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster xen-backend.agent[2453]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster default.hotplug[2430]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2430]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:57:00 xenmaster net.agent[2430]: add event not handled
Sep 27 15:57:00 xenmaster default.hotplug[2500]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1 ACTION=online
PWD=/etc/hotplug UDEV_LOG=3 mac=aa:00:00:00:00:11 domain=ubuntu
bridge=xen-br0 XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1
UDEVD_EVENT=1 SHLVL=1 PHYSDEVDRIVER=vif DEBUG=yes
PHYSDEVBUS=xen-backend SEQNUM=334 _=/bin/env)
And udevsend, which fails:
Sep 27 16:08:51 xenmaster store_evtchn = 19
Sep 27 16:08:51 xenmaster default.hotplug[2297]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=xen-br0
DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 16:08:51 xenmaster default.hotplug[2297]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:08:51 xenmaster net.agent[2297]: add event not handled
Sep 27 16:09:17 xenmaster default.hotplug[2332]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/3e2182e4-998e-4191-863c-a60d0f1d6962/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331
_=/bin/env)
Sep 27 16:09:17 xenmaster default.hotplug[2332]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster xen-backend.agent[2332]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 16:09:17 xenmaster default.hotplug[2337]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332
_=/bin/env)
Sep 27 16:09:17 xenmaster default.hotplug[2337]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster default.hotplug[2344]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 16:09:17 xenmaster xen-backend.agent[2337]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 16:09:17 xenmaster default.hotplug[2344]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:09:17 xenmaster default.hotplug[2375]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1 ACTION=online
PWD=/etc/hotplug UDEV_LOG=3 mac=aa:00:00:00:00:11 domain=ubuntu
bridge=xen-br0 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 PHYSDEVDRIVER=vif DEBUG=yes
PHYSDEVBUS=xen-backend SEQNUM=334 _=/bin/env)
Sep 27 16:09:17 xenmaster net.agent[2344]: add event not handled
Sep 27 16:09:17 xenmaster default.hotplug[2375]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster xen-backend.agent[2375]: in
xen-backend.agent (ACTION=online XENBUS_TYPE=vif)
Sep 27 16:09:27 xenmaster default.hotplug[2412]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=remove PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=335
_=/bin/env)
Sep 27 16:09:27 xenmaster default.hotplug[2414]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=remove PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/3e2182e4-998e-4191-863c-a60d0f1d6962/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=336
_=/bin/env)
Sep 27 16:09:27 xenmaster default.hotplug[2412]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:28 xenmaster default.hotplug[2414]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:28 xenmaster xen-backend.agent[2412]: in
xen-backend.agent (ACTION=remove XENBUS_TYPE=vif)
Sep 27 16:09:28 xenmaster xen-backend.agent[2414]: in
xen-backend.agent (ACTION=remove XENBUS_TYPE=vbd)
Sep 27 16:09:28 xenmaster default.hotplug[2448]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=remove
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=337 _=/bin/env)
Sep 27 16:09:28 xenmaster default.hotplug[2448]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:09:28 xenmaster net.agent[2448]: remove event not handled
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
I finally got it working under Gentoo by abandoning all the hotplug
stuff and just using a few udev rules:
xen udev # cat rules.d/49-xen.rules
SUBSYSTEM=="xen-backend", KERNEL=="vif*",
ACTION=="online",
RUN+="/etc/xen/scripts/launch up"
SUBSYSTEM=="xen-backend", KERNEL=="vbd*",
ACTION=="add",
RUN+="/etc/xen/scripts/vbd-add %k"
SUBSYSTEM=="xen-backend", KERNEL=="vbd*",
ACTION=="remove",
RUN+="/etc/xen/scripts/vbd-remove %k"
SUBSYSTEM=="xen-backend", KERNEL=="vif*",
ACTION=="remove",
RUN+="/etc/xen/scripts/vif-remove %k"
xen udev # cd /etc/xen/scripts/
xen scripts # cat launch
#!/bin/sh
# the script is specified in xend config
# and passed to us. we just call it.
export PATH="/sbin:/bin:/usr/sbin:/usr/bin:$PATH"
#echo "$(date): launch $1"
#env
#echo "Running ${script} $1"
${script} $1
xen scripts # cat vbd-add
#!/bin/sh
t=$(xenstore-read "$XENBUS_PATH"/type)
params=$(xenstore-read "$XENBUS_PATH"/params)
[ -x /etc/xen/scripts/block-"$t" ] && \
/etc/xen/scripts/block-"$t" bind $params
xen scripts # cat vbd-remove
#!/bin/sh
t=$(xenstore-read "$XENBUS_PATH"/type)
node=$(xenstore-read "$XENBUS_PATH"/node)
[ -x /etc/xen/scripts/block-"$t" ] && \
/etc/xen/scripts/block-"$t" unbind $node
# remove device backend store entries
xenstore-rm "$XENBUS_PATH"
xen scripts # cat vif-remove
#!/bin/sh
# remove device backend store entries
xenstore-rm "$XENBUS_PATH"
/sbin/ip link set ${dev} down
/sbin/brctl delif ${bridge} ${dev}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Chris Bainbridge wrote:> On 26/09/05, Gerd Knorr <kraxel@suse.de> wrote: >> I''ve attached my current configuration. ifup-xen goes to /sbin, the >> rules file into /etc/udev/rules.d. With those two files in place >> auto-adding interfaces to the bridge WorksForMe[tm]. > > Can you post your udev rules/scripts for virtual block devices? Thanks.Uhm, well, the above was with a older xen-unstable which hasn''t the hotplug-ified setup for disks yet. Attached below is my current setup, running flawlessly with a fresh checkout. The rules file goes to /etc/udev/rules.d, the xen-* shell scripts to /sbin. No dependency on hotplug any more, everything is invoked directly via udev (or udevd), so this should create much less trouble than the xen-hotplug.agent stuff. cheers & enjoy Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel