blog'o thnet

To content | To menu | To search

Tag - Patch

Entries feed - Comments feed

Wednesday 18 July 2012

Update the HBA firmware on Oracle-branded HBAs

Updating the emlxs driver will no longer automatically update the HBA firmware on Oracle-branded HBAs. If an HBA firmware update is required on an Oracle-branded HBA, a WARNING message will be placed in the /var/adm/messages file, such as this one:

# grep emlx /var/adm/messages
[...]
Jul 18 02:37:11 beastie emlxs: [ID 349649 kern.info] [ 1.0340]emlxs0:WARNING:1540: Firmware update required. (A manual HBA reset or link reset (using luxadm or fcadm) is required.)
Jul 18 02:37:15 beastie emlxs: [ID 349649 kern.info] [ 1.0340]emlxs1:WARNING:1540: Firmware update required. (A manual HBA reset or link reset (using luxadm or fcadm) is required.)
[...]

If found, this message is stating that the emlxs driver has determined that the firmware kernel component needs to be updated. To perform this update, execute luxadm -e forcelip on Solaris 10 (or a fcadm force-lip on Solaris 11) against each emlxs instance that reports the message. As stated in the documentation:

This procedure, while disruptive, will ensure that both driver and firmware are current. The force lip will temporarily disrupt I/O on the port. The disruption and firmware upgrade takes approximately 30-60 seconds to complete as seen from the example messages below. The example shows an update is needed for emlxs instance 0 (emlxs0) and emlxs instance 1 (emlxs1), which happens to correlate to the c1 and c2 controllers in this case.

# fcinfo hba-port
HBA Port WWN: 10000000c9e43860
        OS Device Name: /dev/cfg/c1
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.00a12 (U3D1.00A12)
        FCode/BIOS Version: Boot:5.03a0 Fcode:3.01a1
        Serial Number: 0999BT0-1136000725
        Driver Name: emlxs
        Driver Version: 2.60k (2011.03.24.16.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 8Gb
        Node WWN: 20000000c9e43860
HBA Port WWN: 10000000c9e435fe
        OS Device Name: /dev/cfg/c2
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.00a12 (U3D1.00A12)
        FCode/BIOS Version: Boot:5.03a0 Fcode:3.01a1
        Serial Number: 0999BT0-1136000724
        Driver Name: emlxs
        Driver Version: 2.60k (2011.03.24.16.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 8Gb
        Node WWN: 20000000c9e435fe

In order not to interrupt the service, and because MPxIO (native multipathing I/O) is in use, each emlxs instance will be update one after each other.

# date
Wed Jul 18 09:34:11 CEST 2012

# luxadm -e forcelip /dev/cfg/c1

# grep emlx /var/adm/messages
[...]
Jul 18 09:35:48 beastie emlxs: [ID 349649 kern.info] [ 5.0334]emlxs0: NOTICE: 710: Link down.
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [13.02C0]emlxs0: NOTICE: 200: Adapter initialization. (Firmware update needed. Updating. id=67 fw=6)
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [ 3.0ECB]emlxs0: NOTICE:1520: Firmware download. (AWC file: KERN: old=1.00a11  new=1.10a8  Update.)
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [ 3.0EEB]emlxs0: NOTICE:1520: Firmware download. (DWC file: TEST:             new=1.00a4  Update.)
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [ 3.0EFF]emlxs0: NOTICE:1520: Firmware download. (DWC file: STUB: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [ 3.0F1D]emlxs0: NOTICE:1520: Firmware download. (DWC file: SLI2: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:35:53 beastie emlxs: [ID 349649 kern.info] [ 3.0F2C]emlxs0: NOTICE:1520: Firmware download. (DWC file: SLI3: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:36:01 beastie emlxs: [ID 349649 kern.info] [ 3.0143]emlxs0: NOTICE:1521: Firmware download complete. (Status good.)
Jul 18 09:36:06 beastie emlxs: [ID 349649 kern.info] [ 5.055E]emlxs0: NOTICE: 720: Link up. (8Gb, fabric, initiator)

# date
Wed Jul 18 09:39:51 CEST 2012

# luxadm -e forcelip /dev/cfg/c2

# grep emlx /var/adm/messages
[...]
Jul 18 09:41:35 beastie emlxs: [ID 349649 kern.info] [ 5.0334]emlxs1: NOTICE: 710: Link down.
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [13.02C0]emlxs1: NOTICE: 200: Adapter initialization. (Firmware update needed. Updating. id=67 fw=6)
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [ 3.0ECB]emlxs1: NOTICE:1520: Firmware download. (AWC file: KERN: old=1.00a11  new=1.10a8  Update.)
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [ 3.0EEB]emlxs1: NOTICE:1520: Firmware download. (DWC file: TEST:             new=1.00a4  Update.)
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [ 3.0EFF]emlxs1: NOTICE:1520: Firmware download. (DWC file: STUB: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [ 3.0F1D]emlxs1: NOTICE:1520: Firmware download. (DWC file: SLI2: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:41:40 beastie emlxs: [ID 349649 kern.info] [ 3.0F2C]emlxs1: NOTICE:1520: Firmware download. (DWC file: SLI3: old=1.00a12  new=2.00a3  Update.)
Jul 18 09:41:48 beastie emlxs: [ID 349649 kern.info] [ 3.0143]emlxs1: NOTICE:1521: Firmware download complete. (Status good.)
Jul 18 09:41:53 beastie emlxs: [ID 349649 kern.info] [ 5.055E]emlxs1: NOTICE: 720: Link up. (8Gb, fabric, initiator)

That's it. Lastly, the documentation says:

At this point, the firmware upgrade is complete as indicated by the Status good message above. A reboot is not strictly necessary to begin using the new firmware. But the fcinfo hba-port command may still report the old firmware version. This is only a reporting defect that does not affect firmware operation and will be corrected in a later version of fcinfo. To correct the version shown by fcinfo, a second reboot is necessary. On systems capable of DR, you can perform dynamic reconfiguration on the HBA (via cfgadm unconfigure/configure) instead of rebooting.

For my part, I tried to unconfigure/configure each emlxs instance using cfgadm without a reboot, but this didn't work as expected on Solaris 10. The fcinfo utility still report the old firmware version, seems until the next reboot.

Sunday 13 March 2011

Customized Solaris installation and patching experience

I recently faced a curious problem when trying to patch an Alternate Boot Environment created with Live Upgrade on Solaris 10. Although I initially though it was a LU problem, the solution is finally related to the patches to be applied and the way a Solaris is installed.

Assuming the ABE is named s10u9, I first tried to apply the Critical Patch Updates the new way, i.e. through a switch to the installcluster script , which quickly failed like this:

# cd /net/jumpstart/export/media/patch/cpu/10_Recommended_CPU_2010-10
# ./installcluster --apply-prereq --s10cluster
[...]
# ./installcluster -B s10u9 --s10cluster
ERROR: Patch set cannot be installed from a live boot environment without zones
       support, to a target boot environment that has zones support.

So, I tried to apply the patches using the luupgrade command, but it failed with a very similar message:

# ptime luupgrade -t -n s10u9 -s /net/jumpstart/export/media/patch/cpu/10_Recommended_CPU_2010-10/patches `cat patch_order`
Validating the contents of the media .
The media contains 198 software patches that can be added.
All 198 patches will be added because you did not specify any specific patches to add.
Mounting the BE .
ERROR: The boot environment  supports non-global zones. The current boot
environment does not support non-global zones. Releases prior to Solaris 10 cannot be
used to maintain Solaris 10 and later releases that include support for non-global zones.
You may only execute the specified operation on a system with Solaris 10 (or later)
installed.

The fact is, the Primary Boot Environment is a Solaris 10 installation. So, why complaining that the PBE is an older release? Looking on OTN discussion forums and in the README file which came with the Critical Patch Updates release, there is a known bug which can end this way. This will occur when /etc/zones/index in the inactive boot environment has an incorrect setting for the state for the global zone. The correct setting is installed. So, get check this one:

# lumount -n s10u9
/.alt.s10u9
# grep "^global:configured:" /.alt.s10u9/etc/zones/index
# luumount -n s10u9

So no luck here. But wait: if the PBE is a customized Solaris 10 installation, it may be that the installed packages missed the Zone feature, which seems to be mandatory by installcluster or liveupgrade -t to figure out if the PBE is a proper (usable) Solaris 10 installation. So, I just installed the missing packages from the install media...

# mount -r -F hsfs `lofiadm -a /net/jumpstart/export/media/iso/sol-10-u9-ga-sparc-dvd.iso` /mnt
# pkginfo -d /mnt/Solaris_10/Product | nawk '$2 ~ /zone/ || $2 ~ /pool$/ {print $0}'
application SUNWluzone                       Live Upgrade (zones support)
system      SUNWpool                         Resource Pools
system      SUNWzoner                        Solaris Zones (Root)
system      SUNWzoneu                        Solaris Zones (Usr)
# yes | pkgadd -d /mnt/Solaris_10/Product SUNWluzone SUNWzoner SUNWzoneu SUNWpool
[...]
# umount /mnt
# lofiadm -d /dev/lofi/1

... and this must be OK right now:

# ./installcluster -B s10u9 --s10cluster
Setup ...
CPU OS Cluster 2010/10 Solaris 10 SPARC (2010.10.06)
Application of patches started : 2011.02.07 11:17:08

Applying 120900-04 (  1 of 198) ... skipped
[...]
Installation of patch set to alternate boot environment complete.

Please remember to activate boot environment s10u9 with luactivate(1M)
before rebooting.
Install log files written :
  /.alt.s10u9/var/sadm/install_data/s10s_rec_cluster_short_2011.02.07_11.17.08.log
  /.alt.s10u9/var/sadm/install_data/s10s_rec_cluster_verbose_2011.02.07_11.17.08.log

And it is... The question is, why is the Zone feature necessary and mandatory in this case?

Tuesday 16 October 2007

Error While Patching A New Boot Environment

After creating a new boot environment (BE) named beastie, see below, to upgrade a system running Solaris 8 to Solaris 10 11/06 (as I do many times in the past without a hiccup), I encounter a problem when I tried to apply the appropriate Recommended cluster patch to the new BE with this message:

# luupgrade -t -n beastie -s /var/tmp/10_Recommended

Validating the contents of the media .
The media contains 76 software patches that can be added.
All 76 patches will be added because you did not specify any specific
patches to add.
Mounting the BE .
ERROR: The boot environment  supports non-global
zones.The current boot environment does not support non-global zones.
Releases prior to Solaris 10 cannot be used to maintain Solaris 10 and
later releases that include support for non-global zones. You may only
execute the specified operation on a system with Solaris 10 (or later)
installed.

I can't find any reference to a known bug or problem after looking for this against SunSolve, Sun Support, and Googling. Has anyone already seen this error, and solved it The Right Way? As for me, I needed to boot from the BE and apply the cluster patch: this was a pain since this bundle include the -36 kernel patch which is known to be relatively disruptive, since it need two reboot to apply the entire cluster patch (it contains a new version for the kernel).

Update #1 (2009-03-22): Seems to be explained in this excellent BigAdmin article.

Thursday 22 March 2007

Patching an x86 Miniroot Image for the Solaris OS

Generally speaking, BigAdmin is a great and valuable source for Sun's systems administrators. Here is an awesome article describing how to patch (update) the kernel used during an installation or system upgrade process, known as miniroot, for x86 based Solaris platform.

At work, we precisely encounter a bug between Solaris 6/06 and the provided nVidia driver which prevents jumpstarting it on a Sun Fire X4100 M2 Server. The support team said we can apply specific patches, already present in Solaris 11/06 at that time. Because we don't really known the exact procedure to follow to update the miniroot accordingly, and because these machines must be provisioned very quickly, we doesn't investigate much on that way (ending installing them with DVD-ROMs, in servers room). Now, after reading the proposed article, we will certainly take the time to do so... if we know how to get the proper bundle of patches to correct our bug.

Thursday 1 February 2007

Patching a Solaris 10 Single-System

In order to be able to access Software Updates via the official Sun server, you need to register your system using a valid account. You can use the sconadm command to do so. Note that this one is the command line version of the /usr/bin/updatemanager program.

First, prepare a registration profile, enabling authenticated web proxy support:

# cat /tmp/registrationprofile.properties
userName=aaaaaaaa
password=bbbbbbbb
hostName=cccccccc
subscriptionKey=
portalEnabled=false
proxyHostName=dd.ee.ff.gg
proxyPort=hhhh
proxyUserName=iiiiiiii
proxyPassword=jjjjjjjj

Then, be sure to have correct permissions and mode on the profile (especially since passwords are stored in clear text). Last register the system:

# chown root:root /tmp/registrationprofile.properties && \
  chmod 400 /tmp/registrationprofile.properties
#
# sconadm register -a -r /tmp/registrationprofile.properties
sconadm is running
Authenticating user ...
finish registration!
#
# rm /tmp/registrationprofile.properties

You can now configure the sconadm CLI utility to use the authenticated web proxy configuration permanently, as follow:

# smpatch get
patchpro.backout.directory      -       ""
patchpro.baseline.directory     -       /var/sadm/spool
patchpro.download.directory     -       /var/sadm/spool
patchpro.install.types          -       rebootafter:reconfigafter:standard
patchpro.patch.source           -       https://getupdates1.sun.com/
patchpro.patchset               -       current
patchpro.proxy.host             -       ""
patchpro.proxy.passwd           ****    ****
patchpro.proxy.port             -       8080
patchpro.proxy.user             -       ""
#
# smpatch set patchpro.proxy.host=dd.ee.ff.gg
# smpatch set patchpro.proxy.port=hhhh
# smpatch set patchpro.proxy.user=iiiiiiii
# smpatch set patchpro.proxy.passwd=jjjjjjjj
#
# smpatch get
patchpro.backout.directory      -               ""
patchpro.baseline.directory     -               /var/sadm/spool
patchpro.download.directory     -               /var/sadm/spool
patchpro.install.types          -               rebootafter:reconfigafter:standard
patchpro.patch.source           -               https://getupdates1.sun.com/
patchpro.patchset               -               current
patchpro.proxy.host             dd.ee.ff.gg     ""
patchpro.proxy.passwd           ****            ****
patchpro.proxy.port             hhhh            8080
patchpro.proxy.user             iiiiiiii        ""

So you can now easily analyze your system and see what patches are published online and ready to be applied:

# smpatch analyze
[...]
118855-36 SunOS 5.10_x86: kernel patch
119999-02 SunOS 5.10_x86: arp, ip, ipsecah drivers patch
124923-02 SunOS 5.10_x86: ld.so.1 patch
122033-03 SunOS 5.10_x86: Update timezones patch
125012-01 SunOS 5.10_x86: sendmail patch

At this time, you can choose to download and apply them all. I some updates required a (clean) reboot to be effective, smpatch will tell you how to do properly:

# smpatch update
Update 122033-03 will not be downloaded since it already exists in the download
 directory.
Update 124207-02 will not be downloaded since it already exists in the download
 directory.
118844-30 has been validated.
118855-36 has been validated.
119999-02 has been validated.
124923-02 has been validated.
125012-01 has been validated.
Installing patches from /var/sadm/spool...
NOTICE: Update 118844-30 cannot be applied at this time since it is typed as
 "single user, reconfig immediate" which is disallowed by installation policy.
NOTICE: Patch 118844-30 cannot be installed until the next system shutdown.
NOTICE: Update 122033-03 cannot be applied at this time since it is typed as
 "single user" which is disallowed by installation policy.
NOTICE: Patch 122033-03 cannot be installed until the next system shutdown.
NOTICE: Update 124207-02 cannot be applied at this time since it is typed as
 "single user, reconfig immediate" which is disallowed by installation policy.
NOTICE: Patch 124207-02 cannot be installed until the next system shutdown.
/var/sadm/spool/patchpro_dnld_2007.01.31@13:10:10:CET.txt has been moved to
/var/sadm/spool/patchproSequester/patchpro_dnld_2007.01.31@13:10:10:CET.txt

ID's of the updates that are disallowed by installation policy have been
written to file
        /var/sadm/spool/disallowed_patch_list

One or more updates that you installed requires a system shutdown to activate
 it. To initiate the system shutdown, you must use one of the following
 commands:
o Drop to the firmware prompt - init 0 or shutdown -i 0
o Power down the system - init 5 or shutdown -i 5
o Restart the system - init 6 or shutdown -i 6

The bad thing is that this tool doesn't always as expected... particularly on older releases. Please refer to Matty's entries on this subject for more information.

Thursday 6 July 2006

FreeBSD Port Patch Preview for the Last NanoBlogger's 3.3 RC5

Here is the preview patch for the www/nanoblogger port.

You can apply and install it using the following steps:

# cd /usr/ports/www/nanoblogger && make deinstall
# cd /usr/ports && patch < /tmp/nanoblogger.3.3-rc5.patch
# cd /usr/ports/www/nanoblogger && make install clean clean-depends

Be aware that there are a lot of changes in NanoBlogger itself, so read carefully the NanoBlogger User Manual online documentation and the pkg-message post installation output. After the installation, you can (re)read it using:

# pkg_info -D /var/db/pkg/nanoblogger

Download: nanoblogger.3.3-rc5.patch

Sunday 21 May 2006

Upgrading from snv_38 to snv_39 Using Solaris Live Upgrade

After writing about how to patch (or upgrade) a running system playing with a mirrored OpenSolaris SVM, here is a little step-by-step how to on upgrading (or patching, etc.) a live system using the Live Upgrade feature.

Before installing or running Live Upgrade, you are required to install a limited set of patch revisions. Make sure you have the most recently updated patch list by consulting sunsolve.sun.com. Search for the info doc 72099 on the SunSolve web site (you must have a registered Sun support customer account to be able to view this document).

Note: In the following procedure, we will assume that all we want (and need) to upgrade to is provided via a one large DVD ISO image.

If all seems OK, you must begin to update the current running system with the appropriate lu packages, i.e. those provided for the targeted OS revision. You can either use the provided tools:

# /cdrom/cdrom0/Solaris_11/Tools/Installers/liveupgrade20

Or do it yourself:

# pkgrm SUNWluu SUNWlur
# pkgadd -d /cdrom/cdrom0/Solaris_11/Product SUNWlur SUNWluu

Since the current OS is totally installed on the first slice of the first disk (c1d0s0), and that the slice six (c1d0s6) is exactly the same size as the first one, we will use it for the second ABE device for our purpose and create the corresponding Boot Environment.

# lucreate -c snv_38 -n snv_39 -m /:/dev/dsk/c1d0s6:ufs
/* If the snv_38 BE already exists, just create the new one for snv_39. */
# lucreate -n snv_39 -m /:/dev/dsk/c1d0s6:ufs
Discovering physical storage devices
Discovering logical storage devices
Cross referencing storage devices with boot environment configurations
Determining types of file systems supported
Validating file system requests
Preparing logical storage devices
Preparing physical storage devices
Configuring physical storage devices
Configuring logical storage devices
Analyzing system configuration.
Comparing source boot environment <snv_38> file systems with the file
system(s) you specified for the new boot environment. Determining which
file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Searching /dev for possible boot environment filesystem devices

Updating system configuration files.
The device </dev/dsk/c1d0s6> is not a root device for any boot environment.
Creating configuration for boot environment <snv_39>.
Source boot environment is <snv_38>.
Creating boot environment <snv_39>.
Checking for GRUB menu on boot environment <snv_39>.
The boot environment <snv_39> does not contain the GRUB menu.
Creating file systems on boot environment <snv_39>.
Creating <ufs> file system for </> on </dev/dsk/c1d0s6>.
Mounting file systems for boot environment <snv_39>.
Calculating required sizes of file systems for boot environment <snv_39>.
Populating file systems on boot environment <snv_39>.
Checking selection integrity.
Integrity check OK.
Populating contents of mount point </>.
Copying.
Creating shared file system mount points.
Creating compare databases for boot environment <snv_39>.
Creating compare database for file system </>.
Updating compare databases on boot environment <snv_39>.
Making boot environment <snv_39> bootable.
Updating bootenv.rc on ABE <snv_39>.
Population of boot environment <snv_39> successful.
Creation of boot environment <snv_39> successful.

Verify the correct attribution of the different file systems, in particular between those which are cloned (required by a Solaris installation, such as /, /var, /usr, and /opt) and those which are shared (such as /export).

# lufslist -n snv_38
               boot environment name: snv_38
               This boot environment is currently active.
               This boot environment will be active on next system boot.

Filesystem           fstype    device size Mounted on     Mount Options
-------------------- -------- ------------ -------------- --------------
/dev/dsk/c1d0s1      swap       4301821440 -              -
/dev/dsk/c1d0s0      ufs        8595417600 /              -
/dev/dsk/c1d0s7      ufs       58407713280 /export        -
#
# lufslist -n snv_39
               boot environment name: snv_39

Filesystem           fstype    device size Mounted on     Mount Options
-------------------- -------- ------------ -------------- --------------
/dev/dsk/c1d0s1      swap       4301821440 -              -
/dev/dsk/c1d0s6      ufs        8595417600 /              -
/dev/dsk/c1d0s7      ufs       58407713280 /export        -

You then just need to upgrade the second BE using the installation media of the desired release or revision.

# luupgrade -u -n snv_39 -s /cdrom/cdrom0

Install media is CD/DVD. </cdrom/cdrom0>.
Waiting for CD/DVD media </cdrom/cdrom0> ...
Copying failsafe multiboot from media.
Uncompressing miniroot
Creating miniroot device
miniroot filesystem is <ufs>
Mounting miniroot at </cdrom/cdrom0/Solaris_11/Tools/Boot>
Validating the contents of the media </cdrom/cdrom0>.
The media is a standard Solaris media.
The media contains an operating system upgrade image.
The media contains <Solaris> version <11>.
Constructing upgrade profile to use.
Locating the operating system upgrade program.
Checking for existence of previously scheduled Live Upgrade requests.
Creating upgrade profile for BE <snv_39>.
Checking for GRUB menu on ABE <snv_39>.
Checking for x86 boot partition on ABE.
Determining packages to install or upgrade for BE <snv_39>.
Performing the operating system upgrade of the BE <snv_39>.
CAUTION: Interrupting this process may leave the boot environment unstable
or unbootable.
Upgrading Solaris: 100% completed
Installation of the packages from this media is complete.
Deleted empty GRUB menu on ABE <snv_39>.
Adding operating system patches to the BE <snv_39>.
The operating system patch installation is complete.
ABE boot partition backing deleted.
Configuring failsafe for system.
Failsafe configuration is complete.
INFORMATION: The file </var/sadm/system/logs/upgrade_log> on boot
environment <snv_39> contains a log of the upgrade operation.
INFORMATION: The file </var/sadm/system/data/upgrade_cleanup> on boot
environment <snv_39> contains a log of cleanup operations required.
INFORMATION: Review the files listed above. Remember that all of the files
are located on boot environment <snv_39>. Before you activate boot
environment <snv_39>, determine if any additional system maintenance is
required or if additional media of the software distribution must be
installed.
The Solaris upgrade of the boot environment <snv_39> is complete.
Installing failsafe
Failsafe install is complete.

If something went wrong during the upgrade of the new Boot Environment snv_39, you can always restart with a very fresh one using the lumake -n snv_39 command. If all went smooth, you can now check and compare the newly created BE:

# lucompare -t snv_39 -o /tmp/lucompare.snv_39
# lumount -n snv_39
/.alt.snv_39
# mount -p | grep snv_39
/dev/dsk/c1d0s6 - /.alt.snv_39 ufs - no rw,intr,largefiles,logging,xattr,onerror=panic
# luumount -n snv_39
#
# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
snv_38                     yes      yes    yes       no     -
snv_39                     yes      no     no        yes    -

Since the overall upgrade is OK, you just need to activate the fresh BE snv_39, export your data zpool and perform a clean reboot, otherwise the new environment will not be activated. Do not use the uadmin, halt, or reboot commands!

# luactivate snv_39
# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
snv_38                     yes      yes    no        no     -
snv_39                     yes      no     yes       no     -
#
# zpool export datazp
# shutdown -y -g 0 -i 6

Et voilà! After the reboot, you must see something similar to:

# uname -a
SunOS unic 5.11 snv_39 i86pc i386 i86pc
#
# cat /etc/release
                            Solaris Nevada snv_39 X86
           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                              Assembled 01 May 2006

Last, please find some invaluable documentation on the subject below:

Monday 1 May 2006

How to Patch a Live System Mirrored with SVM

Aim of this memo

The main purpose of this technical note is to demonstrate how to patch a running (live) system currently mirrored using SVM, minimizing the downtime as far as possible.

The idea is simple: detach one side of the mirror, apply the cluster patch against it and reboot on it. If all seems OK, re-encapsulate the system. This can achieve similar goal currently found in the Live Upgrade feature of the Solaris OS (see live_upgrade(5)), with less complexity and different requirement (LVM RAID-1 vs. spare disk, or free slice).

Using this solution, the downtime can go between 10 to 30 minutes of service unavailability (depending on the hardware POST) and a maximum of two reboots are required, whatever is the number of patches to apply.

Here it is

Here is a system encapsulated using SDS 4.x or SVM 1.x, and the associated SVM encapsulation configuration:

# metastat -p
d3 -m d13 d23 1
d13 1 1 c0t0d0s3
d23 1 1 c0t1d0s3
d1 -m d11 d21 1
d11 1 1 c0t0d0s1
d21 1 1 c0t1d0s1
d0 -m d10 d20 1
d10 1 1 c0t0d0s0
d20 1 1 c0t1d0s0
#
# cat /etc/vfstab
#device         device          mount   FS      fsck    mount   mount
#to mount       to fsck         point   type    pass    at boot options
#
fd      -       /dev/fd fd      -       no      -
/proc   -       /proc   proc    -       no      -
/dev/md/dsk/d3  -       -       swap    -       no      -
/dev/md/dsk/d0  /dev/md/rdsk/d0 /       ufs     1       no      -
/dev/md/dsk/d1  /dev/md/rdsk/d1 /var    ufs     1       no      -
swap    -       /tmp    tmpfs   -       yes     -

Run an explorer and generate a cluster patch, based on tools provided by the OSE for example, if you are luckily enough to have one included with your support plan (or just pick one provided at SunSolve).

Then, be sure to be able to boot on the two disks, just in case:

# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0

The next step is to voluntarily detach one side of the mirror: take the first one for the sake of simplicity (i.e. c0t0d0). Indeed, in this case we are pretty sure that its alias name at the OBP is disk.

Note: You can always create it at the OBP (using the usual set of commands, such as show-disks, devalias, etc.) if you want. That is just a matter of personal preferences.

# lockfs -af /* Just to minimize the fs inconsistencies at next fsck(1m). */
#
# metadetach d0 d10
# metadetach d1 d11
# metadetach d3 d13
#
# metaclear d10
# metaclear d11
# metaclear d13

Check and repair the file systems if necessary, since we will boot on them the next time:

# fsck /dev/dsk/c0t0d0s0
# fsck /dev/dsk/c0t0d0s1

Next steps include mounting the recently detached file systems and prepare the first disk to boot without SVM encapsulation:

# mkdir /mirror
# mount /dev/dsk/c0t0d0s0 /mirror
# mount /dev/dsk/c0t0d0s1 /mirror/var
#
# cat << EOF > /mirror/etc/vfstab
#device         device          mount   FS      fsck    mount   mount
#to mount       to fsck         point   type    pass    at boot options
#
fd      -       /dev/fd fd      -       no      -
/proc   -       /proc   proc    -       no      -
/dev/dsk/c0t0d0s3       -       -       swap    -       no      -
/dev/dsk/c0t0d0s0       /dev/rdsk/c0t0d0s0      /       ufs     1       no      -
/dev/dsk/c0t0d0s1       /dev/rdsk/c0t0d0s1      /var    ufs     1       no      -
swap    -       /tmp    tmpfs   -       yes     -
EOF
#
# cp /mirror/etc/system /mirror/etc/system.orig
# sed -e 's;rootdev:/pseudo/md@0:0,0,blk;*rootdev:/pseudo/md@0:0,0,blk;' \
   /mirror/etc/system.orig > /mirror/etc/system

Last, install patches against the first disk, clean things up a little and reboot if the install procedure went all smooth:

# ./install_all_patches -R /mirror
#
# umount /mirror/var
# umount /mirror
# rmdir /mirror
#
# shutdown -y -g 0 -i 6

After rebooting, carefully review the behavior of the very freshly patched system. If all seems well, don't forget to re-encapsulate the second disk. Here is a quick and easy way to this:

/* Recreate the metadb. */
# metadb -d c0t0d0s4 c0t1d0s4
# metadb -a -c3 -f c0t0d0s4 c0t1d0s4
#
/* Clean the system metadevices always present. */
# metaclear d0
# metaclear d1
# metaclear d3
# metaclear d20
# metaclear d21
# metaclear d23
#
/* Re-create them as part of a mirror. */
# metainit -f d10 1 1 c0t0d0s0
# metainit d0 -m d10
# metainit -f d11 1 1 c0t0d0s1
# metainit d1 -m d11
# metainit -f d13 1 1 c0t0d0s3
# metainit d3 -m d13
#
/* Be able to boot on the new metadevices. */
# metaroot d0
#
/* Reboot, and create the second side of the mirror. */
# shutdown -y -g 0 -i 6
[...]
# metainit d20 1 1 c0t1d0s0
# metattach d0 d20
# metainit d21 1 1 c0t1d0s1
# metattach d1 d21
# metainit d23 1 1 c0t1d0s3
# metattach d3 d23

For a little more detailed explanation about encapsulating the system using SVM on Sun Solaris, please refer to the dedicated entry in this blog.

Last, it must be mentioned that this documentation was written by our OSE, and that this procedure was officially marked as supported by Sun Microsystems.

Friday 3 February 2006

FreeBSD Port Patch Preview for the Last NanoBlogger's 3.3 RC4

Because i will be far from a computer for more than a week (as of today!), i post the preview patch for the www/nanoblogger port.

You can apply and install it using the following steps:

# cd /usr/ports/www/nanoblogger && make deinstall
# cd /usr/ports && patch < /tmp/nanoblogger.patch
# cd /usr/ports/www/nanoblogger && make install clean clean-depends

Be aware that there are a lot of changes in NanoBlogger itself, so read carefully the NanoBlogger User Manual online documentation and the pkg-message post installation output. After the installation, you can (re)read it using:

# pkg_info -D /var/db/pkg/nanoblogger

Download: nanoblogger.patch

Friday 12 August 2005

Adding a New Plugin Using the NanoBlogger Framework

Discussing how to add a copyright notice at each page automatically on the NanoBlogger mailing list, here are the two propositions i can think of.

It can be done by adding directly the copyright notice in the desired template files (i.e. templates/main_index.htm, etc.):

  1. Either writing it in the corresponding files...
    $ diff -u templates/main_index.htm templates/main_index.htm.hardwritten
    --- templates/main_index.htm Wed Jul 6 14:49:05 2005
    +++ templates/main_index.htm.hardwritten Mon Aug 8 13:12:05 2005
    @@ -29,6 +29,10 @@
    $NB_Entries
    </div>
    
    +<div class="side">
    +All content herein © 2006, Your Company, Inc. All right reserved.
    +</div>
    +
    <div id="menu">
    $NB_PageLinks
    </div>
    
  2. Or writing a little plugin to do that... (based on the plugins/fortune.sh code)
    # cat << EOF > ${NB_INST_PATH}/plugins/copyright.sh
    # NanoBlogger Copyright plugin.
    
    # sample code for templates, based off default stylesheet
    #
    # <div class="side">
    # $NB_Copyright
    # </div>
    
    PLUGIN_OUTFILE="$BLOG_DIR/$PARTS_DIR/copyright.$NB_FILETYPE"
    
    nb_msg "generating copyright ..."
    echo '<div class="copyright">' > "$PLUGIN_OUTFILE"
    echo 'All content herein © 2006, Your Company, Inc. All right reserved.' >> "$PLUGIN_OUTFILE"
    echo '</div>' >> "$PLUGIN_OUTFILE"
    NB_Copyright=$(< "$PLUGIN_OUTFILE")
    EOF
    $
    $ diff -u templates/main_index.htm templates/main_index.htm.plugin
    --- templates/main_index.htm Wed Jul 6 14:49:05 2005
    +++ templates/main_index.htm.plugin Mon Aug 8 13:12:29 2005
    @@ -29,6 +29,10 @@
    $NB_Entries
    </div>
    
    +<div class="side">
    +$NB_Copyright
    +</div>
    +
    <div id="menu">
    $NB_PageLinks
    </div>
    

The advantage of the second proposition is the capability to add a general feature using the NanoBlogger framework, and the use of the CSS to modify the new copyright class.

- page 1 of 2