Hello Daniel,
I think you're right... follows a revised patch which does not brake the
expected behavior of the "ONBOOT" parameter. Human-friendly put:
- first use the (valid/ONBOOT) VEIDs in the BOOT_ORDER file
- then add the ONBOOT VEIDs that do not appear in the BOOT_ORDER file
I will also
** Attachment added: "Allow to specify VEs boot order in OpenVZ startup script"
http://launchpadlibrarian.net/28637786/vz.patch
--
WISH: allow to specify VEs boot order for /etc/init.d/vz
https://bugs.launchpad.net/bugs/394885
You received this bug notification because you are a member of Ubu
Public bug reported:
Binary package hint: vzctl
Hello,
When (re-)starting the host, the OpenVZ startup script (/etc/init.d/vz)
starts VEs tagged "ONBOOT" in the order corresponding to their VE
number.
In some cases, it may desirable to alter the boot order, for
dependencies reasons. An optional
This is definitely not a Kubuntu/Kwin/Composite-only bug. On Gnome (with
Composite/Compiz disabled), this bug occurs the same (unless DRI is also
disabled).
With PPA kernel 2.6.29-02062904-generic (and DRI re-enabled), this bug SEEMS
SOLVED (after 10 min. GoogleEarthing)
With Ubuntu (9.10?) kern
I confirm this bug on ATI X600 Mobility (M24 chipset).
Disabling composite (Option "Composite" "Disable") does NOT solve the problem.
Switching to XAA acceleration (Option "AccelMethod" "XAA") does NOT solve the
problem.
Disabling DRI (Option "DRI" "off") DOES (seem; no freeze in ~150 minutes) t