Frank Middleton wrote:
Thanks - you have confirmed the way that I thought that it works
On 10/ 8/09 02:44 PM, Shawn Walker wrote:
... this is (roughly) what happens if you have
flush-content-on-success set to True:
$ pkg image-update
* pkg creates an update plan
* pkg downloads everything needed for update
* pkg executes plan
* plan execution creates a new boot environment and mounts it
* plan execution performs the update on the new boot environment
* plan execution finishes, purging the contents of /var/pkg/download
_only_ for the new boot environment
This step isn't working, and flush-content-on-success=true is set as
confirmed by pkg property. It's almost as if "true" and "True" are
In my last recent test, it did work. Again, I wonder if I've still not
adequately explained this or there's some further confusion.
When you say it doesn't work, that mean that after rebooting the system
to the new boot environment, you checked the contents of
/var/pkg/download, and it wasn't empty?
Or did you execute "pkg image-update" and then immediately check the
contents of /var/pkg/download?
different. How could we confirm that flush-content-on-success is
observed only if the image-update succeeds in one pass, but is
ignored if (say) beadm fails because it can't find menu.lst and hence
it takes two or more passes? If this is the case, is this a candidate for
a bug report? Not sure if a) it is legitimate to file bugs against
unsupported features and b) if it is important enough, given that
beadm will soon be bug free :-).
flush-content-on-success should already account for beadm failure (note
that it doesn't actually use beadm literally, it uses libbe, the same
library that beadm uses to manage the system).
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
