On 5/9/13 5:14 AM, Miguel Clara wrote:
Understood and I didn't explain it well. Instead of having a line in /etc/rc.conf that says xend=YES, what you can also do is to have file named xencommons under /etc/rc.conf.d that contains the line xend=YES. See /etc/rc.subr:load_rc_config() for why this works. Granted that you don't want xend to turn be turned on, but if you do, you can have another file named xend under /etc/rc.conf.d that contains the line xend=YES. I find this a bit gnarly and I'm not sure why it was done that way, but maybe it was to reduce surprises with missing a new setting when moving from xen 3.3, who knows.This is xen 4.2... xend is not needed unless I wanted to use xm... I commented that line btw! I solved it the lazy way for now with a symlink so both locations work, but I would like to understand what is wrong. Thanks for the feedback. Sent from my BlackBerry 10 smartphone.
Alternatively, if you want the name of the knob to be xencommons, you can change the xencommons rc.d script so that rcvar=xencommons or rcvar=$name.
Onto the issue of getting differing ${DIR} during boot vs when invoked manually (e.g. /etc/rc.d/xencommons start), that's because /etc/rc basically just sources each file in /etc/rc.d during boot, in which case $0 in xencommons is actually /etc/rc and so $(dirname $0) is /etc. So, that's a bug in the way xencommons is trying to include xen-hotplugpath.sh. In the meantime your workaround obviously is fine.
I'm pleasantly surprised that xen 4.2 seems to work without too much fuss on netbsd even when compiled from source. Does support for file based/vnd based disk work?
Toby