Summary: | patch for /etc/init.d/clock to skip hwclock in xenU | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher G. Stach II <cgs> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chrb, langthang, m.debruijne |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 70161, 107976 | ||
Attachments: |
xen-clock.patch
xen-init.d-script.patch new xen-init.d-script.patch new xen-init.d-script.patch |
Description
Christopher G. Stach II
2005-06-15 19:19:08 UTC
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 ---- |