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 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 :-).
* pkg client exits, as the operation is finished As I said, there are plans to either move /var/pkg/download somewhere else or make it part of a separate dataset, since, as you pointed out, destroying a specific dataset is faster than trying to delete 2GB of individual files.
Can't be too soon for me - even 32Gb could go awfully quickly and the delete process is pretty tedious...
Cheers,
_______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
