thushan@zeusy:~$ pfexec pkg install virtualbox Traceback (most recent call last): File "/usr/bin/pkg", line 2598, in ? __ret = main_func() File "/usr/bin/pkg", line 2541, in main_func return install(mydir, pargs) File "/usr/bin/pkg", line 710, in install update_index=update_index) File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 203, in plan_install self.log_operation_end(error=e) File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 1410, in log_operation_end self.img.history.log_operation_end(error=error, result=result) File "/usr/lib/python2.4/vendor-packages/pkg/client/history.py", line 680, in log_operation_end self.operation_result = result File "/usr/lib/python2.4/vendor-packages/pkg/client/history.py", line 279, in __setattr__ raise AttributeError("'history' object attribute '%s' " AttributeError: 'history' object attribute 'operation_result' cannot be set before 'operation_name'. pkg: This is an internal error. Please let the developers know about this problem by filing a bug at http://defect.opensolaris.org and including the above traceback and this message. The version of pkg(5) is '87d6ba4c8e1c'.
Uh-oh, what the hell did I break now I thought? After some messing about I realised the time on the machine was a few hours behind – this was just installed on the new hardware I picked up the other day, the certificates were timestamped and I figured this was probably a clash of the space-time continuum. Instead of opting to manually set the time, I let it sync (periodically) with an NTP Server local to us here in Melbourne.
To do this, we enter our NTP server in
/etc/inet/ntp.conf like so:
Then we tell it to update itself:
thushan@zeusy:~$ pfexec ntpq -p remote refid st t when poll reach delay offset disp ============================================================================== *yarrina.connect mumnunah.csse.u 2 u 20 64 377 50.22 -11.747 0.44
Done, now you’ll find that your package manager will no longer fail with the stack-trace as the timestamps will match correctly!