How to apply patchset cluster to Solaris servers

— ny_wk

Applying a Solaris 10 patchset cluster safely means breaking the root mirror first so one disk becomes a known-good rollback, patching the remaining root disk in single-user mode with installpatchset, then re-mirroring only after the system proves stable. This guide gives the corrected, end-to-end procedure for SPARC and x86 servers running Solaris Volume Manager (SVM/SDS).

Important context: Oracle Solaris 10 reached the end of its Extended Support life in January 2024 and now sits in Sustaining Support, so new Solaris 10 patchset cluster bundles are no longer produced. The technique below is still essential for the large installed base of legacy Solaris 10 systems under support contracts. If you are building or modernizing infrastructure today, the modern equivalent is Oracle Solaris 11.4, which replaces patch clusters with pkg update and IPS boot environments (beadm) for one-command, snapshot-backed updates.

The problem: why patching Solaris 10 is risky without a mirror break

A recommended Solaris 10 patchset cluster can change hundreds of OS packages, the kernel, and core libraries in a single run. If a patch corrupts the boot archive, conflicts with an application, or the box panics mid-patch, you can be left with an unbootable production server and no fast way back.

On a system that uses a two-way SVM mirror for the root disk, you already own the perfect rollback mechanism. By splitting the mirror before patching, you keep one untouched, fully bootable copy of the old OS. If patching fails, you boot the un-patched submirror and you are running again in minutes instead of restoring from tape.

Prerequisites and pre-flight checks

Before you touch a single patch, confirm the ground truth on the server. Guessing device names is the most common cause of a botched mirror break.

Free space: the recommended patchset and its unzipped contents need a lot of room. Stage everything under /var/tmp with at least 3 GB free (check with df -h /var/tmp).
Current OS level: record it with uname -a and cat /etc/release so you can prove what changed afterward.
Mirror layout: run metastat -p and metadb -i and write down every metadevice, submirror, and state-database replica.
Physical-to-OBP mapping (SPARC): capture the device paths with ls -l /dev/dsk/c1t0d0s0 so your devalias entries are correct.
Backups and downtime: take a full backup, get a maintenance window, and stop all applications cleanly before you begin.

Throughout this guide the primary root disk is c1t0d0 and the root mirror disk is c1t1d0. Substitute your real controller/target numbers — they are almost never identical between servers.

Step-by-step: applying the Solaris 10 patchset cluster

The full workflow has four phases: download and stage, break the mirror, patch the live root disk, then re-mirror. Follow them in order.

Phase 1 — Download and stage the patchset

Download the platform-appropriate Recommended OS Patchset for Solaris 10 (SPARC or x86) from Oracle Support (support.oracle.com) using an account with a valid support contract.
Transfer the ZIP to the target server's /var/tmp (for example via scp), then verify the download size and checksum match Oracle's listing.
Stop all applications and databases gracefully so no I/O is in flight when you split the mirror.

Phase 2 — Break the root mirror (create the rollback disk)

The goal here is to detach the mirror disk (c1t1d0) cleanly so it becomes a standalone, bootable copy of the current OS, while the system keeps running on the primary disk (c1t0d0).

Inspect the current mirrors. A typical two-way root mirror looks like this:
metastat -p
d0 -m d10 d11 1
d10 1 1 c1t0d0s0
d11 1 1 c1t1d0s0
d1 -m d20 d21 1
d20 1 1 c1t0d0s1
d21 1 1 c1t1d0s1
Here d0 is the root (/) mirror and d1 is the swap mirror. The d1x submirrors live on the primary disk; the d2x submirrors live on the mirror disk.
Detach the mirror-disk submirrors from each mirror:
metadetach d0 d11
metadetach d1 d21
Clear the detached submirrors so SVM no longer tracks them:
metaclear d11
metaclear d21
Delete the state-database replicas that live on the mirror disk's dedicated slice (commonly s7), so the freed disk owns no SVM metadata:
metadb -d -f /dev/dsk/c1t1d0s7
Confirm with metadb -i that replicas remain only on the primary disk. (If too few replicas survive — fewer than three — add more on the primary disk before continuing, because SVM will not boot with insufficient replicas.)
Verify the result. metastat -p should now show each mirror with a single remaining submirror on the primary disk:
d0 -m d10 1
d10 1 1 c1t0d0s0
d1 -m d20 1
d20 1 1 c1t0d0s1

Phase 3 — Make the detached disk independently bootable

The detached disk still has SVM metadevice references in its boot files. You must rewrite them to plain physical-device entries so it can boot on its own if you ever need the rollback.

Mount the detached root slice on a temporary mount point:
mount /dev/dsk/c1t1d0s0 /mnt
Edit the vfstab on the mounted disk and change the metadevice entries to the physical slices of that same disk:
vi /mnt/etc/vfstab
Change /dev/md/dsk/d0 → /dev/dsk/c1t1d0s0 (and its /dev/md/rdsk/d0 raw entry to /dev/rdsk/c1t1d0s0), and /dev/md/dsk/d1 → /dev/dsk/c1t1d0s1 for swap. Point every metadevice line at the mirror disk's physical slices, not the primary disk's.
Disable the SVM root reference in the system file. Find the line with:
grep -i md /mnt/etc/system
and comment out the rootdev entry by prefixing it with an asterisk:
* rootdev:/pseudo/md@0:0,0,blk
Leave the surrounding * Begin MDD root info / * End MDD root info markers intact.
Unmount and file-system check the detached disk:
umount /mnt
fsck /dev/rdsk/c1t1d0s0

Phase 4 — Verify both disks boot, then patch

Prove you actually have a working rollback before you patch. On SPARC, drop to the OpenBoot PROM (ok) prompt and test each disk.

Bring the system down to OBP: init 0
Boot the detached mirror disk using its physical OBP path (use the real path from your pre-flight mapping):
ok> boot /pci@1f,0/pci@1/scsi@8/disk@1,0:a
When it comes up, sanity-check with df -h, ifconfig -a, and your application status. Tip: boot by the explicit device path rather than a stale rootmirror alias — an out-of-date alias can point at the wrong slice and fail.
Boot the primary root disk and confirm it is healthy too — this is the disk you will patch:
ok> boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a
Go to single-user mode so no services interfere with patching:
shutdown -g0 -y -i S
Confirm the run level:
who -r → run-level S
Unzip and run the patchset installer from /var/tmp:
cd /var/tmp
unzip -q 10_Recommended.zip
cd 10_Recommended
./installpatchset --s10patchset
The installer prints its banner (for example Recommended OS Patchset Solaris 10 x86) and logs progress to /var/sadm/install_data/. Let it finish without interruption.
Reboot with a device reconfigure so the kernel and boot archive rebuild cleanly:
reboot -- -r

Verification: confirm the patchset applied correctly

After the reboot, prove the patches landed and the system is healthy before you tell anyone it is done.

Kernel revision: uname -a should report the new kernel patch level (for example a higher Generic_NNNNNN-NN string than you recorded earlier).
Patch log review: read the installer summary under /var/sadm/install_data/s10*_installpatchset*log* for any failed or skipped patches.
Installed patches: showrev -p | wc -l and spot-check key patch IDs with showrev -p | grep <patch-id>.
Services and apps: svcs -xv should show no services in maintenance; then restart and validate your applications.
Storage health: metastat and metadb -i should show the surviving (primary) mirror clean, with no errored replicas.

Re-mirror the root disk after a stable burn-in

Do not rush to re-attach the mirror. Run the patched system for two to three weeks so any latent application or kernel issue surfaces while you still hold an untouched rollback disk. Once you are confident, rebuild the two-way mirror so the patched OS is copied onto the formerly-detached disk.

Recreate the state-database replicas on the mirror disk's metadb slice:
metadb -a -c 3 /dev/dsk/c1t1d0s7
(-c 3 adds three replicas on that slice; size them to match your existing replicas.)
Recreate the submirrors on the mirror disk:
metainit d11 1 1 c1t1d0s0
metainit d21 1 1 c1t1d0s1
Attach them back to the mirrors to start the resync:
metattach d0 d11
metattach d1 d21
Watch the resync until it reaches 100%:
metastat | grep -i resync
Install the boot block on the re-mirrored disk so it stays bootable (SPARC example):
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t1d0s0
On x86 the equivalent is installgrub.
Clean up the staging area only after a successful re-mirror: delete the ZIP and unpacked patchset from /var/tmp.

Common pitfalls when applying a Solaris 10 patchset cluster

Most failed patch jobs come from a handful of avoidable mistakes. Watch for these:

Mixing up controller/target numbers. The source-of-truth disks are c1t0d0 (root) and c1t1d0 (mirror). Detaching or clearing the wrong disk can wipe your only good copy — always confirm with metastat -p first.
Too few state-database replicas. SVM needs a quorum of replicas to boot. After deleting the mirror-disk replicas, verify at least three remain on the primary disk or the box may refuse to boot.
Forgetting to edit /etc/system on the detached disk. If the rootdev metadevice line is left active, the rollback disk tries to boot off a metadevice that no longer exists and fails.
Patching in multi-user mode. Always patch in single-user (init S) so running services don't hold files open or change state mid-patch.
Insufficient space in /var/tmp. A half-unzipped patchset or a full filesystem aborts installpatchset; keep 3 GB+ free.
Re-mirroring too soon. Attaching the mirror the same day destroys your rollback before you know the OS is stable. Wait out the burn-in window.
Booting by a stale OBP alias. Update or bypass devalias entries; boot by explicit device path during verification.

Modern equivalent: Solaris 11 IPS and boot environments

If you are on Oracle Solaris 11, you no longer break mirrors by hand. The Image Packaging System creates an automatic boot environment (a ZFS snapshot/clone) before it updates, giving you the same rollback safety with far less risk:

pkg update — updates packages into a new boot environment automatically.
beadm list — shows boot environments; the new one is activated on next reboot.
beadm activate <old-be> then reboot — instant rollback if the update misbehaves.

The Solaris 10 mirror-break method is effectively the manual, UFS/SVM-era version of what ZFS boot environments now do for free.

Key Takeaways

Break the root mirror before patching so one untouched, bootable disk is your guaranteed rollback.
Patch in single-user mode with ./installpatchset --s10patchset, then reboot with reboot -- -r.
Verify both disks boot by explicit OBP device path before patching, never by a possibly-stale alias.
Re-mirror only after a 2–3 week stable burn-in using metainit + metattach, then reinstall the boot block.
Solaris 10 is in sustaining support — for new systems, Solaris 11's pkg update + boot environments deliver the same rollback safety automatically.

Frequently Asked Questions

How much free space do I need to install a Solaris 10 patchset cluster?

Stage the patchset under /var/tmp with at least 3 GB free to hold both the ZIP and the unpacked contents. Check with df -h /var/tmp and clean up old files first if you are tight on space.

Do I have to break the root mirror to apply patches?

It is not strictly required, but it is the safest practice on SVM-mirrored Solaris 10 systems. Breaking the mirror gives you a known-good, bootable copy of the pre-patch OS, so a failed patch becomes a five-minute boot instead of a multi-hour restore.

How do I roll back if a Solaris 10 patch fails?

If you split the mirror first, bring the box to the ok prompt and boot the detached disk by its physical device path. The system comes up on the un-patched OS. You can also remove individual patches with patchrm <patch-id>, but a clean mirror-disk boot is faster and more reliable.

What replaces patch clusters in Oracle Solaris 11?

Solaris 11 uses the Image Packaging System: run pkg update and it builds a new ZFS boot environment automatically. Manage and roll back with beadm list and beadm activate — no manual mirror breaking required.

For more hands-on Solaris and system-administration walkthroughs, subscribe on YouTube @explorenystream.