SLES10 no longer supports selections but uses patterns now. Autoyast is not be able to convert selections into patterns and so you have to do that on your own. 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>

	  

As you can see, the packages section is still the same like on a SLES9. Just the addon and base is gone.

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

Since openSUSE 11.0 you can choose to use images during installation to speed up the installation. This is available in openSUSE 11.1 too. At then end, in the installed system, there is no difference visible if you did an image or a single RPM installation.

   <!-- 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 earlier versions, to install custom and external packages there is no need for a special resource in the control file. 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 required package database.

Creating a new package database is only needed if new RPMs (i.e. update RPMs) were added. To re-create the database, use the /usr/bin/create_package_descr command. For example, use this command line to create the package database. (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 
      

	Change starting from SUSE Linux 9.1/SLES 9
	To provide extra dependencies which can not be extracted from the rpm files, an extra file with missing dependencies is available in the directory suse/setup/descr. The file EXTRA_PROV can be used when recreating the package database using the -x option.

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 (i.e. from SuSE FTP server). Additionally this method makes the creation of custom CD-ROMs easier.

Change starting from SUSE Linux 10.1/SLES 10

With SLES10/SL10.1, the concept of adding own RPMs to an installation source has changed. The yast/order and yast/instorder is no longer supported. Neither by AutoYaST nor by YaST. To add own RPMs to an installation source (that includes add-on products like the SDK) you have to add a file add_on_products to the CD1 of the main product. media_url [path_on_media [product_1 [product_2 [....]]] media_url is URL of the media itself path_on_media is path of the catalog on the media. If not present, / (root) is assumed product_1 and following are the names for products, which should be marked for installation. If no product is mentioned, 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 that 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 that entry in the autoyast profile, the add_on_products file is not necessary. Since openSUSE 11.0 AutoYaST can ask the user to make the add-on available intead of reporting a timed out error when the add-on can't be found at the given location. Set ask_on_error to true for that (the default is false). Your add-on can be on a different CD/DVD than the installation source then. YaST checks the signatures of files on the installation source now. If a content file is not signed, during a manual installation YaST asks the user what to do. During an autoinstallation, the installation source gets rejected silently.

If you want to use unsigned installation sources with autoyast, you can turn of 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's possible to configure the signature handling for each add-on individually. The following elements must be between the <signature-handling> section of the individual add-on.

<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 forcing the installation of the default kernel. In this example this kernel will be installed in any case, 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 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 same services is provided. Best example for this case are MTA packages. By default, postfix will be selected and installed. If you wish however 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 install patterns in stage 2 too. 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 do an online update at the end of the installation with the boolean do_online_update. Of course that makes only sense if you add an online update repository with the suse-register/customer-center section for example or in a post-script. If the online update repository was available in stage1 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 stage2 is triggered.

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