Faq

From JetResources
Jump to: navigation, search

Contents

Frequently Asked Questions

Installation

What are these '.pkg'/'pkg.bz2' files ?

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

     pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

     pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

A GUI Frontend for JET

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

Getting Help with JET

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).


Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

Whats in the Free Bundle ?

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

   * SUNWjet - The core JET product
   * SUNWjetd - The documentation - Please read
   * JetSDS - Configure SVM/SDS
   * JetVTS - Install the Test Suite
   * JetEXPLO - Install and configure Explorer
   * JetFLASH - Utilise flash archives for installation
   * JetSAN - Configure SANs
   * JetJASS - JASS toolkit install and configuration
   * JetZONES - Add local zones to your Solaris 10 global zones as part of the build
   * JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
   * JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

Solaris 10 U1 (01/06) grub/newboot

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.


To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

   * base_config_allocation_method="newboot"


As a guide to what to use:

   * With Solaris 10 GA (03/05)
         o base_config_allocation_method="dhcp"

   * With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
         o base_config_allocation_method="newboot"

   * With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
         o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

Using 'iso' images instead of CD/DVDs

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

  # dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
  1+0 records in
  1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

  # od -D -j 452 -N 8 < vtoc
  0000000 0000000888 0000546560
  0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

  # echo 888*640 | bc
  568320

So now you know s1 starts at block 568320 and is 546560 blocks long.
3. Copy slice one into a separate file:

  # dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
  546560+0 records in
  546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

  # mkdir /cd
  # mkdir /cd/s0
  # mkdir /cd/s1
  # lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
  # lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

  When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

  # mount -F hsfs -o ro /dev/lofi/1 /cd/s0
  # mount -F ufs -o ro /dev/lofi/2 /cd/s1
  # cd /cd/s0/Solaris_9/Tools/
  # ./setup_install_server /destination_dir

How To Upgrade JET

Upgrading JET is normally as easy as

   * pkgrm SUNWjet
   * pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.


However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are

  • remember to update your .profile with the new path (/opt/SUNWjet/bin)
  • if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

How to set up JET as a PXE (DHCP) Server

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network ie

   NETWORK=10.1.1.0

   NETMASK=255.255.255.0

   ROUTER=10.1.1.1

   dhcpconfig -D -r SUNWfiles -p /var/tmp
   dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 and Solaris 11 ?

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10 (and indeed Solaris 11), in the same fashion as with previous versions of Solaris.

You can't currently use JET to install Solaris 11 systems, as Oracle have changed the installation technology to 'Auto Install' which is different from JumpStart. You can still use a Solaris 11 system to deliver both Jet/JumpStart installs to Solaris 10 (or lower) clients, and AI installs to Solaris 11 at the same time though.

Install v.s. Upgrades

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

Using OpenSolaris as a JET server

If you have installed OpenSolaris, you may need to add the following packages to enable all services required.

For rpc.bootparamd and in.tftpd, needed to jumpstart a SPARC box, SUNWbs (formerly the packages were SUNWbsu and SUNWbsr)

Timeservices SUNWcns

Using Solaris 11 as a JET server

Solaris 11 is "different" with Auto Install replacing JumpStart. This means it does not include many packages required for JumpStart by default

To enable S11 to act as a JET server, add the following.

pkg install system/boot/network

         Name: system/boot/network
      Summary: Boot server daemons
  Description: Support for legacy network boot services including the Reverse
               Address Resolution Protocol (RARP) (RFC 903) and the boot
               parameters RPC service. 

pkg install network/dhcp/dhcpmgr - incase you want to use the GUI

pkg install service/network/dhcp - for pntadm etc

S11 tftpboot does not recognise /tftpboot.

Just ln -s /tftpboot /etc/netboot

Then carry on as normal, except using zfs share and not /etc/dfs/dfstab

Configuration

JET and Boot Servers

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.


If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

Disksuite Soft Partitions

The easiest way is to create an md.tab file and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

   d50 -p d40 100m
   d40 -m d41
   d41 1 1 /dev/rdsk/c1t0d0s0
   d42 1 1 /dev/rdsk/c2t0d0s0


or for creating a mirrored stripe with softpartitions:

   d70 -p d60 1g
   d60 -m d61
   d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
   d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0


In addition, the disks used above should all have their vtocs created. This is achieved with the following lines from JET base_config:

   base_config_profile_disk_c0t1d0s0_size="free"
   base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)


Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

   sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
   sds_metadevices_to_attach="d40:d42 d60:d62"


and then add the entries for /etc/vfstab:

   sds_newfs_devices="/dev/md/rdsk/d50"
   sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

Upgrade vs Install

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

  1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

  2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

Using SVM to mirror root disks

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

JET and JASS Integration

You need to get hold of the JetJASS module, which as far as I know is not part of the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will add the JASS module details to your template. After that, the options are pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

How does this JetZONES module work ?

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

  • Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
  • Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
  • Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
    • zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

How does flash work with JET ?

The JetFLASH module can be added in like any other

make_template -f -T <template> <template> flash

Simply edit the template, get to the new flash section and edit the flash_archive= with the path to your NFS shared flar file

line, taking note of the example higher up

ie flash_archive_locations="nfs://10.1.1.11/archives/sample"

Rerun make_client and JumpStart


What is the recommended flash creation line

A recommended line to produce a flash archive

flarcreate -n "<Something meaningfull>" -R / -S -c file

ie:

flarcreate -n "Sol10 U2+Rec Patches" -R / -S -c /var/tmp/s10.flar

Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module.

You use JET exactly as you would do for a normal build; it just means that the usual profile information (cluster etc) gets ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied after the first reboot, exactly as a normal JET build.

Is it possible to include the DB and application into the install?

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

How can I add packages after the initial installation and patching?

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

Adding Mount Options

The base_config_profile_s?_mtpt variables are used to populate the client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!


How do I create additional disk/mirrors

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

JetZONES and other modules - an anomoly

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.


Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir


An example below shows the build still worked


make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1 
 
#######                                                   ###
#          ##       #    #       ######  #####            ###
#         #  #      #    #       #       #    #           ###
#####    #    #     #    #       #####   #    #            #
#        ######     #    #       #       #    #
#        #    #     #    #       #       #    #           ###
#        #    #     #    ######  ######  #####            ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

Troubleshooting

Solaris x86 Media on Sparc (and vice-versa)

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run setup-install-server on your laptop as well as using an x86 Solaris CD on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of the miniroot under "Boot" in the Tools directory of the CD-ROM. The whole filesystem would be of the "hsfs" type and thus readable across architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x  18 root     other       4096 Dec 18  2001 Boot/
-rwxr-xr-x   1 root     bin        59058 Nov 27  2001 add_install_client
-rwxr-xr-x   1 root     sys         1325 Nov 27  2001 dial
-rwxr-xr-x   1 root     bin        18599 Nov 27  2001 rm_install_client
-rwxr-xr-x   1 root     bin        11689 Nov 27  2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x  17 root     other       4096 Dec 18  2001 Boot/
-rwxr-xr-x   1 root     bin        59058 Nov 27  2001 add_install_client
-rwxr-xr-x   1 root     sys         1325 Nov 27  2001 dial
-rwxr-xr-x   1 root     bin        18599 Nov 27  2001 rm_install_client
-rwxr-xr-x   1 root     bin        11689 Nov 27  2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're actually running from when you boot off of the CD. However, as ufs is architecture specific, you can't mount a SPARC ufs partition on an x86 box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of 2 should be all that is needed to do an "End User" install. Certain packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02. Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx   1 root     other         11 Apr 15  2002 Boot -> ../../../s1
-rwxr-xr-x   2 root     bin        59586 Apr 15  2002 add_install_client
-rwxr-xr-x   2 root     sys         1325 Apr 15  2002 dial
-rwxr-xr-x   2 root     bin        18599 Apr 15  2002 rm_install_client
-rwxr-xr-x   2 root     bin        13045 Apr 15  2002 setup_install_server

s1 however is ufs, which is architecture specific.


user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does 
not exist
       Check that boot image exists, or use [-t] to
       specify a valid boot image elsewhere


Getting it to work These instructions are architecture neutral. They will work if you are trying to configure jumpstart from an x86 server to a SPARC client or setting up a SPARC server to jumpstart x86 clients.


Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:
#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"


Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read 

only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3 15:09:39 2002

/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read 

only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3 15:09:39 2002

# share
-               /cdrom   ro,anon=0   ""
-               /cdrom/sol_9_x86/s2   ro,anon=0   ""
-               /cdrom/sol_9_x86/s0   ro,anon=0   ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot                  dial                  setup_install_server
add_install_client    rm_install_client

Alternately, you can mount up the directories manually. For example: 

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script. 

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete
You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular method. Your mileage may vary.

ARP/RARP Timeouts

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

   * At the OBP prompt, do a 'show-nets' to list the network adapters available
   * Select the adapter
   * cd <ctrl+y>
   * .properties


System hangs at a # prompt

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

Forcing Speed/Duplex during JumpStart

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called "forced mode". For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards (ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved. The driver must be forced in all 3 steps of the jumpstart boot process.


1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
       or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net


2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed. 
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .


3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf  or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1 
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

JumpStart & JET logs

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.


JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

Solaris 10, SSH doesn't start

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
       /lib/svc/method/sshd -c 
fi

/usr/sbin/svcadm clear network/ssh


TFTP Problems While Booting

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.


Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

Solaris 10 Update 1 and Flash archive problems

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml


This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

Unable to locate suitable disks

If you install Solaris onto scrubbed disks which have no Solaris label on them, the install will halt because it can't find disks to install too. This is normally more of an issue with x86 systems that don't have a Solaris partition, but can also be encountered on Sparc boxes too.

On Sparc systems, use the 'format' command to 'label' the disks; on x86, fdisk can be used to create a Solaris partition.

I am warned about missing patches, but cannot add

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.


As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

Bug / Problem Reporting

Having Problems with JET and need help ?

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

Reporting a Bug

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

Request For Enhancements (RFEs)

If you discover something you want changed in JET, then it normally falls into two categories:

   Implement it in a module
       Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.
   Submit the change as an RFE
       If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.