Using the control file, multiple workflows can be defined for different modes and installation stages. Thus, the element workflows in the control file evaluates to a list of workflows.

Beside defining what YaST clients should be executed during installation, the workflow configuration also let you specify the wizard steps and how they should appear during graphical installation.

A workflow list element is a map with the following elements:

The following listing shows a typical installation workflow:

                <workflows config:type="list">
        <workflow>
            <!-- 'label' is what the user will see -->
	    <label>Base Installation</label>
            <!-- default settings for all modules -->
            <defaults>
                <!-- arguments for the clients -->
                <arguments>false,false</arguments>
                <!-- allowed architectures "all", "i386", "i386,ia64,x86_64"  -->
                <archs>all</archs>
            </defaults>
            <stage>initial</stage>
            <mode>installation,update</mode>
            <modules  config:type="list">
                <module>
                    <name>info</name>
                    <arguments>false,true</arguments>
                </module>
                <module>
                    <name>proposal</name>
                    <arguments>true,true,`ini</arguments>
	            <label>Installation Settings</label>
                </module>
                <module>
                    <name>do_resize</name>
                    <update config:type="boolean">false</update>
                    <archs>i386,x86_64,ia64</archs>
	            <label>Perform Installation</label>
                </module>
                <module>
                    <name>prepdisk</name>
                    <!-- Multiple modules with the same 'label' will be
                         collapsed to one single user-visible step.
                         The step is considered finished when the last module
                         with the same 'label' is finished.  -->
	            <label>Perform Installation</label>
                </module>
                <module>
                    <name>kickoff</name>
	            <label>Perform Installation</label>
                </module>
                <module>
                    <name>rpmcopy</name>
	            <label>Perform Installation</label>
                </module>
                <module>
                    <name>finish</name>
	            <label>Perform Installation</label>
                </module>
            </modules>
        </workflow>

            

Part of the installation workflows are proposal screens, which consists of group of related configuration settings. For example Network, Hardware and the initial Installation proposal.

If you with for some reason to add or modify a proposal, which is discourged because of configuration dependencies, then this would be possible using the control file.

            

        <proposal>
            <type>network</type>
            <stage>continue,normal</stage>
            <proposal_modules config:type="list">
                <proposal_module>lan</proposal_module>
                <proposal_module>dsl</proposal_module>
                <proposal_module>isdn</proposal_module>
                <proposal_module>modem</proposal_module>
                <proposal_module>proxy</proposal_module>
        <proposal_module>remote</proposal_module>
            </proposal_modules>
        </proposal>


            

The proposal in the above listing is displayed in the so called continue mode which is the second phase of the installation. The proposal consists of different configuration options which are controled using a special API.

Currently, proposals names and captions as fixed and cant be changed. It is not possible to create a special proposal screen, instead those available should be used: network, hardware, service.

In the workflow, the proposals are called as any workflow step with an additional argument identifying the proposal screen to be started. (`net for network, `hw for hardware and `service for service proposals. The following examples shows how the network proposal is called as a workflow step:

            

<module>
    <label>Network</label>
    <name>proposal</name>
    <arguments>true,true,`net</arguments>
</module>


            

It is possible to define some installation variables (language, timezone, keyboard,.. ) and force them in the proposal. User will still be able to change them however.

The following variables can be set:

the following example shows all options above

                

            

    <globals>
        <enable_autologin config:type="boolean">true</enable_autologin>
        <language>de_DE</language>
        <timezone>Canada/Eastern</timezone>
        <use_desktop_scheduler config:type="boolean">true</use_desktop_scheduler>
        <io_scheduler>as</io_scheduler>
    </globals>



            

Using this section in the control file you can change the software proposal during installation.

By default, the software proposal is generated depending on the available space in the system. If enough space is available, a fairly large selection of packages and add-on package groups is automatically selected. This behavior is controlled by the selection_type element in the control file.

The default value for the above element is auto. To force a selection which can not be changed by the user, the value fixed has to be used.

If a fixed software selection is desired, then the fixed selection name has to be specifed in the control file. This selection must be a base selection. To specify the name of the base selectiont to be forced, use the base_selection element.

The list of base selections can be found on the first CD of the product in the directory suse/setup/descr or by using the following command (The example shows the list of selections for SLES 9):

To switch from desktop based proposals to the normal behavior of software proposals in YaST , the software_proposal element has been introduced. Setting the value to desktop will make YaST show a dialog with Desktops to select from, i.e. KDE or Gnome. If this element is not defined, default behavior is assumed.

for i in `grep -l baseconf SUSE-SLES-Version-9/CD1/suse/setup/descr/* `; do 
  basename $i .sel; 
done

            

The above will have the following output:

Full-Installation
Minimal+X11
Minimal
default

            

which matches the base selections in SLES 9.

Additionally, you can configure how updating of packages should be performed. The following options are available:

If present, the partition proposal will be based on the data provided in the control file.

1.1.3.5.2. Configuration Options

The following elements are global to all disks and partitions:

prefer_remove

Possible values

true|false

Default value

true

Description

If set to false the partition suggestion tries to use gaps on the disks or to re-use existing partitions. If set to true then the partition suggestion prefers removal of existing partitions.

remove_special_partitions

Possible values

true|false

Default value

false

Description

If set to false YaST2 will not remove some special partitions (e.g. 0x12 Compaq diagnostics, 0xde Dell Utility) if they exists on the disk even if prefer_remove is set to true. If set to true YaST2 will remove even those special partitions.

	Caution
	Caution: Since some machines are not even bootable any more when these partitions are removed one should really know what he does when setting this to true

keep_partition_fsys

Possible values

comma separated list of reiser, xfs, fat, vfat, ext2, ext3, jfs, ntfs, swap

Default value

Empty list

Description

Partitions that contain filesystems in that list are not deleted even if prefer_remove is set to true.

keep_partition_id

Possible values

comma separated list of possible partition ids

Default value

Empty list

Description

Partitions that have a partition id that is contained in the list are not deleted even if prefer_remove is set to true.

keep_partition_num

Possible values

comma separated list of possible partition numbers

Default value

Empty list

Description

Partitions that have a partition number that is contained in the list are not deleted even if prefer_remove is set to true.

To configure individual partitions and disks, a list element is used with its items describing how should the partitions be created and configured

The attributes of such a partition are determined by several elements. These elements are described in more detail later.

	General remarks to all option values
	If there is a blank or a equal sign (=) contained in an option value, the values has to be surrounded by double quotes ("). Values that describe sizes can be followed by the letters K, M, G. (K means Kilobytes, M Megabytes and G Gigabytes).

mount

Example

<mount>swap</mount>

Description

This entry describes the mount point of the partition. For a swap partition the special value "swap" has to be used.

fsys

Example

<fsys>reiser</fsys>

Description

This entry describes the filesystem type created on this partition. Possible Filesystem types are: reiser, ext2, ext3, xfs, vfat, jfs, swap If no filesystem type is given for a partition, reiserfs is used.

formatopt

Example

<formatopt>reiser<formatopt>

Description

This entry describes the options given to the format command. Multiple options have to be separated by blanks. There must not be a blank between option letter and option value. This entry is optional.

fstopt

Example

<fstopt>acl,user_xattr<fstopt>

Description

This entry describes the options written to /etc/fstab. Multiple options have to be separated by comma. This entry is optional.

label

Example

<label>emil<label>

Description

If the filesystem can have a label, the value of the label is set to this value.

id

Example

<id>0x8E<id>

Description

This keyword makes it possible to create partitions with partition ide other than 0x83 (for normal filesystem partitions) or 0x82 (for swap partitions). This make it possible to create LVM or MD partitions on a disk.

size

Example

<size>2G<size>

Description

This keyword determines the size that is at least needed for a partition. A size value of zero means that YaST2 should try to make the partition as large as possible after all other demands regarding partition size are fulfilled. The special value of "auto" can be given for the /boot and swap partition. If auto is set for a /boot or swap partition YaST2 computes a suitable partition size by itself.

percent

Example

<percent>30<percent>

Description

This keyword determines that a partition should be allocated a certain percentage of the available space for installation on a disk.

maxsize

Example

<maxsize>4G<maxsize>

Description

This keyword limits the maximal amount of space that is allocated to a certain partition. This keyword is only useful in conjunction with a size specification by keyword "percent" or by an entry of "size=0".

increasable

Example

<increasable config:type="boolean">true<increasable>

Default

false

Description

After determining the optimal disk usage the partition may be increased if there is unallocated space in the same gap available. If this keyword is set, the partition may grow larger than specified by the maxsize and percent parameter. This keyword is intended to avoid having unallocated space on a disk after partitioning if possible.

disk

Example

<disk>2<disk>

Description

This keyword specifies which partitions should be placed on which disks if multiple disks are present in the system. All partitions with the same disk value will be placed on the same disk. The value after the keyword determines the priority of the partition group. Lower numbers mean higher priority. If there are not enough disks in the system a partition group with lower priority is assigned a separate disks before a partition group with higher priority. A partition without disk keyword is implicitly assigned the highest priority 0.

Example 1.1. Flexible Partitioning

If in the example below the machine has three disks then each of the partition groups gets on a separate disk. So one disk will hold /var, another disk will hold /home and another disk will hold /, /usr and /opt. If in the above example the machine has only two disks then /home will still be on a separate disk (since it has lower priority than the other partition groups) and /, /usr, /opt and /var will share the other disk.

If there is only one disk in the system of course all partitions will be on that disk. To make the flexible partitioning possible, use_flexible_partitioning option must be se to true and partitions must be surrounded with flexible_partitioning tag.

<partitioning>
    <use_flexible_partitioning config:type="boolean">true</use_flexible_partitioning>

    <flexible_partitioning>
        <partitions config:type="list">
            <partition>
                <disk config:type="integer">3</disk>
                <mount>/var</mount>
                <percent config:type="integer">100</percent>               
            </partition>
            <partition>
                <disk config:type="integer">2</disk>                                
                <mount>/</mount>
                <size>1G</size>
            </partition>
            <partition>
                <disk config:type="integer">2</disk>                                
                <mount>/usr</mount>
                <size>2G</size>
            </partition>
            <partition>
                <disk config:type="integer">2</disk>                                
                <mount>/opt</mount>
                <size>2G</size>
            </partition>
           <partition>
                <disk config:type="integer">1</disk>
                <mount>/home</mount>
                <percent config:type="integer">100</percent>               
            </partition>       
        </partitions>
    </flexible_partitioning>
</partitioning>

                    

A more complete example with other options is shown below:

<partitioning>
    <use_flexible_partitioning config:type="boolean">true</use_flexible_partitioning>

    <flexible_partitioning>
        <partitions config:type="list">
            <partition>
                <disk config:type="integer">2</disk>
                <mount>swap</mount>
                <size>auto</size>
            </partition>
            <partition>
                <disk config:type="integer">1</disk>
                <fstopt>defaults</fstopt>
                <fsys>reiser</fsys>
                <increasable config:type="boolean">true</increasable>
                <mount>/</mount>
                <size>2gb</size>
            </partition>
            <partition>
                <disk config:type="integer">2</disk>
                <fstopt>defaults,data=writeback,noatime</fstopt>
                <fsys>reiser</fsys>
                <increasable config:type="boolean">true</increasable>
                <mount>/var</mount>
                <percent config:type="integer">100</percent>
                <size>2gb</size>
            </partition>
        </partitions>
    </flexible_partitioning>

    <prefer_remove config:type="boolean">true</prefer_remove>
    <remove_special_partitions config:type="boolean">false</remove_special_partitions>
</partitioning>

                

It is possible to add hooks before and after any workflow step for further customization of the installed system and to to perform non-standard tasks during installation.

Two additional elements define custom script hooks:

Both script types accept two elements, the interpreter used (shell or perl) and the source of the scripts which is embedded in the XML file using CDATA sections to avoid confusion with the XML syntax. The following example shows how scripts can be embedded in the control file:

                
            
                <module>
                    <name>info</name>
                    <arguments>false,true</arguments>
                    <prescript>
                        <interpreter>shell</interpreter>
                        <source>
<![CDATA[#!/bin/sh
touch /tmp/anas
echo anas > /tmp/anas
]]>
                        </source>
                    </prescript>
                </module>