Robert Milkowski wrote:
Then creating a new BE just because someone installed a package could
lead to a situation when a sys admin did not fully understood he needs
to reboot just because package was installed and maybe will reboot weeks
later with outdated /etc and /var and scrapping his head of what happened.
We will try to make this very clear.
The other question is: if I install a package A which requires a reboot
so pkg will installed it to a cloned BE what will happen if I try to
install package B which also requires a reboot but I haven't rebooted
yet after installing A. Will install to the same BE which was created
for A?
Not at present; we understand that this needs some thought. One
possible mechanism is to inform the user that a new boot environment
already exists, and suggest that he install his package there.
Maybe if there is a package being installed and it requires a reboot
it should fail with an appropriate info that either extra option is
required so it installs to new BE and changes won't take effect until
one reboots to a new BE or an extra --force (or whatever) option is
required to install it anyway but an immediate reboot is highly
recommended.
To be on a safe side perhaps a clone of current BE should be created
and once package installed succesfully the new BE would be destroyed?
That way if system reboots while install was hapenning it would boot
from the old (clone) OS automatically avoiding mismatch in kernel
modules, etc...
We don't ever want to install incompatible kernel modules into a running
image; if the system gets low on memory the kernel may unload modules at
any time. This would cause the new modules to be loaded at on top of
the old kernel, with ensuing chaos.
good example. Perhaps it should be the only exception then?
Basically, a good rule of thumb is that if the modules are not
unloadable, they must be installed in an alternate boot environment.
If we need to reboot to load a update, we should install that update
in a new boot environment.
If we need to have fewer updates require a reboot, we should focus on
better ways of doing that rather than leaving it to administrative
cleverness to figure a way around the reboot.
It's almost hard not to agree to the above.
Still I'm all for all power for sysadmins with safe defaults even if it
means they will hurt themselves - and yes, they will.
Based on long and painful experience, we're really leaning towards not
aiding and abetting unsafe system management practices. Where we've
providing escape hatches "just in case", this often became standard
operating procedure. I'd rather just spend the time to solve the
underlying problem correctly and obviate the need for "special procedures".
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
