Xen unprivileged domains don't have access to the hardware clock, similar to UML.
Created attachment 61310 [details, diff] xen-clock.patch This patch fixes it, and brings up a possible scripting error (see the added comment.)
the stop() is a typo but the fix is to check $fakeit added to cvs
the is_xen_U function in function.sh doesn't work with xen-3. both unprivileged domains and privileged domain have /proc/xen/privcmd xenU ~ # ls -l /proc/xen/privcmd -r-------- 1 root root 0 Dec 22 23:56 /proc/xen/privcmd xen0 ~ # ls -l /proc/xen/privcmd -r-------- 1 root root 0 Dec 22 09:55 /proc/xen/privcmd my hack was to check for xencons binary (assumed one doesn't install xen inside unprivileged domains) - [[ -d /proc/xen && ! -f /proc/xen/privcmd ]] + [[ -d /proc/xen/net && ! $(type -t xencons) ]] there are similar problem with keymaps and consolefont too # /etc/init.d/keymaps restart * Caching service dependencies ... [ ok ] * WARNING: you are stopping a boot service. * WARNING: you are stopping a boot service. Couldnt get a file descriptor referring to the console * Loading key mappings ...Couldnt get a file descriptor referring to the console * Error loading key mappings [ !! ] Couldnt get a file descriptor referring to the console Couldnt get a file descriptor referring to the console * Setting terminal encoding to UTF-8 ... [ ok ] * Setting user font ...Couldnt open //dev/tty1 Couldnt open //dev/tty2 Couldnt open //dev/tty3 Couldnt open //dev/tty4 Couldnt open //dev/tty5 Couldnt open //dev/tty6 Couldnt open //dev/tty7 Couldnt open //dev/tty8 Couldnt open //dev/tty9 Couldnt open //dev/tty10 Couldnt open //dev/tty11 * Failed to set user font [ !! ] change it to - if is_uml_sys || is_xenU_sys ; then + if is_uml_sys ; then would fix it.
your diffs looked reverse post complete diffs against init.d files if this xen stuff gets anymore complex, i'm inclined to just cut it completely
Created attachment 75366 [details, diff] xen-init.d-script.patch yes, I did have the diff backward. Thanks.
seems pretty weak to rely on the existence of the xencons binary
There's no direct way to tell dom0 and domU apart. You can check for the presence of front end or backend drivers in /sys as I mentioned in #107976. xen support in baselayout is no more complex than uml, you need to do exactly the same init for uml binaries and xen domU domains.
Created attachment 75465 [details, diff] new xen-init.d-script.patch change test to [[ -d /sys/bus/xen/drivers/vbd ]] . I agree that it is hard to get domainU running without a vdb device.
i meant the detection detecting UML is dirt simple and fool proof detecting xen is prone to bugs and not perfect as you've shown
why dont you two agree on a is_xenU_sys() func and i'll commit it it should only use bash builtins
What about the check for vbd or vif? The problem with vbd only is that the user might be netbooting with pxe and nfsroot as explained on the wiki.
Created attachment 75475 [details, diff] new xen-init.d-script.patch change detection check to: [[ -d /sys/bus/xen/drivers/vbd || -d /sys/bus/xen/drivers/vif ]] Thanks
fixed in svn then, thanks
This does not work with gentoo-sources-2.6.30-r5 (pv-ops) as /proc/xen is an empty directory.
(In reply to comment #14) > This does not work with gentoo-sources-2.6.30-r5 (pv-ops) as /proc/xen is an > empty directory. > you'll need to add xenfs to /etc/fstab: ---- xenfs /proc/xen xenfs defaults 0 0 ----