Ian Murdock wrote:
Tim Foster wrote:
LiveUpgrade, and the Solaris install/upgrade tools don't yet understand
ZFS, but as was mentioned, there's a prototype to do jumpstarts with via
a tweaked pfinstall.
Is LiveUpgrade even necessary with ZFS? Or does LiveUpgrade simply
change implementation to operate on a ZFS clone rather than a copy
partition?
We can't open-source the Live Upgrade code, so the Live Upgrade
implementation you see today is not part of the plan going forward.
I can see the advantage of preserving the LiveUpgrade command set
for the people who are familiar with it. I.e., it continues to be
the way you manually manage multiple boot environments on Solaris.
Much of the command set is factored fairly poorly, I think, and based on
assumptions of UFS with slices and the existing installer, packaging,
and patching system. It seems unlikely to be a good fit since we're
probably changing every assumption it is based on. I would step back to
task analysis first and feel free to invent without compatibility as a
core constraint, and provide a transitional compatibility layer, should
it prove necessary. If the focus is really on making it easy for the
next 100 million OpenSolaris users, I'd learn from LU but not replicate it.
Then again, coming from Linux, most people are going to
expect to be able to upgrade without requiring a reboot. So, I'd
say the ideal UI here is to add an apt-get rollback (or whatever) that
goes back to the last known good state, i.e., the snapshot that
existed at the time the last apt-get install or apt-get upgrade was
run (automatically taken by install and upgrade). (Is there a zfs
diff? It would be very useful to be able to preview changes the
rollback would make before doing it. I see there's an lucompare.)
What updates in Solaris require a reboot? For updates that do require
a reboot, having the last known good state available in the grub
menu would be the way to go here. FWIW, in Linux, we got it down to just
the kernel, and even that could be done in place with patches at one
point. I.e., that's our benchmark, or at least what people will expect..
It would be desirable, but your near-term is probably going to need
reboots for most upgrades, because we haven't attempted to factor the
system to avoid them. Even where we sort of did (if you look at the
existing patching that way) it really hasn't worked out that well.
Dave
_______________________________________________
indiana-discuss mailing list
[email protected]
http://opensolaris.org/mailman/listinfo/indiana-discuss
