SLES10 no longer supports selections but uses patterns. AutoYaST cannot convert selections to patterns. If you want to use a SLES9 AutoYaST profile to install a SLES10 server, you have to remove all addon entries and the base entry. Patterns are configured like this:

  <software>
    <patterns config:type="list">
        <pattern>directory_server</pattern>
    </patterns>
    <packages  config:type="list">
      <package>apache</package>
      <package>sendmail</package>
    </packages>
    <do_online_update config:type="boolean">true</do_online_update>  <!-- since openSUSE 11.1 -->
  </software>

The packages section is still the same as on a SLES9. Just the addon and base sections are gone.

This feature is available since openSUSE 11.1 but not in SLES11.

Since openSUSE 11.0 you can use images during installation to speed up the installation. This feature is available in openSUSE 11.1 as well.

   <!-- since openSUSE 11.1 -->
   <!-- note! this is not in the software section! -->
  <deploy_image>
      <image_installation config:type="boolean">false</image_installation>
  </deploy_image>

In addition to the packages available for installation on the CD-ROMs, you can add external packages including customized kernels. Customized kernel packages must be compatible to the SuSE packages and must install the kernel files to the same locations.

Unlike in earlier in versions, you do not need a special resource in the control file to install custom and external packages. Instead you need to re-create the package database and update it with any new packages or new package versions in the source repository.

A script is provided for this task which will query packages available in the repository and create the package database. Use the command /usr/bin/create_package_descr. When creating the database, all languages will be reset to English.

cd /usr/local/CDs/LATEST/suse
	create_package_descr  -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse

In the above example, the directory /usr/local/CDs/LATEST/suse contains the architecture dependent and independent packages, i.e. noarch and i586. This might look different on other architectures.

The advantage of this method is that you can keep an up-to-date repository with fixed and updated package (e.g. from SuSE FTP server). Additionally this method makes the creation of custom CD-ROMs easier.

Changes starting with SUSE Linux 10.1/SLES 10

With SLES10/SL10.1, the concept of adding your own RPMs to an installation source has changed. Neither yast/order nor yast/instorder are supported any longer by AutoYaST or by YaST. To add your own RPMs to an installation source (or add-on products like the SDK), add a file add_on_products to CD1 of the main product. media_url [path_on_media [product_1 [product_2 [....]]] media_url is the URL of the media, path_on_media is the path to the catalog on the media. If not present, / (root) is assumed. product_1 and following are the names of products, which should be marked for installation. If no product is specified, all products found on the media are selected for installation. For example: http://192.168.66.6/SLES10/sdk/CD1 http://192.168.66.6/SLES10/CD1/updates Besides the add_on_products file, you can use the AutoYaST profile to specify add-on products. For example: <add-on> <add_on_products config:type="list"> <listentry> <media_url>http://192.168.66.6/SLES10/CD1/updates</media_url> <product>SuSE-Linux-Updates</product> <product_dir>/</product_dir> <ask_on_error config:type="boolean">false</ask_on_error> <!-- available since openSUSE 11.0 --> <name>MyUpdates</name> <!-- available since openSUSE 11.1/SLES11 (bnc#433981) --> </listentry> </add_on_products> </add-on> With this entry in the AutoYaST profile, the add_on_products file is not necessary. Since openSUSE 11.0, AutoYaST can ask the user to make add-on products available instead of reporting a time-out error when an add-on product cannot be found at the given location. Set ask_on_error to "true" (the default is "false"). Then your add-on product can be on a different CD/DVD than the installation source. YaST checks the signatures of files on the installation source. If a content file is not signed, during a manual installation YaST asks the user what to do. During an automatic installation, the installation source is rejected silently.

If you want to use unsigned installation sources with AutoYaST, turn off the checks with the following configuration in your AutoYaST profile (part of the general section.

The following elements must be between the <general><signature-handling> ... </signature-handling></general> tags.

<accept_unsigned_file config:type="boolean"
>true</accept_unsigned_file>

<accept_file_without_checksum config:type="boolean"
>true</accept_file_without_checksum>

<accept_verification_failed config:type="boolean"
>true</accept_verification_failed>

<accept_unknown_gpg_key config:type="boolean"
>true</accept_unknown_gpg_key>

<accept_non_trusted_gpg_key config:type="boolean"
>true</accept_non_trusted_gpg_key>

<import_gpg_key config:type="boolean"
>true</import_gpg_key>

Since openSUSE 10.3, it is possible to configure the signature handling for each add-on product individually. The following elements must be between the <signature-handling> section of the individual add-on product.

<accept_unsigned_file config:type="boolean"
>true</accept_unsigned_file>

<accept_file_without_checksum config:type="boolean"
>true</accept_file_without_checksum>

<accept_verification_failed config:type="boolean"
>true</accept_verification_failed>

<accept_unknown_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </accept_unknown_gpg_key>

<accept_non_trusted_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </accept_non_trusted_gpg_key>

<import_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </import_gpg_key>

Kernel packages are not part of any selection. The required kernel is determined during installation. If the kernel package is added to any selection or to the individual package selection, installation will mostly fail due to conflicts.

To force the installation of a specific kernel, use the kernel property. The following is an example of forcing the installation of the default kernel. This kernel will be installed even if an SMP or other kernel is required.

  <software>        
    <kernel>kernel-default</kernel>
    <packages  config:type="list">
      <package>apache2</package>
    </packages>
  </software>

Some packages are selected automatically either because of a dependency or because it is available in a selection.

Removing such packages might break the system consistency and it is not recommended to remove basic packages unless a replacement which provides the same services is provided. The best example for this case are MTA packages. By default, postfix will be selected and installed. If you wish to use another MTA like sendmail, then postfix can be removed from the list of selected package using a list in the software resource. The following example shows how this can be done:

  <software>
    <packages  config:type="list">
      <package>sendmail</package>
    </packages>
    <remove-packages  config:type="list">
      <package>postfix</package>
    </remove-packages>
  </software>

If you want to install packages after the reboot during stage 2, instead of during the normal installation process in stage 1, you can use the post-packages element for that:

<software>
  <post-packages config:type="list">
    <package>yast2-cim</package>
  </post-packages>
</software>

Since SLES11 and openSUSE 11.1, you can also install patterns in stage 2. Use the post-patterns element for that:

<software>
  <post-patterns config:type="list">
    <pattern>apparmor</pattern>
  </post-patterns>
</software>

Since openSUSE 11.1, you can perform an online update at the end of the installation. Set the boolean do_online_update to "true". Of course this makes only sense if you add an online update repository in the suse-register/customer-center section, for example, or in a post-script. If the online update repository was available in stage 1 already via add-on section, then AutoYaST has already installed the latest packages available. If a kernel update is done via online-update, a reboot at the end of stage 2 is triggered.

<software>
  <do_online_update config:type="boolean">true</do_online_update>
</software>