icon

InfoUnix

Linux · Solaris · DevOps

Solaris · Patch Rollback & Troubleshooting in Solaris 11

Solaris · Lesson 24

Patch Rollback & Troubleshooting in Solaris 11

Even with careful planning, patches can break things. This lesson shows how to handle two critical scenarios: server not booting after patching, and application issues after patching. You will learn how to rollback using Boot Environments (BEs) both when the server is up and when it is stuck during boot.

Add the YouTube embed URL for this lesson in components/solaris/solarisLessons.js.

Theory: Why Solaris patch rollback is BE-centric

In Solaris 11, patching is designed around Boot Environments (BEs). Instead of overwriting the running root filesystem, pkg update creates a new ZFS clone (new BE), patches it, and activates it for the next boot.

Atomic change

Old BE remains untouched. New BE contains patched image. Rollback just means booting previous BE.

Rollback = BE switch

You rarely downgrade packages manually. Instead you boot into the older BE where everything was OK.

Safer patching

If patch breaks boot or apps, you simply change active BE via beadm or boot menu/OBP.

Two main failure scenarios after patching

1. Server is UP but something is broken

  • OS boots successfully into new BE.
  • Applications may fail (version conflicts, configs, libs).
  • Network/storage services might misbehave.
  • You can still log in via SSH or console.

2. Server is NOT booting properly

  • Kernel panic at boot, stuck in maintenance, or failing before login prompt.
  • Use OBP (SPARC) or boot menu (x86) to select older BE.
  • After booting old BE, investigate logs and patch causes.

Practical rollback flows – commands & explanation

The following flows cover both situations: rollback when system is running, and rollback when system does not boot cleanly.

1. Scenario 1 – Server is UP but application broken

Common case: OS patched successfully, but application/library/version issues appear.

terminal — rollback
solaris-lab
[root@solaris ~]# uname -a
SunOS sol11 5.11 11.4.76.182.1 i86pc i386 i86pc
 
# Application errors in logs
[root@solaris ~]# tail -50 /var/adm/messages
...
Jan 20 23:30:01 appserver[1234]: FATAL: Library version mismatch after update
...
 
# Check current and previous boot environments
[root@solaris ~]# beadm list
BE Active Mountpoint Space Policy Created
solaris - - 13.0G static 2024-01-10 10:15
solaris-11_4_76 NR / 14.5G static 2025-01-20 23:05
 
# Decision: rollback to previous BE 'solaris'

2. Rollback when server is UP (beadm activate + reboot)

Safest rollback: switch active BE back to previous version, then reboot cleanly.

terminal — rollback
solaris-lab
[root@solaris ~]# beadm list
BE Active Mountpoint Space Policy Created
solaris - - 13.0G static 2024-01-10 10:15
solaris-11_4_76 NR / 14.5G static 2025-01-20 23:05
 
# Activate old BE
[root@solaris ~]# beadm activate solaris
 
# Output:
# Activated successfully.
# On next reboot, 'solaris' will be used as the default boot environment.
 
[root@solaris ~]# beadm list
BE Active Mountpoint Space Policy Created
solaris R - 13.0G static 2024-01-10 10:15
solaris-11_4_76 N / 14.5G static 2025-01-20 23:05
 
# R = will be used on next reboot
# N = currently running BE
 
# Reboot cleanly:
[root@solaris ~]# init 6

3. Verify rollback after reboot

Confirm you are back on old BE and validate applications.

terminal — rollback
solaris-lab
[root@solaris ~]# uname -a
SunOS sol11 5.11 11.4.41.111.0 i86pc i386 i86pc
 
[root@solaris ~]# beadm list
BE Active Mountpoint Space Policy Created
solaris NR / 13.0G static 2024-01-10 10:15
solaris-11_4_76 - - 14.5G static 2025-01-20 23:05
 
# Check app again
[root@solaris ~]# systemctl status appserver # or svcs -xv / logs as per environment

4. Scenario 2 – Server NOT booting after patch (SPARC OBP)

If OS doesn’t boot properly after patch, use OBP (OpenBoot PROM) boot menu to choose another BE.

terminal — rollback
solaris-lab
# SPARC console example:
{0} ok boot
Boot device: /pci@400/pci@0/pci@8/scsi@0/disk@0,0 File and args:
SunOS Release 5.11 Version 11.4 64-bit
...
panic[cpu0]/thread=...: fatal errors during boot
 
# Drop to OBP again:
{0} ok

5. Use boot -L from OBP to list Boot Environments (SPARC)

boot -L shows available Solaris boot environments; choose the previous known-good BE.

terminal — rollback
solaris-lab
{0} ok boot -L
 
Boot device: /pci@400/pci@0/pci@8/scsi@0/disk@0,0 File and args: -L
1 solaris-11_4_76
2 solaris
 
Select environment to boot: [ 1 - 2 ]: 2
 
# Select '2' (old BE 'solaris')
# System now boots using previous BE

6. Use devalias to inspect boot devices (SPARC)

If boot device is misconfigured, devalias helps you find correct disk alias.

terminal — rollback
solaris-lab
{0} ok devalias
disk /pci@400/pci@0/pci@8/scsi@0/disk@0,0
disk1 /pci@400/pci@0/pci@8/scsi@0/disk@1,0
net /pci@400/pci@1/network@0
 
# To temporarily boot from disk1:
{0} ok boot disk1 -L

7. x86: choose Boot Environment from boot menu

On x86, Solaris presents a boot menu with available BEs (similar to GRUB/loader).

terminal — rollback
solaris-lab
Boot Menu:
1 solaris-11_4_76
2 solaris
 
Enter choice: 2
 
# Select previous BE and boot; then use beadm from the OS to activate permanently if desired.

8. Application version conflict after patching

Typical situation: OS updated, but application not yet certified or library versions changed.

terminal — rollback
solaris-lab
# After patching:
[root@solaris ~]# pkg update --accept
...
 
# App throws version conflict
[root@solaris ~]# tail -50 /var/adm/messages
appX[2345]: ERROR: Requires libxyz.so.1.2, found 1.3
 
# Strategy:
# 1) If downtime allowed: rollback to previous BE (beadm activate old_BE).
# 2) Or spin up test system with same SRU and work with app vendor.
 
# Example rollback:
[root@solaris ~]# beadm list
BE Active Mountpoint Space Policy Created
solaris - - 13.0G static 2024-01-10 10:15
solaris-11_4_76 NR / 14.5G static 2025-01-20 23:05
 
[root@solaris ~]# beadm activate solaris
[root@solaris ~]# init 6

How to decide rollback approach

When server is UP

  • Prefer clean rollback via beadm activate old_BE + reboot.
  • Communicate downtime to stakeholders; schedule maintenance window.
  • Keep new BE for later testing (don’t delete immediately).
  • Document which SRU caused the issue and inform application team/vendor.

When server is NOT booting

  • Use SPARC OBP {0} ok boot -L to list BEs and pick previous.
  • On x86, use Solaris boot menu to select older BE.
  • Once booted into old BE, run beadm list to confirm.
  • Optionally deactivate/remove problematic BE once root cause is understood.

Safety tips for patch rollback

  • Never run pkg undo-style experiments on production unless specifically recommended by Oracle; rely on BEs instead.
  • Avoid deleting old BEs immediately after successful patch; retain at least one known-good BE for some time.
  • For mission-critical apps, coordinate with application teams and vendors before patching; confirm certified SRU levels.
  • After rollback, collect logs (/var/adm/messages, /var/log, pkg history) to understand what went wrong before attempting patch again.

Once you are comfortable with BEs, patching and rollback in Solaris 11 becomes much less scary — it's basically branch & switch rather than manual downgrade.