1. Prepare your IBM System z machine:

   1. Add the following parameter line in /etc/zipl.conf:

      switch_amode

   2. Run zipl

   3. Reboot the runner

   4. After the reboot, run yast2 add-on

   5. Select Add and go to Local ISO image....

   6. Select the add-on image for System z and accept the End User License Agreement (EULA). The software selection dialog appears.

2. Select the filter SUSE Studio Upgrade for System z for add-on repository.

3. Select all packages in that repository.

4. Choose Install and accept the suggestion.

5. Finish with Ok to close the YaST module.

1. Log in to your SUSE Studio Onsite server.

2. Click the Admin User and Advanced links.

3. Click the Manage extension for System z link.

4. Enter the hostname or IP address of your previously configured System z runner. SUSE Studio requests all relevant information from the System z runner and creates a /studio/filestore directory. This directory will be made available to the System z runner host.

5. Wait until all the System z repositories and templates are added. This step is run automatically after the runner setup and takes some time.

6. Use a NFS share from SUSE Studio server on your IBM System z runner:

   1. Log in as root on your IBM System z runner.

   2. Open the file /etc/fstab and add the following line:

      UI_SERVER:/studio:filestore /studio/filestore nfs rw,nolock,auto 0 0

      Replace UI_SERVER with the name or IP address of your SUSE Studio Onsite server.

   3. Mount the share:

      mount /studio/filestore

   4. Open the file /srv/studio/runner/config/options.yml and locate the section production:. Change it to the following line (observe the two spaces before scheduler):

      production:
        scheduler: UI_SERVER:80

      Replace UI_SERVER with the name or IP address of your SUSE Studio Onsite server.

   5. Restart the Apache Web server:

      rcapache2 restart

   6. Enable and start Samba:

      insserv smb
      rcsmb start

1. Log in to your SUSE Studio Onsite server.

2. Click the Admin User and Advanced links.

3. Choose Repositories+Software.

4. Click the Hide button on the SLES11_SP1 System z template.

1. Install the image description for KIWI where you locate the faulty driver. For example, kiwi-desc-oemboot if you want to build an OEM images with a special driver.

2. Get to know the path of the image description, the product name and locate the config file. In our example, KIWI's OEM image description is installed under /usr/share/kiwi/image/oemboot/. If you want to change that for SUSE Linux Enterprise Server 11, add suse-SLES11 to the previous path. The full path yields /usr/share/kiwi/image/oemboot/suse-SLES11.

3. Insert the missing driver in the configuration file. Depending on the driver, you have several options:

   • If your driver is part of the standard Kernel, extend the drivers section as described in Step 4.

   • If your driver is not part of the standard Kernel, build a KMP package of your driver as described in http://developer.novell.com/wiki/index.php/Creating_a_Kernel_Module_Package_%28KMP%29. Insert the following highlighted line in the packages section:

     <packages type="image">
       <package name="..."/>
       <package name="YOUR_KMP_PACKAGE"/>
     </packages>

     Additionally create a repository for your driver RPM. Usually this is an ordinary directory for KIWI. Edit the file /usr/share/kiwi/image/oemboot/suse-SLE11/config.xml and insert:

     <repository type="rpm-dir">
       <source path="/path/to/your/repo"/>/>
     </repository>

   • If your driver is not part of the standard Kernel and you do not want to create a KMP package, the only option is to copy your binary driver into the overlay tree of the boot image description. The overlay tree is the directory in the image description, in our case /usr/share/kiwi/image/oemboot/suse-SLES11/root/. The overlay tree contains all the overlay files which you have changed or added. Note that binary drivers in the overlay tree are hard to maintain as the module has to match with the Kernel version. Use this method only as your last option.

4. Extend the drivers section as indicated with the highlighted line. Replace the dots with the corresponding driver name (extension .ko):

   <drivers type="drivers">
     <file name="..."/>
     <file name="drivers/..."/>
   </drivers>

   One additional note for KIWI users: KIWI tries to make the initrd as small as possible. As such, it removes everything which is not specified in the drivers section.

5. Create a new boot image with the following commands and replace URL with the repository URL:

   kiwi -p /usr/share/kiwi/image/oemboot/suse-SLES11 \
       --root /tmp/fixed-oemboot --set-repo URL
   
   kiwi --create /tmp/fixed-oemboot -d /tmp/myfixed-oemboot

6. Copy the initrd and the Kernel file on a USB stick (usually mounted as /media/disk). Name them initrd.kexec and linux.kexec:

   cp /tmp/myfixed-oemboot/kernel /media/disk/linux.kexec
   cp /tmp/myfixed-oemboot/initrd /media/disk/initrd.kexec

   The stick can only contain these two files.

7. Boot the media with the Kernel option hotfix=1.

Procedure 1.5. Obtaining IP Address of your SUSE Studio Server¶

1. During the boot process, press the Esc key to enter verbose boot mode.

2. Follow the boot messages and assure that one of the following messages is displayed:

   Loading KVM for intel

   or:

   Loading KVM for amd

   If you receive an error message check Section 1.1, “System Requirements”.

3. If you need to change your network parameters, log in as root (with password linux). The password is changed later in Step 5 of Procedure 1.6. Run yast network and select Network Card. There configure your network according to your needs. Find more information in the section Configuring a Network Connection with YaST under http://www.novell.com/documentation/sles11/book_sle_admin/data/sec_basicnet_yast.html.

   If you want to customize more than the network, use YaST to configure additional settings of your SUSE Studio Onsite server.

Procedure 1.6. Configuring Your SUSE Studio Onsite Server¶

1. Start a browser on a different machine and point the browser to your SUSE Studio Onsite instance. In our example it is https://192.168.1.1.

2. Accept the license agreement.

3. Register your SUSE Studio server with SMT or with the Novell Customer Center. The registration process is needed to get the necessary repositories in order to update SUSE Studio Onsite and to provide packages for all the images in the build step. Either way, without a successful registration you cannot proceed and SUSE Studio Onsite will not work. Choose the registration with SMT or Novell Customer Center:

   	Licenses and Expiring
   If an evaluation license expires, SUSE Studio will no longer work. If a full license expires, each user will see a red message on every page telling that the license has expired. In such case, SUSE Studio will still be functional. The administrator will see a message on his home screen two months before the license eventually expires.

   • If you have an SMT server (Subscription Management Tool), click Use SMT and enter the server hostname (without the protocol) to continue. Find detailed information in the section How to Get Mirroring Credentials of the SUSE Lifecycle Management Server Manual.

   • If you do not have an SMT server, register your product in the Novell Customer Center. Enter the following data to complete the registration procedure:

     • your e-mail address that you have used for registration in the Novell Customer Center,

     • your SUSE Linux Enterprise Server registration code,

     • your SUSE Studio registration code.

4. If you have used the Novell Customer Center for registration, enter username and password for your mirror credentials from the Novell Customer Center. Get your credentials from the link aside. In case you used SMT, skip this step.

5. Create the administrator account and enter the login name, password and e-mail address. Finish with Continue.

   	Changed Password for root
   Your administrator password for your SUSE Studio server is also synced with the system's root account. Use a safe and secure password.

1. Log in as root into your SUSE Studio Onsite server 1.0.

2. Do a maintenance update.

3. Run the export_from_onsite10.sh script. This script is part of the maintenance update. Replace the PATH placeholder where you want to store the resulting tar archives:

   /srv/studio/scripts/export_from_onsite10.sh PATH

   The script stops the services (RMDS, Thoth, Apache), packs the /studio directory, and creates a database dump. After running this script, you will get the files studio.tar.gz and studio_db.tar.gz.

4. Save the archives from Step 3 on a external storage device.

5. Shut down your SUSE Studio Onsite server 1.0 and deploy version 1.1 as described in Section 1.2, “Deploying SUSE Studio Onsite”. Do NOT run the setup wizard yet!

6. Log in as root into your SUSE Studio Onsite server 1.1.

7. Run the import_to_onsite11.sh script and insert the directory where the tar archives from Step 4 are stored, for example:

   /srv/studio/scripts/import_to_onsite11.sh /media/studio-backup

   The script migrates database dumps and populates the database with the old values.

8. Run the setup wizard manually by entering the domain of your SUSE Studio server and the path /admin/onsite/license. For example http://YOUR-STUDIO-SERVER/admin/onsite/license.

1. Log in as root into your SUSE Studio Onsite server 1.1.

2. Do a maintenance update.

3. Run the export_from_onsite11.sh script. This script is part of the maintenance update. Replace the PATH placeholder where you want to store the resulting tar archives:

   /srv/studio/scripts/export_from_onsite11.sh PATH

   The script stops the services (RMDS, Thoth, Apache), packs the /studio directory, and creates a database dump. After running this script, you will get the file studio_export-1.1.tar.gz.

4. Save the archive from Step 3 on a external storage device.

5. Deploy version 1.2 on a different server as described in Section 1.2, “Deploying SUSE Studio Onsite”. Do NOT run the setup wizard yet!

6. Log in as root into your SUSE Studio Onsite server 1.2.

7. Run the import_to_onsite12.sh script and insert the directory where the tar archive from Step 4 are stored, for example:

   /srv/studio/scripts/import_to_onsite12.sh /media/studio-backup

   The script migrates database dumps and populates the database with the old values.