16 Deploying customized preinstallations #

By default, an installation of SUSE Linux Enterprise Desktop contains several default messages that are localized and displayed at certain stages of the installation process. These include a welcome message, a license message, and a congratulatory message at the end of installation. You can replace any of these with your own versions and include localized versions of them in the installation. To include your own welcome message, proceed as follows:

Proceed in a similar way to configure customized license and finish messages. These variables are FIRSTBOOT_LICENSE_DIR and FIRSTBOOT_FINISH_FILE.

Change the SHOW_Y2CC_CHECKBOX to “yes” if the user needs to be able to start YaST directly after performing the installation.

You can customize the way the installation system reacts to a user's refusal to accept the license agreement. There are three different ways in which the system could react to this scenario:

Make your choice and set LICENSE_REFUSAL_ACTION to the appropriate value.

Depending on whether you have changed the instance of SUSE Linux Enterprise Desktop you are deploying with firstboot, you might need to educate the end users about important aspects of their new operating system. A standard installation uses release notes (displayed during one of the final stages of the installation) to provide important information to the users. To have your own modified release notes displayed as part of a firstboot installation, proceed as follows:

The provided /etc/YaST2/firstboot.xml example defines a standard workflow which includes the following enabled components:

Bear in mind that this workflow is a template. You can adjust it properly by manually editing the firstboot configuration file /etc/YaST2/firstboot.xml. This XML file is a subset of the standard control.xml file that is used by YaST to control the installation workflow. See Example 16.2, “Configuring the workflow section” to learn more about how to configure the workflow section.

For an overview of proposals, see Example 16.1, “Configuring the proposal screens”. This provides you with enough background to modify the firstboot installation workflow. The basic syntax of the firstboot configuration file (plus how the key elements are configured) is explained via this example.

    …
    <proposals config:type="list">1
        <proposal>2
            <name>firstboot_hardware</name>3
            <mode>installation</mode>4
            <stage>firstboot</stage>5
            <label>Hardware Configuration</label>6
            <proposal_modules config:type="list">7
                <proposal_module>printer</proposal_module>8
            </proposal_modules>
        </proposal>
        <proposal>
        …
        </proposal>
    </proposals>

The next section of the firstboot configuration file consists of the workflow definition. All modules that should be part of the firstboot installation workflow must be listed here.

    <workflows  config:type="list">
        <workflow>
            <defaults>
                <enable_back>yes</enable_back>
                <enable_next>yes</enable_next>
                <archs>all</archs>
            </defaults>
            <stage>firstboot</stage>
            <label>Configuration</label>
            <mode>installation</mode>
            … <!–– list of modules  ––>
            </modules>
        </workflow>
    </workflows>
    …

The overall structure of the workflows section is very similar to that of the proposals section. A container holds the workflow elements and the workflow elements all include stage, label and mode information (just as the proposals introduced in Example 16.1, “Configuring the proposal screens”). The most notable difference is the defaults section, which contains basic design information for the workflow components:

    <modules  config:type="list">1
        <module>2
            <label>Language</label>3
            <enabled config:type="boolean">false</enabled>4
            <name>firstboot_language</name>5
        </module>
    <modules>

To make changes to the number or order of proposal screens during the firstboot installation, proceed as follows:

You can always change the workflow of the configuration steps if the default does not meet your needs. Enable or disable certain modules in the workflow (or add your own custom ones).

To toggle the status of a module in the firstboot workflow, proceed as follows:

To add a custom made module to the workflow, proceed as follows:

Tip: Finding connected network interface for auto-configuration

If the target hardware could feature more than one network interface, add the network-autoconfig package to the application image. network-autoconfig cycles through all available Ethernet interfaces until one is successfully configured via DHCP.

Firstboot can be configured to execute additional scripts after the firstboot workflow has been completed. To add additional scripts to the firstboot sequence, proceed as follows:

Depending on the end user it could be desirable to offer translations of the customized workflow. Those translations could be necessary if you customized the workflow by changing the /etc/YaST2/firstboot.xml file, as described in Section 16.2.4, “Customizing the workflow”.

If you have changed /etc/YaST2/firstboot.xml and introduced string changes, generate a new translation template file (.pot file) and use the gettext toolchain to translate and finally install the translated files in the YaST locale directories (/usr/share/YaST2/locale) as compiled .mo files. Proceed as follows:

If you need translations for additional or changed YaST modules, provide translations within such a module itself. If you changed an existing module, make sure to change also its text-domain statement to avoid undesired side effects.

Tip: More information

For more information about YaST development, refer to https://en.opensuse.org/openSUSE:YaST_development. Detailed information about YaST firstboot can be found at https://doc.opensuse.org/projects/YaST/SLES11/tdg/bk09ch01s02.html.