Difference between revisions of "Faq"

From JetResources
Jump to: navigation, search
Line 86: Line 86:
 
JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.
 
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
+
==== Using 'iso' images instead of CD/DVDs ====
  
 
The following was derived from information at http://www.unix.com/showthread.php?t=18074
 
The following was derived from information at http://www.unix.com/showthread.php?t=18074
Line 174: Line 174:
  
  
==== How To Upgrade JET
+
==== How To Upgrade JET ====
  
 
Upgrading JET is normally as easy as
 
Upgrading JET is normally as easy as
Line 197: Line 197:
 
     * 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
 
     * 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
+
==== 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".
 
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".
Line 224: Line 224:
 
JET will now "do the right thing" based on the allocation method in your template.
 
JET will now "do the right thing" based on the allocation method in your template.
  
==== I noticed alot of docs for jumpstart setup for solaris8,9 I dont see one for solaris10. Why isnt there one for 10? i am interesting in setting up jumpstart for upgrades and clean install. is is safe to do jumpstart straioght from sol7 to sol10?
+
==== I noticed alot of docs for jumpstart setup for solaris8,9 I dont see one for solaris10. Why isnt there one for 10? i am interesting in setting up jumpstart for upgrades and clean install. is is safe to do jumpstart straioght from sol7 to sol10? ====
  
 
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 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.
Line 234: Line 234:
 
=== Configuration ===
 
=== Configuration ===
  
==== JET and Boot Servers
+
==== 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.
 
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.
Line 241: Line 241:
 
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!
 
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
+
==== Disksuite Soft Partitions ====
  
 
The easiest way is to create an md.tab file
 
The easiest way is to create an md.tab file
Line 282: Line 282:
 
     sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"
 
     sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"
  
==== Upgrade vs Install
+
==== 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 ?
 
JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?
Line 294: Line 294:
 
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!
 
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
+
==== 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."
 
"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."
Line 302: Line 302:
 
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.
 
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
+
==== JET and JASS Integration ====
  
 
You need to get hold of the JetJASS module, which as far as I know is not part of
 
You need to get hold of the JetJASS module, which as far as I know is not part of
Line 313: Line 313:
 
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.
 
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 ?
+
==== 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 :
 
The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :
Line 342: Line 342:
 
Further comments are within the the zone template
 
Further comments are within the the zone template
  
==== 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.
+
==== 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
 
You use JET exactly as you would do for a normal build; it just
Line 353: Line 353:
 
after the first reboot, exactly as a normal JET build.
 
after the first reboot, exactly as a normal JET build.
  
==== Hi, I have read that jumpstart automates the installation of the OS. Is it possible to include the DB and application?
+
==== Hi, I have read that jumpstart automates the installation of the OS. Is it possible to include the DB and application? ====
  
 
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.
 
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.
Line 359: Line 359:
 
Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.
 
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?
+
==== 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.
 
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.
Line 367: Line 367:
 
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.
 
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
+
==== Adding Mount Options ====
  
 
The base_config_profile_s?_mtpt variables are used to populate the
 
The base_config_profile_s?_mtpt variables are used to populate the
Line 381: Line 381:
  
  
==== How do I create additional disk/mirrors
+
==== How do I create additional disk/mirrors ====
  
 
JET can be used to create additional mirrors by creating the slices in the base_config section
 
JET can be used to create additional mirrors by creating the slices in the base_config section
Line 427: Line 427:
 
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.
 
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 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)
 
JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)
Line 483: Line 483:
 
=== Troubleshooting ===
 
=== Troubleshooting ===
  
==== Solaris x86 Media on Sparc (and vice-versa)
+
==== Solaris x86 Media on Sparc (and vice-versa) ====
  
 
Jumpstarting with x86 Laptops and SPARC systems
 
Jumpstarting with x86 Laptops and SPARC systems
Line 706: Line 706:
 
method. Your mileage may vary.
 
method. Your mileage may vary.
  
==== ARP/RARP Timeouts
+
==== 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 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.
Line 724: Line 724:
  
  
==== System hangs at a # prompt
+
==== 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.
 
If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.
Line 730: Line 730:
 
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.
 
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
+
==== Forcing Speed/Duplex during JumpStart ====
  
 
You really should just use Auto-negotiation on switches; it works these days and is reliable.
 
You really should just use Auto-negotiation on switches; it works these days and is reliable.
Line 770: Line 770:
 
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;
 
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;
  
==== JumpStart & JET logs
+
==== 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.
 
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.
Line 779: Line 779:
 
The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.
 
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
+
==== 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.
 
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.
Line 801: Line 801:
  
  
==== TFTP Problems While Booting
+
==== 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.
 
A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.
Line 814: Line 814:
 
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 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
+
==== 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 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.
Line 833: Line 833:
 
This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).
 
This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).
  
==== I am warned about missing patches, but cannot add
+
==== I am warned about missing patches, but cannot add ====
  
 
If you get the warning
 
If you get the warning
Line 855: Line 855:
 
=== Bug / Problem Reporting ===
 
=== Bug / Problem Reporting ===
  
==== Having Problems with JET and need help ?
+
==== 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.  
 
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
+
==== 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.
 
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.
Line 865: Line 865:
 
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.
 
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)
+
==== Request For Enhancements (RFEs) ====
  
 
If you discover something you want changed in JET, then it normally falls into two categories:
 
If you discover something you want changed in JET, then it normally falls into two categories:

Revision as of 14:47, 3 September 2007

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. Code:


  1. 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: Code:


  1. 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. Code:


  1. 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: Code:


  1. 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: Code:


  1. 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: Code:


  1. mkdir /cd
  2. mkdir /cd/s0
  3. mkdir /cd/s1
  4. lofiadm -a /path_to/sol-9-u1-sparc-v1.iso

/dev/lofi/1

  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: Code:


  1. mount -F hsfs -o ro /dev/lofi/1 /cd/s0
  2. mount -F ufs -o ro /dev/lofi/2 /cd/s1
  3. cd /cd/s0/Solaris_9/Tools/
  4. ./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.

I noticed alot of docs for jumpstart setup for solaris8,9 I dont see one for solaris10. Why isnt there one for 10? i am interesting in setting up jumpstart for upgrades and clean install. is is safe to do jumpstart straioght from sol7 to sol10?

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 unless anything specific is said, it works in the same fashion with 10 (and indeed 11) in the same fashion as previous versions of Solaris.

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.

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.
         o
           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

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.

Hi, I have read that jumpstart automates the installation of the OS. Is it possible to include the DB and application?

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

  1. You can specify additional disks to use/configure here
  2. additional_disks is a space separated list of c?t?d? type disk names
  3. For each disk listed in additional_disks, a pair of variables of the form
  4. base_config_profile_disk_c?t?d?s?_mtpt="...."
  5. base_config_profile_disk_c?t?d?s?_size="...."
  6. should be defined for each slice required on the disk.
  7. 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

  1. You can also describe other simple mirrors - these only work if you define
  2. the partitions in the base_config_profile_disk_ variables
  3. The format of this variable is a space separated list of source=target,
  4. 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


---8< make_client output

checking product base_config/solariszone Checking product custom WARNING: CUSTOM: Unable to locate custom package SFWmozilla


Check of client b1-zone1

              1. ###
  1. ## # # ###### ##### ###
  2. # # # # # # # ###
          1. # # # # ##### # # #
  3. ###### # # # # #
  4. # # # # # # # ###
  5. # # # ###### ###### ##### ###

---8<

---8< 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

q
  1. uname -a

SunOS b1-zone1 5.10 Generic_118855-33 i86pc i386 i86pc

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:

  1. pwd

/cdrom/sol_9_sparc/Solaris_9/Tools

  1. ./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:

  1. 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)


  1. 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 byt 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.

  1. 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

  1. 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.

  1. pwd

/

  1. cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
  2. pwd

/cdrom/sol_9_x86/s2/Solaris_9/Tools

  1. ls

Boot dial setup_install_server add_install_client rm_install_client

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

  1. mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
  2. mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0

/mnt/sol_9_x86/s0

  1. 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.

  1. ./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.


o 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


o 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 .


o 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.

  1. !/bin/sh
  2. 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:

  1. svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml


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

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.