Summary: | is_xenU_sys in /etc/init.d/functions.sh is broken | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Bainbridge (RETIRED) <chrb> |
Component: | [OLD] baselayout | Assignee: | Roy Marples (RETIRED) <uberlord> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cgs, erik, nao.nakashima, sascha_lucas, uberlord, via-gentoo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 96240 | ||
Bug Blocks: |
Description
Chris Bainbridge (RETIRED)
2005-10-03 04:51:19 UTC
Maybe behaviour under xen3 is different? Anyway, checking /sys/bus/xen/devices will work - there should be no backend devices in a domain0. i dont want to run `ls` so is there a file i can check for with [[ -e ]] ? try "-e /sys/bus/xen/drivers/vbd || -e /sys/bus/xen/drivers/vif". That will catch any domains with xen frontend vif or vbd devices.. it would be very difficult, if not impossible, to run a domain without either of them. hmm, well does /sys/bus/xen/devices/ always exist even if it's empty ? yes. fixed in svn then, thanks *** Bug 123258 has been marked as a duplicate of this bug. *** *** Bug 131434 has been marked as a duplicate of this bug. *** time to review again :P I was looking at another xen bug and thought I'd look at this now I have a working xen setup and this is a very bad solution as sysfs export is optional. One solution which works is that dom0 always reports control_d in /proc/xen/capabilities and domU won't - regardless of kernel options set. This works for a dom0/U combined kernel which I used for testing as well. I've comitted this fix to our svn and will be in baselayout-1.12.0_pre20 Fixed in baselayout-1.12.0 As of baselayout-1.12.14-r1, it still doesn't work right in my configuration. is_xenU_sys() { [[ ! -d /proc/xen ]] && return 1 [[ ! -r /proc/xen/capabilities ]] && return 1 grep -q "control_d" /proc/xen/capabilities && return 1 return 0 } /proc/xen/capabilities doesn't exist in my domU system (/proc/xen exists and is completely empty), so the function incorrectly returns 1. Kernel version is 2.6.34-gentoo-r12, if that matters. Configuration: % zgrep XEN /proc/config.gz CONFIG_XEN=y CONFIG_XEN_MAX_DOMAIN_MEMORY=32 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_NETXEN_NIC=m CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_XEN_KBDDEV_FRONTEND=y CONFIG_HVC_XEN=y CONFIG_XEN_FBDEV_FRONTEND=y CONFIG_XEN_BALLOON=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y P.S. Is it right to post a comment to the closed old bug, or should I have created a new one? (In reply to comment #13) > As of baselayout-1.12.14-r1, it still doesn't work right in my configuration. > /proc/xen/capabilities doesn't exist in my domU system (/proc/xen exists and is > completely empty), so the function incorrectly returns 1. you'll need to add xenfs to /etc/fstab: ---- xenfs /proc/xen xenfs defaults 0 0 ---- |