Cloning a Solaris Zone

I tried out cloning on a Solaris Zone today and it was a breeze, so much easier (and far, far quicker) than creating another zone from scratch and re-installing all the same users, packages, port lock-downs etc. Here are my notes from the exercise:

Existing System Setup

SunFire T1000 with a single sparse root zone (zone1) installed in /export/zones/zone1. The objective is to create a clone of zone1 called zone2 but using a different IP address and physical network port. I am not using any ZFS datasets (yet).


1. Export the configuration of the zone you want to clone/copy

# zonecfg -z zone1 export > zone2.cfg

2. Change the details of the new zone that differ from the existing one (e.g. IP address, data set names, network interface etc.)

# vi zone2.cfg

3. Create a new (empty, unconfigured) zone in the usual manner based on this configuration file

# zonecfg -z zone2 -f zone2.cfg

4. Ensure that the zone you intend to clone/copy is not running

# zoneadm -z zone1 halt

5. Clone the existing zone

# zoneadm -z zone2 clone zone1
Cloning zonepath /export/zones/zone1...
This took around 5 minutes to clone a 1GB zone (see notes below)

6. Verify both zones are correctly installed

# zoneadm list -vi
0 global running /
- zone1 installed /export/zones/zone1
- zone2 installed /export/zones/zone2

7. Boot the zones again (and reverify correct status)

# zoneadm -z zone1 boot
# zoneadm -z zone2 boot
# zoneadm list -vi
0 global running /
5 zone1 running /export/zones/zone1
6 zone2 running /export/zones/zone2

8. Configure the new zone via its console (very important)

# zlogin -C zone2

The above step is required to configure the locale, language, IP settings of the new zone. It also creates the system-wide RSA key pairs for the new zone, without which you cannot SSH into the zone. If this step not done, many of the services on the new zone will not start and you may observe /etc/.UNCONFIGURED errors in certain log files.


You should now be able to log into the new zone, either from the root zone using zlogin or directly via ssh (of configured). All of the software that was installed in the existing zone was present and accounted for in the new zone, including SMF services, user configuration and security settings etc.


If you are using ZFS datasets in your zones, then you may see the following error when trying to execute the clone command for the newly created zone:

Could not verify zfs dataset tank/xxxxx: mountpoint cannot be inherited
zoneadm: zone xxxxx failed to verify

To resolve this, you need to ensure that the mountpoint for the data set (i.e. ZFS partition) being used has been explicitly set to none. Even though the output from a zfs list command at the global zone might suggest that it does not have a mount point, this has happened to me a number of times and in each case, the following command did the trick for me:

# zfs set mountpoint=none tank/xxxxx


Solaris Live Upgrade on SunFire T1000/T2000 servers

The process of installing and configuring Live Upgrade on Solaris is pretty well covered at this stage but, as ever with Solaris, there is always something that is not covered in the many existing documents and blog postings on the subject. So, here is an overview of what I did, what worked, what did not work and how I overcame the bits that did not work.


I wanted to use Live Upgrade to ease the painful patching process on Solaris (not to upgrade the operating system). I tried this on a SunFire T1000 and a SunFire T2000 both running Solaris 2.10 U3 (06/06). In both cases, the systems contained 2 existing 10GB UFS file systems (/ on c0t0d0s0 and /opt on c0t0d0s3) as well as a swap partition (c0t0d0s1).

What Did Work

Following the Live Upgrade documentation from the Sun website, I narrowed the commands down to the following steps:

Create a new partition to accommodate the Alternative Boot Environment
# format
Created a Live Upgrade configuration:
# lucreate -c solaris_env_1 -n solaris_env_2 -m /:/dev/dsk/c0t0d0s4:ufs
Verified the successful creation using
# lustatus
# lucurr

Downloaded any available patches for this system
# smpatch download
Install the downloaded patches in the alternative boot environment
# smpatch update -b solaris_env_2
Reboot the system in the recommended manner
# init 6

What Did Not Work

No matter how many times I retried to reboot the system (in full accordance with the instructions in the documentation), the system simply refused to boot from the new/alternative boot environment. Each time, the lustatus command showed that both boot environment were correctly configured and that the alternative environment (solaris_env_2) was scheduled to boot at the next reboot. However, it never did boot from the alternative environment.
Apparently, when the patch process completes successfully (or whenever you use the luactivate command), the system should automatically update the boot-device EEPROM environment variable (see eeprom command from Solaris).


I found that the only way around this problem was to manually adjust the boot-device environment variable from the system console each time you need to boot an alternative boot environment. This was done (from the system console) as follows:

Shut down the system
# init 0
Determine the appropriate setting for the boot-device variable
ok setenv auto-boot? false
ok reset-all
ok probe-scsi-all
ok show-disks

Using the output from the above commands, determine a new value for the boot-device variable. For example:
ok setenv boot-device /pci@7c0/pci@0/pci@8/scsi@2/disk@0,0:a
Verify that the system still boots from the old/existing environment
ok boot
If so, you should now be able to drop back to the boot prompt and set the boot-device variable to a new value in accordance to the Live Upgrade partition you created earlier (in my case, c0t0d0s4 or disk@0,0:e)
ok setenv boot-device /pci@7c0/pci@0/pci@8/scsi@2/disk@0,0:e
Also, you might like to return auto-boot setting to its normal value before booting the system again
ok setenv auto-boot? true
ok boot

Best of luck!

Installing a Solaris JumpStart server

We acquired a number of SunFire T1000 servers recently which came with Solaris 10 U2 (06/06) pre-installed. Before putting them into full-time use, we decided to take the opportunity to upgrade them to a later revision of Solaris, namely U3 (or 10/06). However, since these systems do not come with an internal CDROM drive, we had to reinstall the operating system over the network and to do this we needed a JumpStart server.

I used this site as the basis of my activities. It looks like it was written for Solaris 2.7 but seemed to work just as well (for me) on Solaris 2.10. So, here are my notes on installing and configuring a Solaris 10 jumpstart server. I used an existing SPARC system as my jumpstart server.

1. Preparation

Configure some NFS-mountable directories to store the contents of the Solaris installation media and some additional jumpstart configuration files:

# mkdir /export/install/5.10u3-sparc
# mkdir /export/jumpstart

Add the following lines to the /etc/dfs/dfstab file to make these directories shareable:

# vi /etc/dfs/dfstab
share -F nfs -o ro,anon=0 /export/install/5.10u3-sparc
share -F nfs -o ro,anon=0 /export/jumpstart

Finally to share (and verify) these directories, use the following command:

# shareall

Finally, you will need to mount the CDROM/DVD containing the Solaris media. This should happen automatically as soon as you insert the disc in the drive (if your system has the Solaris Volume Manager running on it) but strangely, it did not for me. I actually had to restart the Volume Manager to get the DVD mounted:

# /etc/init.d/volmgt stop
# /etc/init.d/volmgt start

Now use the mount or df command(s) to verify that the CD/DVD has been mounted. For the record, here is a useful way to determine the device name for your CD/DVD drive:

# ls -al /dev/sr*
xrwxrwx 1 root root 12 May 2 16:42 /dev/sr0 -> dsk/c2t0d0s2
# mount -F hsfs -o ro /dev/dsk/c2t0d0s2 /mnt/cdrom

However, the Solaris 10 DVD contains several UFS slices and cannot be mounted in this way.

2. Installing the JumpStart Server

Assuming that your CD/DVD has been mounted on /cdrom, here is how to install the core of the jumpstart server:

# cd /cdrom/cdrom0/s0/Solaris_10/Tools
# ./setup_install_server /export/install/5.10u3-sparc

This will copy the appropriate contents from the CD/DVD to the relevant directories within /export/install/5.10u3-sparc. This part of the process can take some time to complete so be patient.

You may also want to configure a Boot Server (I wasn’t sure if I needed this but did it anyway):

# cd /cdrom/cdrom0/s0/Solaris_10/Tools
# ./setup_install_server -b /export/install/5.10u3-sparc/sun4v

3. Copying up the JumpStart sample configuration files

There are several configuration files within a JumpStart server and the Solaris CD contains some samples to get you started. We created a directory for these earlier but must copy them from the CD now:

# cp -r /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample/* /export/jumpstart

4. Setting up the JumpStart configuration files

As the reference site indicates, there are several files that need to be configured before you can attempt to initiate a network installation from a client, namely:


This file is mandatory and helps to define some rules to specify what (type of) clients are allowed to use this install server and what to do before and after the installation. I created a single rule as follows:

network XX.XX.XX.0 && arch sparc - myT1000 -

which says that only SPARC systems in the XX.XX.XX.0 network are allowed to use this server and when they do, the settings in the myT1000 file should be used to specify how those systems should be configured.


This file specifies how a given system should be configured by allowing you to predefine what type of installation you want, which software packages you want (and do not want) and how to lay out your file systems etc.

Here is the profile file that I used:

install_type initial_install
system_type server
partitioning explicit
filesys c0t0d0s0 10240 /
filesys c0t0d0s1 2048 swap
filesys c0t0d0s3 10240 /var
filesys c0t0d0s4 10240 /usr
filesys c0t0d0s5 10240 /opt
cluster SUNWCprog add
package SUNWauda delete
package SUNWaudh delete
package SUNWaudf delete
package SUNWxorg-devel-docs delete

As you can see, I chose the Developer Support software cluster but then requested that several software packages be excluded from it. I chose to remove many more than are shown here but I think you get the point…


This is an optional file that essentially allows you to specify extra settings for your installation. In summary, the more settings you specify here, the less questions you are asked during the network installation and the more automated the process becomes. Here is the sysidcfg file that I used:

name_service=DNS { domain_name=XXXX.YYY name_server=X.X.X.X,Y.Y.Y.Y search=XXX.YYY,XXX.YY }
network_interface=bge0 {netmask= default_route=X.X.X.X protocol_ipv6=no }

Once you have all of these files in place, you need to verify that they are syntactically correct. This is done using the check tool as follows:

# cd /export/jumpstart
# ./check
Validating rules...
Validating profile myT1000...
The custom JumpStart configuration is ok.

5. Telling the server about a client

Before you can commence an installation from a client, you need to tell the install server about that client. Since I was not using DHCP and already had a DNS server with a valid entry for my client, this stage was a little easier for me. Of course you also need to ensure that your server is running a TFTP Boot Server.

To tell the server about a client, you need to know the MAC address of the primary network adapter of the client and the intended hostname of the client. Once you know this, use the following command:

# cd /export/install/5.10u3-sparc/Solaris_10/Tools
# ./add_install_client -e 11:22:33:44:55:66 -s fonda:/export/install/5.10u3-sparc -c fonda:/export/jumpstart -p fonda:/export/jumpstart shefflin sun4v

The name of my client was shefflin (it was a sun4v system) and as I indicated earlier, the name of my server was fonda. Clearly, you will need to use your own values for the parameters as well as the correct MAC address. The result of this command is some new files in the TFTP Boot area as well an a new entry in the /etc/ethers file.

You are now ready to start the installation from the client.

6. Starting the Client Installation

This is actually the simplest part of the exercise and involves one command. However, you do need to ensure that the Network Management port of your client has been configured with a valid IP address. Anyway, to start the client installation, use the following command from the boot prompt of your client:

boot net - install

The system should then start installing the new version of Solaris. It will do things like request an IP address from the network, attempt to configure the network interfaces in the client and ultimately follow pretty much the same procedure as if you were installing from a CD or DVD. The more configuration files you provided on the server, the fewer questions you will be asked during the installation.

When the installation has completed, you will be dropped back to the (root) command prompt. You should now reboot the system after which you will be asked to provide a password for the root user. Upon completion of this task, you should finally be presented with the console login prompt and, hey presto, you’re done!

Reference Sites

Here are some other useful websites I discovered during this exercise:

And some links to others who have attempted the same task:

Best of luck!

Upgrading the firmware on a SunFire T2000

In preparation for installing a newer release of Solaris 10 on a SunFire T2000, we first decided to bring the system to the most recent version of firmware. Here is how we got on …

Personally, I have upgraded firmware on many different types of systems in the past and whilst the technique is invariably the same, there are always minor differences that catch you out. This is also true in this case (hence the reason for this article). We found that many of the articles covering this topic made certain assumptions (without realising) and thus, left out certain key information. This article attempts to address those omitted assumptions.

What is the latest version of firmware and where can I get it?

We found links to all versions of firmware for T2000 systems here. The latest version at the time this article was written was 6.4.4. The firmware is distributed in a ZIP file.

What do I do next?

The best source of information on installing the firmware you have just downloaded is contained in a file called which can be found inside the ZIP file you just downloaded.

What the does not tell you

Here is a list of things that I did not know before reading the but found out during …

  1. There are many references on how to use the System Controller Console (SC) to both determine whether you need an upgrade and also to carry out the upgrade. However, they don’t actually tell you how to get to it. I discovered that:
    • You do not need to shut down your system
    • You must type #. at the system console to get to the SC (that’s a hash followed by a dot).
  2. When you first access the SC, you will be asked to provide a password (for future sessions). However, later on when it comes to authenticating yourself, you are also asked for a username but nowhere do they tell you what this is. The default username is admin but this is not well documented.
  3. Once you have establlished your connection to the SC and determined whether or not you actually need a firmware upgrade, it will be time to use the flashupdate command. When I tried this, it kept telling me that it could not establish an FTP connection to the specified server. Once again, I soon discovered that:
    • The flash update process (via FTP) uses a different network port than the one for normal system operation. So I had to move my network connection on the T2000 to the network port labelled NET MGT. The network ports used for normal system operating are actually powered off at this time.
    • You need to assign an IP address to the NET MGT network port. This can be done using the setupsc command from the SC (click here for a separate article on this). Once this is done you then need to reset the SC (resetsc) after which you will require the username and password referred to earlier to regain access to the SC.
  4. Once you finally get to the stage where you have a proper outbound connection from the SC, there is still one last issue. It concerns the name of the file containing the firmware image that you are passing to the flashupdate command from SC (via the -f parameter). I had assumed that this path was relative to the home directory of the FTP user being used but it turns out it was not. I had to specify an absolute path (e.g. /tmp/abc.bin)


Essentially, the file is your friend but there were 3 fundamentals that it does not cover:

  1. You need to have a valid network connection to the NET MGT port
  2. Your NET MGT port must have a valid IP address, Mask and Gateway
  3. You must use an absolute path for the image file in the flashupdate command.

Now I fully accept that none of this is rocket science and much of it is indeed documented but if you have not done this before, you will waste time discovering these issues. So hopefully, you will benefit from knowing this and it will save you time some time in the future.

Best of luck!