DTrace scripts may reject to work when you try to run very large scripts with hundreds of enablings or thousands of actions.
Error message:
dtrace: failed to enable './myDtraceProbe.d'' : DIF program exceeds maximum program size
Reason: The current default size for DTrace is 256K. This may be to small for some probes.
Solution 1: Increase the default size in file /etc/system. You will require to have root privileges.
set dtrace:dtrace_dof_maxsize=0x800000
Reboot the system after the change.
Disclaimer: Changes to the /etc/system file change the behavior of the entire system. Consult your system administrator upfront!
Solution 2: Set the parameter dynamically with mdb (Solaris Modular Debugger)
# mdb -kw Loading modules: [ ... ] > dtrace_dof_maxsize/E dtrace_dof_maxsize: dtrace_dof_maxsize: 262144 > dtrace_dof_maxsize/Z 0t524288 dtrace_dof_maxsize: 0x40000 = 0x80000 > dtrace_dof_max_size/E dtrace_dof_maxsize: dtrace_dof_maxsize: 524288
Disclaimer: Work with mdb is the equivalent to open heart surgery on your Solaris system. Any change has direct and system wide impact. Consider to use a /etc/system entry (see solution 1) and a reboot instead of.
The new Solaris update release Solaris 10 9/10 is out. The product ships with Oracle branding and licensing and it has a new feature the "autoregistration".
I used to Virtualbox sandbox to figure out what the impact the auto registration has on a text based upgrade and and a GUI based fresh installation. Some example of the regadm command and the related service can be found at the end.
The first thing I was was a text based upgrade of an existing vanilla installation of Solaris 10 on x64. The first change it that the installer asks you to to optionally register my support information.

I have chosen this option. The next thing it wants to know is

The next steps follow as usual. The installer performs a patch analysis.

It'll be able to remove 69 patches in my case and downgrade one

The patches in question are listed below




Patch 121781 will get downgraded

Voila, my system got upgraded a good hour later.
The next thing I tried was a fresh GUI based install. The invitation to use the auto registration looks as follows:

The same information is getting gathered as before.

A summary screen shows the data gathered:

The alternative is to to register anonymously. I left all fields blank. The summary looked in this case like:

Once the system is up and running you'll find out that you got a new buddy the service autoreg will will call home to Oracle from time to time...
bash-3.00# svcs -l svc:/application/autoreg:default fmri svc:/application/autoreg:default name Solaris Auto Registration enabled true state online next_state none state_time Sat Sep 11 12:40:23 2010 logfile /var/svc/log/application-autoreg:default.log restarter svc:/system/svc/restarter:default dependency require_all/none svc:/system/filesystem/local:default (online) dependency require_all/none svc:/network/service (online) dependency require_all/none svc:/milestone/name-services (online) dependency require_all/none svc:/milestone/multi-user-server (online) dependency optional_all/none svc:/application/stosreg (online)
The registration can then be managed through the new regadm command
An anonymous registration looks as follows:
bash-3.00# regadm register Registering with My Oracle Support using usernameRegistered Solaris 10 Operating System Registered StarOffice 8 Office Suite Update 11 Registered StarOffice 8 Office Suite Update 11 Registration successful
The registration service can be enable, disabled and checked thorigh the regadm command as well.
bash-3.00# regadm status Solaris Auto-Registration is currently online bash-3.00# regadm disable bash-3.00# regadm status Solaris Auto-Registration is currently disabled bash-3.00# regadm enable bash-3.00# regadm status Solaris Auto-Registration is currently online
More information can be found in the Oracle online documentation.