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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home