Solaris Express Release Notes

Solaris Express 11/06 Issues

The following issues apply to the Solaris Express 11/06 release.

Using patchadd With the -R Option To Specify an Alternative Root Path From Systems That Are Not Zones Aware Should Be Restricted (6464969)

On systems running a Solaris release that is not zones aware, using patchadd -R, or any command that accepts the -R option to specify an alternate root path for a global zone that has non-global zones installed, will not work.

In contrast with the error message that is displayed by using the luupgrade [-t, -T, -p, -P] command, no error message regarding the use of appropriate command-level restrictions is displayed in this instance.

There is no indication that the -R option did not work. As a result of the failure of the command, Solaris Express packages or patches are not installed on any of the installed non-global zones.

This problem occurs while installing and uninstalling packages or patches.


Note –

The -R option works if the alternate boot environment has configured non-global zones, but no installed non-global zones. However, to avoid a potential problem, or if you are not sure whether there are any installed non-global zones used as the alternate root path, restrict the use of the -R option in all instances.


For more information, see the following man pages :

Workaround 1: Upgrade the OS to at least the Solaris Express 12/05 release.

Workaround 2: Restrict the use of the patchadd -R command or any command that accepts the -R option to create an alternate root path.

Instead, boot the alternate root, for example, the Solaris Express release, as the active OS.

Buffer Recycling Causes Long ARC Mutex Spins (6478928)

Significant performance regressions have been seen in ZFS SpecSFS runs. These performance regression issues are caused by the ZFS cache (ARC) holding a lock for an excessive length of time while trying to recycle buffers. No error message is displayed.

Workaround: None.

Panic Caused by Bad Trap ire_round_robin() (6478246)

When multiple default routes are managed by a dynamic routing scheme, as in.routed, the system may panic with the following stack:


000002a1004063b1 ire_round_robin+0x9c(60001ac1778, 0, 2a100406d50,
deadbeefdeadbeef, 0, 60001ac1780)
000002a100406481 ire_ftable_lookup+0x2b8(819911c1, 60001bd3bf0, 0, a, 0,
2a100406f88)
000002a1004065c1 ip_newroute+0x350(302882bde48, 60002535320, 0, 0, 0,
600177fcf90)
000002a1004067a1 ip_output+0x1d84(302527cd400, 600177fcf90, 1, 301596d6c80, 0,
302527cd400)
000002a100406891 tcp_rput_data+0x39e8(40000, 2018, 2018, 70461800, 302527cd880,
5c00)
000002a100406a81 squeue_enter_chain+0x1d0(600004b1d00, 30129545580, 302527cd400
, 2561caae75d0, 1, 1)
000002a100406b31 ip_input+0xa50(60000822728, 0, 0, 8192e41f, 7bb3cc00,
30129545580)
000002a100406c41 putnext+0x3ec(60000c577e8, 60000c57540, 60000c57730,
30129545580, 2a1004074f0, 0)
 :
 :

The following error message is displayed:


BAD TRAP: type=31 rp=2a100406b10 addr=deadbeefdeadbf34 mmu_fsr=0

Workaround: In feasible environments, manage the default routes through routing schemes as /etc/defaultrouter.