Jump to content
documentation.suse.com / Deployment Guide
SUSE Linux Enterprise Desktop 15 SP6

Deployment Guide

This guide details how to install single or multiple systems, and how to exploit the product-inherent capabilities for a deployment infrastructure.

Publication Date: December 05, 2024

Copyright © 2006–2024 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled GNU Free Documentation License.

For SUSE trademarks, see https://www.suse.com/company/legal/. All third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.

Preface

1 Available documentation

Online documentation

Our documentation is available online at https://documentation.suse.com. Browse or download the documentation in various formats.

Note
Note: Latest updates

The latest updates are usually available in the English-language version of this documentation.

SUSE Knowledgebase

If you run into an issue, check out the Technical Information Documents (TIDs) that are available online at https://www.suse.com/support/kb/. Search the SUSE Knowledgebase for known solutions driven by customer need.

Release notes

For release notes, see https://www.suse.com/releasenotes/.

In your system

For offline use, the release notes are also available under /usr/share/doc/release-notes on your system. The documentation for individual packages is available at /usr/share/doc/packages.

Many commands are also described in their manual pages. To view them, run man, followed by a specific command name. If the man command is not installed on your system, install it with sudo zypper install man.

2 Improving the documentation

Your feedback and contributions to this documentation are welcome. The following channels for giving feedback are available:

Service requests and support

For services and support options available for your product, see https://www.suse.com/support/.

To open a service request, you need a SUSE subscription registered at SUSE Customer Center. Go to https://scc.suse.com/support/requests, log in, and click Create New.

Bug reports

Report issues with the documentation at https://bugzilla.suse.com/.

To simplify this process, click the Report an issue icon next to a headline in the HTML version of this document. This preselects the right product and category in Bugzilla and adds a link to the current section. You can start typing your bug report right away.

A Bugzilla account is required.

Contributions

To contribute to this documentation, click the Edit source document icon next to a headline in the HTML version of this document. This will take you to the source code on GitHub, where you can open a pull request.

A GitHub account is required.

Note
Note: Edit source document only available for English

The Edit source document icons are only available for the English version of each document. For all other languages, use the Report an issue icons instead.

For more information about the documentation environment used for this documentation, see the repository's README.

Mail

You can also report errors and send feedback concerning the documentation to <>. Include the document title, the product version, and the publication date of the document. Additionally, include the relevant section number and title (or provide the URL) and provide a concise description of the problem.

3 Documentation conventions

The following notices and typographic conventions are used in this document:

  • /etc/passwd: Directory names and file names

  • PLACEHOLDER: Replace PLACEHOLDER with the actual value

  • PATH: An environment variable

  • ls, --help: Commands, options, and parameters

  • user: The name of a user or group

  • package_name: The name of a software package

  • Alt, AltF1: A key to press or a key combination. Keys are shown in uppercase as on a keyboard.

  • File, File › Save As: menu items, buttons

  • Chapter 1, Example chapter: A cross-reference to another chapter in this guide.

  • Commands that must be run with root privileges. You can also prefix these commands with the sudo command to run them as a non-privileged user:

    # command
    > sudo command
  • Commands that can be run by non-privileged users:

    > command
  • Commands can be split into two or multiple lines by a backslash character (\) at the end of a line. The backslash informs the shell that the command invocation will continue after the end of the line:

    > echo a b \
    c d
  • A code block that shows both the command (preceded by a prompt) and the respective output returned by the shell:

    > command
    output
  • Notices

    Warning
    Warning: Warning notice

    Vital information you must be aware of before proceeding. Warns you about security issues, potential loss of data, damage to hardware, or physical hazards.

    Important
    Important: Important notice

    Important information you should be aware of before proceeding.

    Note
    Note: Note notice

    Additional information, for example about differences in software versions.

    Tip
    Tip: Tip notice

    Helpful information, like a guideline or a piece of practical advice.

  • Compact Notices

    Note

    Additional information, for example about differences in software versions.

    Tip

    Helpful information, like a guideline or a piece of practical advice.

4 Support

Find the support statement for SUSE Linux Enterprise Desktop and general information about technology previews below. For details about the product lifecycle, see https://www.suse.com/lifecycle.

If you are entitled to support, find details on how to collect information for a support ticket at https://documentation.suse.com/sles-15/html/SLES-all/cha-adm-support.html.

4.1 Support statement for SUSE Linux Enterprise Desktop

To receive support, you need an appropriate subscription with SUSE. To view the specific support offers available to you, go to https://www.suse.com/support/ and select your product.

The support levels are defined as follows:

L1

Problem determination, which means technical support designed to provide compatibility information, usage support, ongoing maintenance, information gathering and basic troubleshooting using available documentation.

L2

Problem isolation, which means technical support designed to analyze data, reproduce customer problems, isolate a problem area and provide a resolution for problems not resolved by Level 1 or prepare for Level 3.

L3

Problem resolution, which means technical support designed to resolve problems by engaging engineering to resolve product defects which have been identified by Level 2 Support.

For contracted customers and partners, SUSE Linux Enterprise Desktop is delivered with L3 support for all packages, except for the following:

  • Technology previews.

  • Sound, graphics, fonts, and artwork.

  • Packages that require an additional customer contract.

  • Packages with names ending in -devel (containing header files and similar developer resources) will only be supported together with their main packages.

SUSE will only support the usage of original packages. That is, packages that are unchanged and not recompiled.

4.2 Technology previews

Technology previews are packages, stacks, or features delivered by SUSE to provide glimpses into upcoming innovations. Technology previews are included for your convenience to give you a chance to test new technologies within your environment. We would appreciate your feedback. If you test a technology preview, please contact your SUSE representative and let them know about your experience and use cases. Your input is helpful for future development.

Technology previews have the following limitations:

  • Technology previews are still in development. Therefore, they may be functionally incomplete, unstable, or otherwise not suitable for production use.

  • Technology previews are not supported.

  • Technology previews may only be available for specific hardware architectures.

  • Details and functionality of technology previews are subject to change. As a result, upgrading to subsequent releases of a technology preview may be impossible and require a fresh installation.

  • SUSE may discover that a preview does not meet customer or market needs, or does not comply with enterprise standards. Technology previews can be removed from a product at any time. SUSE does not commit to providing a supported version of such technologies in the future.

For an overview of technology previews shipped with your product, see the release notes at https://www.suse.com/releasenotes.

Part I Installation preparation

  • 1 Planning for SUSE Linux Enterprise Desktop
  • This chapter describes some basic considerations before installing SUSE Linux Enterprise Desktop.

  • 2 Installation on AMD64 and Intel 64
  • This chapter describes the steps necessary to prepare for the installation of SUSE Linux Enterprise Desktop on AMD64 and Intel 64 computers. It introduces the steps required to prepare for various installation methods. The list of hardware requirements provides an overview of systems supported by SUSE Linux Enterprise Desktop. Find information about available installation methods and several commonly known problems. Also learn how to control the installation, provide installation media, and boot with regular methods.

  • 3 Installation on virtualization hosts
  • This section describes the support status of SUSE Linux Enterprise Desktop 15 SP6 running as a guest operating system on top of different virtualization hosts (hypervisors).

1 Planning for SUSE Linux Enterprise Desktop

This chapter describes some basic considerations before installing SUSE Linux Enterprise Desktop.

This chapter is addressed mainly to corporate system administrators who face the task of having to deploy SUSE® Linux Enterprise Desktop at their site. Rolling out SUSE Linux Enterprise Desktop to an entire site should involve careful planning and consideration of the following questions:

For which purpose will the SUSE Linux Enterprise Desktop workstations be used?

Determine the purpose for which SUSE Linux Enterprise Desktop should be used and make sure that hardware and software with the ability to match these requirements are used. Consider testing your setup on a single machine before rolling it out to the entire site.

How many workstations should be installed?

Determine the scope of your deployment of SUSE Linux Enterprise Desktop. Depending on the number of installations planned, consider different approaches to the installation or even a mass installation using SUSE Linux Enterprises unique AutoYaST or KIWI NG technology.

How do you get software updates for your deployment?

All patches provided by SUSE for your product are available for download to registered users in the SUSE Customer Center.

Do you need help for your local deployment?

SUSE provides training, support, and consulting for all topics pertaining to SUSE Linux Enterprise Desktop. Find more information about this at https://www.suse.com/products/desktop/.

Note
Note: Terminology

In the following sections, the system to hold your new SUSE Linux Enterprise Desktop installation is called target system or installation target. The term repository (previously called installation source) is used for all sources of installation data. This includes physical media, such as CD and DVD, and network servers distributing the installation data in your network.

1.1 Hardware requirements

For a standard installation of SUSE Linux Enterprise Desktop, including the desktop environment and a wealth of applications, the following configuration is recommended:

  • Intel Pentium IV, 2.4 GHz or higher or any AMD64 or Intel 64 processor

  • 1–2 physical CPUs

  • 512 MB physical RAM or higher

  • 3 GB of available disk space or more

  • 1024 x 768 display resolution (or higher)

1.2 Reasons to use SUSE Linux Enterprise Desktop

Let the following items guide you in your selection of SUSE Linux Enterprise Desktop and determining the purpose of the installed systems:

Wealth of applications

SUSE Linux Enterprise Desktop's broad offer of software makes it appeal to both professional users in a corporate environment and to home users or users in smaller networks.

Ease of use

SUSE Linux Enterprise Desktop comes with the enterprise-ready desktop environment GNOME. It enables users to comfortably adjust to a Linux system while maintaining their efficiency and productivity. To explore GNOME in detail, refer to the Book “GNOME User Guide”.

Support for mobile users

With the NetworkManager technology fully integrated into SUSE Linux Enterprise Desktop and its two desktop environments, mobile users will enjoy the freedom of easily joining and switching wired and wireless networks.

Seamless integration into existing networks

SUSE Linux Enterprise Desktop was designed to be a versatile network citizen. It cooperates with various different network types:

Pure Linux networks.  SUSE Linux Enterprise Desktop is a complete Linux client and supports all the protocols used in traditional Linux and Unix* environments. It integrates well with networks consisting of other SUSE Linux or SUSE Linux Enterprise machines. LDAP, NIS, and local authentication are supported.

Windows networks.  SUSE Linux Enterprise Desktop supports Active Directory as an authentication source. It offers you all the advantages of a secure and stable Linux operating system plus convenient interaction with other Windows clients, as well as the means to manipulate your Windows user data from a Linux client. Explore this feature in detail in Book “Security and Hardening Guide”, Chapter 7 “Active Directory support”.

Application security with AppArmor

SUSE Linux Enterprise Desktop enables you to secure your applications by enforcing security profiles tailor-made for your applications. To learn more about AppArmor, refer to Book “Security and Hardening Guide”.

2 Installation on AMD64 and Intel 64

This chapter describes the steps necessary to prepare for the installation of SUSE Linux Enterprise Desktop on AMD64 and Intel 64 computers. It introduces the steps required to prepare for various installation methods. The list of hardware requirements provides an overview of systems supported by SUSE Linux Enterprise Desktop. Find information about available installation methods and several commonly known problems. Also learn how to control the installation, provide installation media, and boot with regular methods.

2.1 Hardware requirements

The SUSE® Linux Enterprise Server operating system can be deployed on a wide range of hardware. It is impossible to list all the different combinations of hardware SUSE Linux Enterprise Server supports. However, to provide you with a guide to help you during the planning phase, the minimum requirements are presented here.

If you want to be sure that a given computer configuration will work, find out which platforms have been certified by SUSE. Find a list at https://www.suse.com/yessearch/.

CPU

Most CPUs available at the time of release are supported.

Maximum number of CPUs

The maximum number of CPUs supported by software design is 8192 for Intel 64 and AMD64. If you plan to use such a large system, verify with our hardware system certification Web page for supported devices, see https://www.suse.com/yessearch/.

Memory requirements

A minimum of 1024 MB of memory is required for a minimal installation. On machines with more than two processors, add 512 MB per CPU. For remote installations via HTTP or FTP, add another 150 MB. Note that these values are only valid for the installation of the operating system—the actual memory requirement in production depends on the system's workload. For systems running the GNOME desktop environment, a minimum of 2048 MB of memory is required and 4096  MB is recommended.

Hard disk requirements

The disk requirements depend largely on the installation selected and how you use your machine. Commonly, you need more space than the installation software itself needs to have a system that works properly. Minimum requirements for different selections are:

Installation Scope

Minimum Hard Disk Requirements

Text Mode

1.5 GB

Minimal System

2.5 GB

GNOME Desktop

3 GB

All patterns

4 GB

Recommended Minimum (no Btrfs snapshots): 10 GB

Required Minimum (with Btrfs snapshots): 16 GB

Recommended Minimum (with Btrfs snapshots): 32 GB

If your root partition is smaller than 10 GB, the installer will not make an automated partitioning proposal and you need to manually create partitions. Therefore the recommended minimum size for the root partition is 10 GB. If you want to enable Btrfs snapshots on the root volume to enable system rollbacks the minimum size for the root partition is 16 GB.

Boot methods

The computer can be booted from a CD or a network. A special boot server is required to boot over the network. This can be set up with SUSE Linux Enterprise Server.

2.2 Installation considerations

This section encompasses many factors that need to be considered before installing SUSE Linux Enterprise Desktop on AMD64 and Intel 64 hardware.

2.2.1 Installation on hardware or virtual machine

SUSE Linux Enterprise Desktop is normally installed as an independent operating system. With virtualization it is also possible to run multiple instances of on the same hardware.

2.2.2 Installation target

Most installations are to a local hard disk. Therefore, it is necessary for the hard disk controllers to be available to the installation system. If a special controller (like a RAID controller) needs an extra kernel module, provide a kernel module update disk to the installation system.

Other installation targets may be various types of block devices that provide sufficient disk space and speed to run an operating system. This includes network block devices like iSCSI or SAN. It is also possible to install on network file systems that offer the standard Unix permissions. However, it may be problematic to boot these, because they must be supported by the initramfs before the actual system can start. Such installations can be useful when you need to start the same system in different locations or you plan to use virtualization features like domain migration.

2.3 Installation methods

You can choose the desired installation method by booting the setup with one of the options listed in Section 2.4, “Booting the system”. To enable the additional installation methods, refer to Section 4.3.4, “Specifying remote access”. For information about how to use remote installation methods, refer to Chapter 8, Remote installation.

A brief overview of the different methods:

Local with monitor and keyboard

This is the method most frequently used to install SUSE Linux Enterprise Desktop. This also requires very little preparation but needs a lot of direct interaction.

Remote via SSH

You can perform installation via SSH either in text mode or use X-forwarding for a graphical installation. For details, refer to Section 8.4, “Monitoring installation via SSH”.

Remote via serial console

For this installation method, you need a second computer connected via a null modem cable to the target computer. The installation is done in text mode. For details, refer to Section 8.5, “Installation via serial console”.

Remote via VNC

Use this method to perform the installation using a graphical interface without direct access to the target machine. For details, refer to Section 8.3, “Monitoring installation via VNC”.

2.4 Booting the system

This section gives an overview of the steps required for the complete installation of SUSE® Linux Enterprise Desktop.

For a full description of how to install and configure the system with YaST, refer to .

  1. Prepare the installation media.

    USB Flash Drive

    This is the simplest way to start the installation. To create a bootable flash disk, you need to copy a DVD image to the device using the dd command. The flash disk must not be mounted, and all data on the device will be erased.

    # dd if=PATH_TO_ISO_IMAGE of=USB_STORAGE_DEVICE bs=4M
    Network booting

    If the target computer's firmware supports it, you can boot the computer from the network and install from a server. This booting method requires a boot server that provides the needed boot images over the network. The exact protocol depends on your hardware. Commonly you need several services, such as TFTP and DHCP or PXE boot.

    It is possible to install from many common network protocols, such as NFS, HTTP, FTP, or SMB. For more information on how to perform such an installation, refer to Chapter 8, Remote installation.

  2. Configure the target system firmware to boot the medium you chose. Refer to the documentation of your hardware vendor about how to configure the correct boot order.

  3. Set the boot parameters required for your installation control method. An overview of the different methods is provided in Section 2.3, “Installation methods”. A list of boot parameters is available in Chapter 4, Boot parameters.

  4. Perform the installation as described in Chapter 5, Installation steps. The system needs to restart after the installation is finished.

  5. Optional: Change the boot order of the system to directly boot from the medium to which SUSE Linux Enterprise Desktop has been installed. If the system boots from the installation medium, the first boot parameter will be to boot the installed system.

2.5 Dealing with boot and installation problems

Prior to delivery, SUSE® Linux Enterprise Desktop is subjected to an extensive test program. Despite this, problems occasionally occur during boot or installation.

2.5.1 Problems booting

Boot problems may prevent the YaST installer from starting on your system. Another symptom is when your system does not boot after the installation has been completed.

System does not boot from installation media

Change your computer's firmware or BIOS so that the boot sequence is correct. To do this, consult the manual for your hardware.

The computer hangs

Change the console on your computer so that the kernel outputs are visible. Be sure to check the last outputs. This is normally done by pressing CtrlAltF10. If you cannot resolve the problem, consult the SUSE Linux Enterprise Desktop support staff. To log all system messages at boot time, use a serial connection as described in Section 2.3, “Installation methods”.

Boot disk

The boot disk is a useful interim solution if you have difficulties setting the other configurations or if you want to postpone the decision regarding the final boot mechanism. For more details on creating boot disks, see Book “Administration Guide”, Chapter 18 “The boot loader GRUB 2” grub2-mkrescue.

Virus warning after installation

There are BIOS variants that check the structure of the boot sector (MBR) and erroneously display a virus warning after the installation of GRUB 2. Solve this problem by entering the BIOS and looking for corresponding adjustable settings. For example, switch off virus protection. You can switch this option back on again later. It is unnecessary, however, if Linux is the only operating system you use.

2.5.2 Problems installing

If an unexpected problem occurs during installation, information is needed to determine the cause of the problem. Use the following directions to help with troubleshooting:

  • Check the outputs on the various consoles. You can switch consoles with the key combination CtrlAltFn. For example, obtain a shell in which to execute various commands by pressing CtrlAltF2.

  • Try launching the installation with Safe Settings (press F5 on the installation screen and choose Safe Settings). If the installation works without problems in this case, there is an incompatibility that causes either ACPI or APIC to fail. In some cases, a BIOS or firmware update fixes this problem.

  • Check the system messages on a console in the installation system by entering the command dmesg -T.

2.5.3 Initiating installation instead of booting

The default option in the boot menu of the installation source for SUSE Linux Enterprise Desktop boots the machine into the already installed system. To avoid this and to initiate the installation process instead, choose one of the available installation options in the boot menu.

3 Installation on virtualization hosts

This section describes the support status of SUSE Linux Enterprise Desktop 15 SP6 running as a guest operating system on top of different virtualization hosts (hypervisors).

Table 3.1: The following SUSE host environments are supported

SUSE Linux Enterprise Server

Hypervisors

SUSE Linux Enterprise Server 11 SP4

Xen and KVM

SUSE Linux Enterprise Server 12 SP1 to SP5

Xen and KVM

SUSE Linux Enterprise Server 15 GA to SP6

Xen and KVM

You can also search in the SUSE YES certification database

The level of support is as follows
  • Support for SUSE host operating systems is full L3 (both for the guest and host) according to the respective product life cycle.

  • SUSE provides full L3 support for SUSE Linux Enterprise Desktop guests within third-party host environments.

  • Support for the host and cooperation with SUSE Linux Enterprise Desktop guests must be provided by the host system's vendor.

Part II Installation procedure

  • 4 Boot parameters
  • SUSE Linux Enterprise Desktop allows setting several parameters during boot, for example choosing the source of the installation data or setting the network configuration.

  • 5 Installation steps
  • This chapter describes the procedure in which the data for SUSE Linux Enterprise Desktop is copied to the target device. Some basic configuration parameters for the newly installed system are set during the procedure. A graphical user interface will guide you through the installation. The procedure described in the following also applies to remote installation procedures as described in Chapter 8, Remote installation. The text mode installation has the same steps and only looks different.

  • 6 Registering SUSE Linux Enterprise and managing modules/extensions
  • To get technical support and product updates, you need to register and activate SUSE Linux Enterprise Desktop with the SUSE Customer Center. It is recommended to register during the installation, since this will enable you to install the system with the latest updates and patches available. However, if you are offline or want to skip the registration step, you can register at any time later from the installed system.

    Modules and extensions add features to your system and allow you to customize the system according to your needs. These components also need to be registered and can be managed with YaST or command line tools. For more details also refer to the Article “Modules and Extensions Quick Start”.

  • 7 Expert Partitioner
  • Sophisticated system configurations require specific disk setups. You can perform all common partitioning tasks during the installation.

  • 8 Remote installation
  • The installation of SUSE® Linux Enterprise Desktop can be performed entirely over the network. This chapter describes how to provide the required environment for booting, installing and controlling the installation via the network.

  • 9 Troubleshooting
  • This section covers several common installation problems and describes possible solutions.

4 Boot parameters

SUSE Linux Enterprise Desktop allows setting several parameters during boot, for example choosing the source of the installation data or setting the network configuration.

Using the appropriate set of boot parameters helps simplify your installation procedure. Many parameters can also be configured later using the linuxrc routines, but using the boot parameters is easier. In some automated setups, the boot parameters can be provided with initrd or an info file.

The way the system is started for the installation depends on the architecture—system start-up is different for PC (AMD64/Intel 64) or mainframe, for example. If you install SUSE Linux Enterprise Desktop as a VM Guest on a KVM or Xen hypervisor, follow the instructions for the AMD64/Intel 64 architecture.

Note
Note: Boot options and boot parameters

The terms Boot Parameters and Boot Options are often used interchangeably. In this documentation, we mostly use the term Boot Parameters.

4.1 Using the default boot parameters

The boot parameters are described in detail in Chapter 5, Installation steps. Generally, selecting Installation starts the installation boot process.

If problems occur, use Installation—ACPI Disabled or Installation—Safe Settings. For more information about troubleshooting the installation process, refer to Chapter 9, Troubleshooting.

The menu bar at the bottom of the screen offers some advanced functionality needed in some setups. Using the function keys (F1 ... F12), you can specify additional options to pass to the installation routines without having to know the detailed syntax of these parameters (see Chapter 4, Boot parameters). A detailed description of the available function keys is available in Section 4.2.1, “The boot screen on machines with traditional BIOS”.

4.2 PC (AMD64/Intel 64/AArch64)

This section describes changing the boot parameters for AMD64, Intel 64 and AArch64.

4.2.1 The boot screen on machines with traditional BIOS

The boot screen displays several options for the installation procedure. Boot from Hard Disk boots the installed system and is selected by default. Select one of the other options with the arrow keys and press Enter to boot it. The relevant options are:

Installation

The normal installation mode. All modern hardware functions are enabled. In case the installation fails, see F5Kernel for boot parameters that disable potentially problematic functions.

Upgrade

Perform a system upgrade. For more information refer to Book “Upgrade Guide”, Chapter 2 “Upgrade paths and methods”.

More › Rescue System

Starts a minimal Linux system without a graphical user interface. For more information, see Book “Administration Guide”, Chapter 42 “Common problems and their solutions”, Section 42.5.2 “Using the rescue system”.

More › Boot Linux System

Boot a Linux system that is already installed. You will be asked from which partition to boot the system.

More › Check Installation Media

This option is only available when you install from media created from downloaded ISOs. In this case it is recommended to check the integrity of the installation medium. This option starts the installation system before automatically checking the media. In case the check was successful, the normal installation routine starts. If a corrupt media is detected, the installation routine aborts. Replace the broken medium and restart the installation process.

More › Memory Test

Tests your system RAM using repeated read and write cycles. Terminate the test by rebooting. For more information, see Section 9.4, “Boot failure”. This option is not available on the live CDs.

The Boot Screen on Machines with a Traditional BIOS
Figure 4.1: The boot screen on machines with a traditional BIOS

Use the function keys shown at the bottom of the screen to change the language, screen resolution, installation source or to add an additional driver from your hardware vendor:

F1Help

Get context-sensitive help for the active element of the boot screen. Use the arrow keys to navigate, Enter to follow a link, and Esc to leave the help screen.

F2Language

Select the display language and a corresponding keyboard layout for the installation. The default language is English (US).

F3Video Mode

Select various graphical display modes for the installation. By Default the video resolution is automatically determined using KMS (Kernel Mode Setting). If this setting does not work on your system, choose No KMS and, optionally, specify vga=ask on the boot command line to get prompted for the video resolution. Choose Text Mode if the graphical installation causes problems.

F4Source

Normally, the installation is performed from the inserted installation medium. Here, select other sources, like FTP or NFS servers, or configure a proxy server. If the installation is deployed on a network with an SLP server, select an installation source available on the server with this option. Find information about setting up an installation server with SLP at Chapter 13, Setting up a network installation source.

F5Kernel

If you encounter problems with the regular installation, this menu offers to disable a few potentially problematic functions. If your hardware does not support ACPI (advanced configuration and power interface) select No ACPI to install without ACPI support. No local APIC disables support for APIC (Advanced Programmable Interrupt Controllers) which may cause problems with some hardware. Safe Settings boots the system with the DMA mode (for CD/DVD-ROM drives) and power management functions disabled.

If you are not sure, try the following options first: Installation—ACPI Disabled or Installation—Safe Settings. Experts can also use the command line (Boot Options) to enter or change kernel parameters.

F6Driver

Press this key to notify the system that you have an optional driver update for SUSE Linux Enterprise Desktop. With File or URL, load drivers directly before the installation starts. If you select Yes, you are prompted to insert the update disk at the appropriate point in the installation process.

Tip
Tip: Getting driver update disks

Driver updates for SUSE Linux Enterprise are provided at https://drivers.suse.com/. These drivers have been created via the SUSE SolidDriver Program.

4.2.2 The boot screen on machines equipped with UEFI

UEFI (Unified Extensible Firmware Interface) is a new industry standard which replaces and extends the traditional BIOS. The latest UEFI implementations contain the Secure Boot extension, which prevents booting malicious code by only allowing signed boot loaders to be executed. See Book “Administration Guide”, Chapter 17 “UEFI (Unified Extensible Firmware Interface)” for more information.

The boot manager GRUB 2, used to boot machines with a traditional BIOS, does not support UEFI, therefore GRUB 2 is replaced with GRUB 2 for EFI. If Secure Boot is enabled, YaST will automatically select GRUB 2 for EFI for installation. From an administrative and user perspective, both boot manager implementations behave the same and are called GRUB 2 in the following.

Tip
Tip: Using additional drivers with Secure Boot

When installing with Secure Boot enabled, you cannot load drivers that are not shipped with SUSE Linux Enterprise Desktop. This is also true of drivers shipped via SolidDriver, because their signing key is not trusted by default.

To load drivers not shipped with SUSE Linux Enterprise Desktop, do either of the following:

  • Before the installation, add the needed keys to the firmware database via firmware/system management tools.

  • Use a bootable ISO that will enroll the needed keys in the MOK list on the first boot.

For more information, see Book “Administration Guide”, Chapter 17 “UEFI (Unified Extensible Firmware Interface)”, Section 17.1 “Secure boot”.

The boot screen displays several options for the installation procedure. Change the selected option with the arrow keys and press Enter to boot it. The relevant options are:

Installation

The normal installation mode. All modern hardware functions are enabled. In case the installation fails, see F5Kernel for boot parameters that disable potentially problematic functions.

Upgrade

Perform a system upgrade. For more information refer to Book “Upgrade Guide”, Chapter 2 “Upgrade paths and methods”.

More › Rescue System

Starts a minimal Linux system without a graphical user interface. For more information, see Book “Administration Guide”, Chapter 42 “Common problems and their solutions”, Section 42.5.2 “Using the rescue system”.

More › Boot Linux System

Boot a Linux system that is already installed. You will be asked from which partition to boot the system.

More › Check Installation Media

This option is only available when you install from media created from downloaded ISOs. In this case it is recommended to check the integrity of the installation medium. This option starts the installation system before automatically checking the media. In case the check was successful, the normal installation routine starts. If a corrupt media is detected, the installation routine aborts.

The Boot Screen on Machines with UEFI
Figure 4.2: The boot screen on machines with UEFI

GRUB 2 for EFI on SUSE Linux Enterprise Desktop does not support a boot prompt or function keys for adding boot parameters. By default, the installation will be started with American English and the boot media as the installation source. A DHCP lookup will be performed to configure the network. To change these defaults or to add boot parameters you need to edit the respective boot entry. Highlight it using the arrow keys and press E. See the on-screen help for editing hints (note that only an English keyboard is available now). The Installation entry will look similar to the following:

setparams 'Installation'

   set gfxpayload=keep
   echo 'Loading kernel ...'
   linuxefi /boot/x86_64/loader/linux splash=silent
   echo 'Loading initial ramdisk ...'
   initrdefi /boot/x86_64/loader/initrd

Add space-separated parameters to the end of the line starting with linuxefi. To boot the edited entry, press F10. If you access the machine via serial console, press Esc0. A complete list of parameters is available at https://en.opensuse.org/Linuxrc.

4.3 List of important boot parameters

This section contains a selection of important boot parameters.

4.3.1 General boot parameters

autoyast=URL

The autoyast parameter specifies the location of the autoinst.xml control file for automatic installation.

manual=<0|1>

The manual parameter controls whether the other parameters are only default values that still must be acknowledged by the user. Set this parameter to 0 if all values should be accepted and no questions asked. Setting autoyast implies setting manual to 0.

Info=URL

Specifies a location for a file from which to read additional options.

upgrade=<0|1>

To upgrade SUSE Linux Enterprise Desktop, specify Upgrade=1.

dud=URL

Load driver updates from URL.

Set dud=ftp://ftp.example.com/PATH_TO_DRIVER or dud=http://www.example.com/PATH_TO_DRIVER to load drivers from a URL. When dud=1 you will be asked for the URL during boot.

language=LANGUAGE

Set the installation language. Some supported values are cs_CZ, de_DE, es_ES, fr_FR, ja_JP, pt_BR, pt_PT, ru_RU, zh_CN, and zh_TW.

acpi=off

Disable ACPI support.

noapic

No logical APIC.

nomodeset

Disable KMS.

textmode=1

Start installer in text mode.

console=SERIAL_DEVICE[,MODE]

SERIAL_DEVICE can be an actual serial or parallel device (for example ttyS0) or a virtual terminal (for example tty1). MODE is the baud rate, parity and stop bit (for example 9600n8). The default for this setting is set by the mainboard firmware. If you do not see output on your monitor, try setting console=tty1. It is possible to define multiple devices.

4.3.2 Configuring the network interface

Important
Important: Configuring the network interface

The settings discussed in this section apply only to the network interface used during installation. Configure additional network interfaces in the installed system by following the instructions in Book “Administration Guide”, Chapter 23 “Basic networking”, Section 23.6 “Configuring a network connection manually”.

The network will only be configured if it is required during the installation. To force the network to be configured, use the netsetup or ifcfg parameters.

netsetup=VALUE

netsetup=dhcp forces a configuration via DHCP. Set netsetup=-dhcp when configuring the network with the boot parameters hostip, gateway and nameserver. With the option netsetup=hostip,netmask,gateway,nameserver the installer asks for the network settings during boot.

ifcfg=INTERFACE[.VLAN]=[.try,]SETTINGS

INTERFACE can be * to match all interfaces or, for example, eth* to match all interfaces that start with eth. It is also possible to use MAC addresses as values.

Optionally, a VLAN can be set behind the interface name, separated by a period.

If SETTINGS is dhcp, all matching interfaces will be configured with DHCP. If you add the try option, configuration will stop when the installation repository can be reached via one of the configured interfaces.

Alternatively, you can use static configuration. With static parameters, only the first matching interface will be configured, unless you add the try option. This will configure all interfaces until the repository can be reached.

The syntax for the static configuration is:

ifcfg=*="IPS_NETMASK,GATEWAYS,NAMESERVERS,DOMAINS"

Each comma separated value can in turn contain a list of space character separated values. IPS_NETMASK is in the CIDR notation, for example 10.0.0.1/24. The quotes are only needed when using space character separated lists. Example with two name servers:

ifcfg=*="10.0.0.10/24,10.0.0.1,10.0.0.1 10.0.0.2,example.com"
Tip
Tip: Other networking parameters

The ifcfg boot parameter is very powerful and allows you to set almost all networking parameters. In addition to the parameters mentioned above, you can set values for all configuration options (comma separated) from /etc/sysconfig/network/ifcfg.template and /etc/sysconfig/network/config. The following example sets a custom MTU size on an interface otherwise configured via DHCP:

ifcfg=eth0=dhcp,MTU=1500
hostname=host.example.com

Enter the fully qualified host name.

domain=example.com

Domain search path for DNS. Allows you to use short host names instead of fully qualified ones.

hostip=192.168.1.2[/24]

Enter the IP address of the interface to configure. The IP can contain the subnet mask, for example hostip=192.168.1.2/24. This setting is only evaluated if the network is required during the installation.

gateway=192.168.1.3

Specify the gateway to use. This setting is only evaluated if the network is required during the installation.

nameserver=192.168.1.4

Specify the DNS server in charge. This setting is only evaluated if the network is required during the installation.

domain=example.com

Domain search path. This setting is only evaluated if the network is required during the installation.

4.3.3 Specifying the installation source

If you are not using DVD or USB flash drive for installation, specify an alternative installation source.

install=SOURCE

Specify the location of the installation source to use. Possible protocols are cd, hd, slp, nfs, smb (Samba/CIFS), ftp, tftp, http, and https. The default option is cd.

To install over an encrypted connection, use an https URL. If the certificate cannot be verified, disable certificate checking with the sslcerts=0 boot parameter.

If an http, https, ftp, tftp, or smb URL is given, you can authenticate by specifying the user name and password with the URL. Example:

install=https://USER:PASSWORD@SERVER/DIRECTORY/DVD1/

In case of a Samba or CIFS installation, you can also specify the domain that should be used:

install=smb://WORKDOMAIN;USER:PASSWORD@SERVER/DIRECTORY/DVD1/

To use cd, hd or slp, set them as the following example:

install=cd:/
install=hd:/?device=sda/PATH_TO_ISO
install=slp:/

4.3.4 Specifying remote access

Only one of the different remote control methods should be specified at a time. The different methods are: SSH, VNC, remote X server. For information about how to use the parameters listed in this section, see Chapter 8, Remote installation.

display_ip=IP_ADDRESS

Display_IP causes the installing system to try to connect to an X server at the given address.

Important
Important: X authentication mechanism

The direct installation with the X Window System relies on a primitive authentication mechanism based on host names. This mechanism is disabled on current SUSE Linux Enterprise Desktop versions. Installation with SSH or VNC is preferred.

vnc=1

Enables a VNC server during the installation.

vncpassword=PASSWORD

Sets the password for the VNC server.

ssh=1

ssh enables SSH installation.

ssh.password=PASSWORD

Specifies an SSH password for the root user during installation.

4.4 Advanced setups

To configure access to a local RMT or supportconfig server for the installation, you can specify boot parameters to set up these services during installation. The same applies if you need IPv6 support during the installation.

4.4.1 Providing data to access a Repository Mirroring Tool server

By default, updates for SUSE Linux Enterprise Desktop are delivered by the SUSE Customer Center. If your network provides a Repository Mirroring Tool (RMT) server to provide a local update source, you need to equip the client with the server's URL. Client and server communicate solely via HTTPS protocol, therefore you also need to enter a path to the server's certificate if the certificate was not issued by a certificate authority.

Note
Note: Non-interactive installation only

Providing parameters for accessing an RMT server is only needed for non-interactive installations. During an interactive installation the data can be provided during the installation (see Section 5.6, “Registration” for details).

regurl

URL of the RMT server. This URL has a fixed format of https://FQN/center/regsvc/. FQN needs to be a fully qualified host name of the RMT server. Example:

regurl=https://smt.example.com/center/regsvc/

Make sure the values you enter are correct. If regurl has not been specified correctly, the registration of the update source will fail.

regcert

Location of the RMT server's certificate. Specify one of the following locations:

URL

Remote location (HTTP, HTTPS or FTP) from which the certificate can be downloaded. In case regcert is not specified, it will default to http://FQN/smt.crt with FQN being the name of the RMT server. Example:

regcert=http://rmt.example.com/smt-ca.crt
local path

Absolute path to the certificate on the local machine. Example:

regcert=/data/inst/smt/smt-ca.cert
Interactive

Use ask to open a pop-up menu during the installation where you can specify the path to the certificate. Do not use this option with AutoYaST. Example

regcert=ask
Deactivate certificate installation

Use done if the certificate will be installed by an add-on product, or if you are using a certificate issued by an official certificate authority. For example:

regcert=done

4.4.2 Configuring an alternative data server for supportconfig

The data that supportconfig (see Book “Administration Guide”, Chapter 41 “Gathering system information for support” for more information) gathers is sent to the SUSE Customer Center by default. It is also possible to set up a local server to collect this data. If such a server is available on your network, you need to set the server's URL on the client. This information needs to be entered at the boot prompt.

supporturl URL of the server. The URL has the format http://FQN/Path/, where FQN is the fully qualified host name of the server and Path is the location on the server. For example:

supporturl=http://support.example.com/supportconfig/data/

4.4.3 Using IPv6 for the installation

By default you can only assign IPv4 network addresses to your machine. To enable IPv6 during installation, enter one of the following parameters at the boot prompt:

Accept IPv4 and IPv6
ipv6=1
Accept IPv6 only
ipv6only=1

4.4.4 Using a proxy for the installation

In networks enforcing the usage of a proxy server for accessing remote web sites, registration during installation is only possible when configuring a proxy server.

On systems with traditional BIOS, press F4 on the boot screen and set the required parameters in the HTTP Proxy dialog.

On Systems with UEFI BIOS, provide the boot parameter proxy at the boot prompt:

  1. On the boot screen, press E to edit the boot menu.

  2. Append the proxy parameter to the linux line in the following format:

    proxy=https://proxy.example.com:PORT

    If the proxy server requires authentication, add the credentials as follows:

    proxy=https://USER:PASSWORD@proxy.example.com:PORT

    If the proxy server's SSL certificate cannot be verified, disable certificate checking with the sslcerts=0 boot parameter.

    The outcome will be similar to the following:

    GRUB options editor
    Figure 4.3: GRUB options editor
  3. Press F10 to boot with the new proxy setting.

4.4.5 Enabling SELinux support

Enabling SELinux upon installation start-up enables you to configure it after the installation has been finished without having to reboot. Use the following parameters:

security=selinux selinux=1

4.4.6 Enabling the installer self-update

During installation and upgrade, YaST can update itself as described in Section 5.2, “Installer self-update” to solve potential bugs discovered after release. The self_update parameter can be used to modify the behavior of this feature.

To enable the installer self-update, set the parameter to 1:

self_update=1

To use a user-defined repository, specify a URL:

self_update=https://updates.example.com/

4.4.7 Reusing LVM

As of SUSE Linux Enterprise 15 SP6, the installer no longer reuses pre-existing Logical Volume Manager (LVM) configurations in its Guided Setup for this can be confusing and lead to suboptimal setups. To reuse an existing LVM regardless, use the YAST_REUSE_LVM parameter or configure it manually in the Expert Partitioner (Chapter 7, Expert Partitioner).

4.4.8 Scale user interface for high DPI

If your screen uses a very high DPI, use the boot parameter QT_AUTO_SCREEN_SCALE_FACTOR. This scales font and user interface elements to the screen DPI.

QT_AUTO_SCREEN_SCALE_FACTOR=1

4.4.9 Using CPU mitigations

The boot parameter mitigations lets you control mitigation options for side-channel attacks on affected CPUs. Its possible values are:

auto Enables all mitigations required for your CPU model, but does not protect against cross-CPU thread attacks. This setting may impact performance to some degree, depending on the workload.

nosmt Provides the full set of available security mitigations. Enables all mitigations required for your CPU model. In addition, it disables Simultaneous Multithreading (SMT) to avoid side-channel attacks across multiple CPU threads. This setting may further impact performance, depending on the workload.

off Disables all mitigations. Side-channel attacks against your CPU are possible, depending on the CPU model. This setting has no impact on performance.

Each value comes with a set of specific parameters, depending on the CPU architecture, the kernel version, and on the vulnerabilities that need to be mitigated. Refer to the kernel documentation for details.

4.4.10 LUKS 2 Support

LUKS2 encryption is supported by the YaST installer as of SUSE Linux Enterprise 15 SP4, but needs to be enabled explicitly.

YAST_LUKS2_AVAILABLE

Alternatively, you can also enable LUKS2 in the YaST expert console. For more information, refer to Section 7.2, “Device encryption”.

4.5 More information

You can find more information about boot parameters in the openSUSE wiki at https://en.opensuse.org/SDB:Linuxrc#Parameter_Reference.

5 Installation steps

This chapter describes the procedure in which the data for SUSE Linux Enterprise Desktop is copied to the target device. Some basic configuration parameters for the newly installed system are set during the procedure. A graphical user interface will guide you through the installation. The procedure described in the following also applies to remote installation procedures as described in Chapter 8, Remote installation. The text mode installation has the same steps and only looks different.

If you are a first-time user of SUSE Linux Enterprise Desktop, you should follow the default YaST proposals in most parts, but you can also adjust the settings as described here to fine-tune your system according to your preferences. Help for each installation step is provided by clicking Help.

Tip
Tip: Installation without a mouse

If the installer does not detect your mouse correctly, use →| for navigation, arrow keys to scroll, and Enter to confirm a selection. Various buttons or selection fields contain a letter with an underscore. Use AltLetter to select a button or a selection directly instead of navigating there with →|.

5.1 Overview

This section provides an overview of all installation steps. Each step contains a link to a more detailed description.

  1. Before the installation starts, the installer may update itself. For details, see Section 5.2, “Installer self-update”.

  2. The actual installation starts with choosing the language and the product. For details, see Section 5.3, “ Language, keyboard and product selection.

  3. Accept the license agreement. For details, see Section 5.4, “License agreement”.

  4. Configure the network. This is only required when you need network access during the installation, and automatic network configuration via DHCP fails. If the automatic network configuration succeeds, this step is skipped. For details, see Section 5.5, “Network settings”.

  5. With a working network connection you can register the machine at the SUSE Customer Center or an RMT server. For details, see Section 5.6, “Registration”.

  6. Select the modules you want to enable for the machine. This impacts the availability of system roles in the next step and packages later on. For details, see Section 5.7, “Extension and module selection”.

  7. You can manually add repositories. For details, see Section 5.8, “Add-on product”.

  8. Select a role for your system. This defines the default list of packages to install and makes a suggestion for partitioning the hard disks. For details, see Section 5.9, “System roles”.

  9. Partition the hard disks of your system. For details, see Section 5.10, “Partitioning”.

  10. Choose a time zone. For details, see Section 5.11, “Clock and time zone”.

  11. Create a user. For details, see Section 5.12, “Create new user”.

  12. (Optional) Optionally, set a different password for the system administrator root. For details, see Section 5.13, “Authentication for the system administrator root.

  13. In a final step, the installer presents an overview of all settings. If required, you can change them. For details, see Section 5.14, “Installation settings”.

  14. The installer copies all required data and informs you about the progress. For details, see Section 5.15, “Performing the installation”.

5.2 Installer self-update

During the installation and upgrade process, YaST may update itself to solve bugs in the installer that were discovered after the release. This functionality is enabled by default; to disable it, set the boot parameter self_update to 0. For more information, see Section 4.4.6, “Enabling the installer self-update”.

Important
Important: Quarterly media update: self-update disabled

The installer self-update is only available if you use the GM images of the Unified Installer and Packages ISOs. If you install from the ISOs published as quarterly update (they can be identified by the string QU in the name), the installer cannot update itself, because this feature is disabled in the update media.

Important
Important: Networking during self-update

To download installer updates, YaST needs network access. By default, it tries to use DHCP on all network interfaces. If there is a DHCP server in the network, it will work automatically.

If you need a static IP setup, you can use the ifcfg boot argument. For more details, see the linuxrc documentation at https://en.opensuse.org/Linuxrc.

Tip
Tip: Language selection

The installer self-update runs before the language selection step. This means that progress and errors which happen during this process are displayed in English by default.

To use another language for this part of the installer, use the language boot parameter if available for your architecture, for example, language=de_DE. On machines equipped with a traditional BIOS, alternatively, press F2 in the boot menu and select the language from the list.

Although this feature was designed to run without user intervention, it is worth knowing how it works. If you are not interested, you can jump directly to Section 5.3, “ Language, keyboard and product selection and skip the rest of this section.

5.2.1 Self-update process

The process can be broken down into two different parts:

  1. Determine the update repository location.

  2. Download and apply the updates to the installation system.

5.2.1.1 Determining the update repository location

Installer Self-Updates are distributed as regular RPM packages via a dedicated repository, so the first step is to find the repository URL.

Important
Important: Installer self-update repository only

No matter which of the following options you use, only the installer self-update repository URL is expected, for example:

self_update=https://www.example.com/my_installer_updates/

Do not supply any other repository URL—for example the URL of the software update repository.

YaST will try the following sources of information:

  1. The self_update boot parameter. (For more details, see Section 4.4.6, “Enabling the installer self-update”.) If you specify a URL, it will take precedence over any other method.

  2. The /general/self_update_url profile element in case you are using AutoYaST.

  3. A registration server. YaST will query the registration server for the URL. The server to be used is determined in the following order:

    1. By evaluating the regurl boot parameter (Section 4.4.1, “Providing data to access a Repository Mirroring Tool server”).

    2. By evaluating the /suse_register/reg_server profile element if you are using AutoYaST.

    3. By performing an SLP lookup. If an SLP server is found, YaST will ask you whether it should be used because there is no authentication involved and anybody on the local network can broadcast a registration server.

    4. By querying the SUSE Customer Center.

  4. If none of the previous attempts work, the fallback URL (defined in the installation media) will be used.

5.2.1.2 Downloading and applying the updates

When the update repository is determined, YaST checks whether an update is available. If it is, all the updates are downloaded and applied.

Finally, YaST restarts and displays the welcome screen. If no updates are available, the installation continues without restarting YaST.

Note
Note: Update integrity

Update signatures will be checked to ensure integrity and authorship. If a signature is missing or invalid, you will be asked whether you want to apply the update.

5.2.1.3 Temporary self-update add-on repository

Some packages distributed in the self-update repository provide additional data for the installer, like installation defaults, system role definitions and similar. If the installer finds such packages in the self-update repository, a local temporary repository is created, to which those packages are copied. They are used during the installation. The temporary local repository is removed at the end of the installation. Its packages are not installed on the target system.

This additional repository is not displayed in the list of add-on products, but during installation it may still be visible as SelfUpdate0 repository in the package management.

5.2.2 Custom self-update repositories

YaST can use a user-defined repository instead of the official repository by specifying a URL through the self_update boot parameter.

  • HTTP/HTTPS and FTP repositories are supported.

  • Starting with yast2-installation-4.4.30, the relurl:// schema is supported, as a boot parameter or in an AutoYaST profile. The URL is relative to the main installation repository, and you may navigate the file tree with the usual ../ notation, for example relurl://../self_update. This is useful when serving the packages via a local installation server, or when building a custom installation medium which includes a self-update repository.

    The following examples assume the installation repository is at the medium root (/), and the self-update repository in the self_update subdirectory. This structure makes the relurl:// portable, and it will work anywhere without changes as a boot parameter, copied to a USB stick, hard disk, network server, or in an AutoYaST profile.

    Custom DVD/USB medium

    Add the self_update=relurl://self_update boot option directly to the default boot parameters, and it will work properly even if the medium is copied to an USB stick, hard disk, or a network server.

    Installation server

    Assume that the installation packages are available via http://example.com/repo and a self-update repository is available at http://example.com/self_update.

    Then you can use the http://example.com/repo and http://example.com/self_update boot parameters, without having to change the self_update parameter when the repositories are moved to a different location.

  • Only RPM-MD repositories are supported (required by RMT).

  • Packages are not installed in the usual way: They are uncompressed only and no scripts are executed.

  • No dependency checks are performed. Packages are installed in alphabetical order.

  • Files from the packages override the files from the original installation media. This means that the update packages might not need to contain all files, only files that have changed. Unchanged files are omitted to save memory and download bandwidth.

Note
Note: Only one repository

Currently, it is not possible to use more than one repository as source for installer self-updates.

5.3 Language, keyboard and product selection

Language, keyboard and product selection
Figure 5.1: Language, keyboard and product selection

The Language and Keyboard Layout settings are initialized with the language you chose on the boot screen. If you did not change the default, it will be English (US). Change the settings here, if necessary.

Changing the language automatically selects a corresponding keyboard layout. You can override this proposal by selecting a different keyboard layout from the drop-down box. Use the Keyboard Test text box to test the layout. The selected language also determines a time zone for the system clock. This setting can be modified later as described in Book “Administration Guide”, Chapter 5 “Changing language and country settings with YaST”.

With the Unified Installer, you can install all SUSE Linux Enterprise base products:

Select a product for installation. You need to have a registration code for the respective product. In this document it is assumed you have chosen SUSE Linux Enterprise Desktop. Proceed with Next.

Tip
Tip: Light and high-contrast themes

If you have difficulties reading the labels in the installer, you can change the widget colors and theme.

Click the Change the widget theme button or press ShiftF3 to open a theme selection dialog. Select a theme from the list and Close the dialog.

ShiftF4 switches to the color scheme for vision-impaired users. Press the buttons again to switch back to the default scheme.

5.4 License agreement

License Agreement
Figure 5.2: License agreement

Read the License Agreement. It is presented in the language you have chosen on the boot screen. Translations are available via the License Language drop-down box. If you agree to the terms, check I Agree to the License Terms and click Next to proceed with the installation. If you do not agree to the license agreement, you cannot install SUSE Linux Enterprise Desktop; click Abort to terminate the installation.

5.5 Network settings

After booting into the installation, the installation routine is set up. During this setup, an attempt to configure at least one network interface with DHCP is made. In case this attempt has failed, the Network Settings dialog launches now.

Network Settings
Figure 5.3: Network settings

Choose a network interface from the list and click Edit to change its settings. Use the tabs to configure DNS and routing. See Book “Administration Guide”, Chapter 23 “Basic networking”, Section 23.4 “Configuring a network connection with YaST” for more details.

In case DHCP was successfully configured during installation setup, you can also access this dialog by clicking Network Configuration at the SUSE Customer Center Registration and the Installation Settings step. It lets you change the automatically provided settings.

Note
Note: Network configuration with boot parameters

If at least one network interface has been configured via boot parameters (see Section 4.3.2, “Configuring the network interface”), automatic DHCP configuration is disabled and the boot parameter configuration is imported and used.

Tip
Tip: Accessing network storage or local RAID

To access a SAN or a local RAID during the installation, you can use the libstorage command line client for this purpose:

  1. Switch to a console with CtrlAltF2.

  2. Install the libstoragemgmt extension by running extend libstoragemgmt.

  3. Now you have access to the lsmcli command. For more information, run lsmcli --help.

  4. To return to the installer, press AltF7

Supported are Netapp Ontap, all SMI-S compatible SAN providers, and LSI MegaRAID.

5.6 Registration

To get technical support and product updates, you need to register and activate SUSE Linux Enterprise Desktop with the SUSE Customer Center or a local registration server. Registering your product at this stage also grants you immediate access to the update repository. This enables you to install the system with the latest updates and patches available.

When registering, repositories and dependencies for modules and extensions are loaded from the registration server.

From this dialog, you can switch to the YaST Network Settings module by clicking Network Configuration. For details, see Book “Administration Guide”, Chapter 23 “Basic networking”, Section 23.4 “Configuring a network connection with YaST”.

If you are offline or want to skip registration, activate Skip Registration. See Section 5.6.3, “Installing without registration” for instructions.

5.6.1 Manual registration

To register with the SUSE Customer Center, provide the E-mail Address associated with your SCC account and the Registration Code for SUSE Linux Enterprise Desktop.

If your organization offers a local registration server, you may register there. Activate Register System via local SMT Server and either choose a URL from the drop-down box or type in an address. Proceed with Next.

To register with the SUSE Customer Center, enter your Registration Code for SUSE Linux Enterprise Desktop. If your organization provides a local registration server, you may register there. Activate Register System via local RMT Server and either choose a URL from the drop-down box or type in an address.

Start the registration process with Next.

SUSE Customer Center Registration
Figure 5.4: SUSE Customer Center registration
Note
Note: Trusting repositories

Depending on your hardware, additional repositories containing hardware drivers may be added during the registration. If so, you will be asked to Trust each of these repositories.

Tip
Tip: Installing product patches at installation time

After SUSE Linux Enterprise Desktop has been successfully registered, you are asked whether to install the latest available online updates during the installation. If you choose Yes, the system will be installed with the most current packages without having to apply updates after installation. It is recommended to enable this option.

Note
Note: Firewall settings for receiving updates

By default, the firewall on SUSE Linux Enterprise Desktop only blocks incoming connections. If your system is behind another firewall that blocks outgoing traffic, make sure to allow connections to https://scc.suse.com/ and https://updates.suse.com on ports 80 and 443 in order to receive updates.

If the system is successfully registered during installation, YaST disables repositories from local installation media such as CD/DVD or flash disks when the installation completes. This prevents problems caused by the missing installation source and ensures that you always get the latest updates from the online repositories.

5.6.2 Loading registration codes from USB storage

To make the registration more convenient, you can also store your registration codes on a USB storage device such as a flash disk. YaST will automatically pre-fill the corresponding text box. This is particularly useful when testing the installation or if you need to register many systems or extensions.

Create a file named regcodes.txt or regcodes.xml on the USB disk. If both are present, the XML takes precedence.

In that file, identify the product with the name returned by zypper search --type product and assign it a registration code as follows:

Example 5.1: regcodes.txt
SLES    cc36aae1
SLED    309105d4

sle-we  5eedd26a
sle-live-patching 8c541494
Example 5.2: regcodes.xml
<?xml version="1.0"?>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
 xmlns:config="http://www.suse.com/1.0/configns">
  <suse_register>
    <addons config:type="list">
      <addon>
<name>SLES</name>
<reg_code>cc36aae1</reg_code>
      </addon>
      <addon>
<name>SLED</name>
<reg_code>309105d4</reg_code>
      </addon>
      <addon>
<name>sle-we</name>
<reg_code>5eedd26a</reg_code>
      </addon>
      <addon>
<name>sle-live-patching</name>
<reg_code>8c541494</reg_code>
      </addon>
    </addons>
  </suse_register>
</profile>

Note that SLES and SLED are not extensions, but listing them as add-ons allows for combining several base product registration codes in a single file.

Note
Note: Limitations

Currently flash disks are only scanned during installation or upgrade, but not when registering a running system.

5.6.3 Installing without registration

If you are offline or want to skip registration, activate Skip Registration. Accept the warning with OK and proceed with Next.

Important
Important: Skipping the registration

Your system and extensions need to be registered to retrieve updates and to be eligible for support. Skipping the registration is only possible when installing from the SLE-15-SP6-Full-ARCH-GM-media1.iso image.

Installing without Registration
Figure 5.5: Installing without registration
Note
Note: Registering SUSE Linux Enterprise Desktop

Your system and extensions need to be registered to retrieve updates and to be eligible for support. If you do not register during the installation, you can do so at any time later from the running system. To do so, run YaST › Product Registration.

Tip
Tip: Copying the installation media image to a removable flash disk

Use the following command to copy the contents of the installation image to a removable flash disk.

> sudo dd if=IMAGE of=FLASH_DISK bs=4M && sync

IMAGE needs to be replaced with the path to the SLE-15-SP6-Online-ARCH-GM-media1.iso or SLE-15-SP6-Full-ARCH-GM-media1.iso image file. FLASH_DISK needs to be replaced with the flash device. To identify the device, insert it and run:

# grep -Ff <(hwinfo --disk --short) <(hwinfo --usb --short)
     disk:
     /dev/sdc             General USB Flash Disk

Make sure the size of the device is sufficient for the desired image. You can check the size of the device with:

# fdisk -l /dev/sdc | grep -e "^/dev"
     /dev/sdc1  *     2048 31490047 31488000  15G 83 Linux

In this example, the device has a capacity of 15 GB. The command to use for the SLE-15-SP6-Full-ARCH-GM-media1.iso would be:

dd if=SLE-15-SP6-Full-ARCH-GM-media1.iso of=/dev/sdc bs=4M && sync

The device must not be mounted when running the dd command. Note that all data on the partition will be erased!

5.7 Extension and module selection

In this dialog the installer lists modules and extensions that are available for SUSE Linux Enterprise Desktop. Modules are components that allow you to customize the product according to your needs. They are included in your SUSE Linux Enterprise Desktop subscription. Extensions add functionality to your product. They must be purchased separately.

The availability of certain modules or extensions depends on the product you chose in the first step of this installation. For a description of the modules and their lifecycles, select a module to see the accompanying text. More detailed information is available in the Modules and Extensions Quick Start.

The selection of modules indirectly affects the scope of the installation, because it defines which software sources (repositories) are available for installation and in the running system.

Extension and Module Selection
Figure 5.6: Extension and module selection

The following modules and extensions are available for SUSE Linux Enterprise Desktop:

Basesystem Module

This module adds a basic system on top of the Unified Installer. It is required by all other modules and extensions. The scope of an installation that only contains the base system is comparable to the installation pattern minimal system of previous SUSE Linux Enterprise Desktop versions. This module is selected for installation by default and should not be deselected.

Dependencies: None

Certifications Module

Contains the FIPS certification packages.

Dependencies: Server Applications

Desktop Applications Module

Adds a graphical user interface and essential desktop applications to the system. This module is selected for installation by default; deselecting it is not recommended.

Dependencies: Basesystem

Development Tools Module

Contains compilers (including gcc) and libraries required for compiling and debugging applications. Replaces the former Software Development Kit (SDK).

Dependencies: Basesystem, Desktop Applications

Python 3 Module

This module contains the most recent version of the selected Python 3 packages.

Dependencies: Basesystem

SUSE Linux Enterprise Workstation Extension

Contains additional desktop tools such as an office suite or multimedia software such as music and video players. This extension is included in the SUSE Linux Enterprise Desktop subscription and is selected for installation by default; deselecting it is not recommended.

Dependencies: Basesystem, Desktop Applications

SUSE Package Hub

Provides access to packages for SUSE Linux Enterprise Desktop maintained by the openSUSE community. These packages are delivered without L3 support and do not interfere with the supportability of SUSE Linux Enterprise Desktop. For more information, refer to https://packagehub.suse.com/.

Dependencies: Basesystem

Some modules depend on the installation of other modules. Therefore, when selecting a module, other modules may be selected automatically to fulfill dependencies.

Depending on the product, the registration server can mark modules and extensions as recommended. Recommended modules and extensions are preselected for registration and installation. To avoid installing these recommendations, deselect them manually.

Select the modules and extensions you want to install and proceed with Next. In case you have chosen one or more extensions, you will be prompted to provide the respective registration codes. Depending on your choice, it may also be necessary to accept additional license agreements.

Important
Important: Default modules for offline installation

When performing an offline installation from the SLE-15-SP6-Full-ARCH-GM-media1.iso, only the Basesystem Module is selected by default. To install the complete default package set of SUSE Linux Enterprise Desktop, additionally select the Desktop Applications Module, the SUSE Linux Enterprise Workstation Extension, and the Python 2 Module.

5.8 Add-on product

The Add On Product dialog allows you to add additional software sources (so-called repositories) to SUSE Linux Enterprise Desktop, that are not provided by the SUSE Customer Center. Such add-on products may include third-party products and drivers or additional software for your system.

Add-On Product
Figure 5.7: Add-on product

From this dialog, you can switch to the YaST Network Settings module by clicking Network Configuration. For details, see Book “Administration Guide”, Chapter 23 “Basic networking”, Section 23.4 “Configuring a network connection with YaST”.

Tip
Tip: Adding drivers during the installation

You can also add driver update repositories via the Add On Product dialog. Driver updates for SUSE Linux Enterprise are provided at https://drivers.suse.com/. These drivers have been created via the SUSE SolidDriver Program.

If you do not want to install add-ons, proceed with Next. Otherwise activate I would like to install an additional Add On Product. Specify the Media Type by choosing from CD, DVD, Hard Disk, USB Mass Storage, a Local Directory or a Local ISO Image. If network access has been configured you can choose from additional remote sources such as HTTP, SLP, FTP, etc. Alternatively you may directly specify a URL. Check Download repository description files to download the files describing the repository now. If deactivated, they will be downloaded after the installation starts. Proceed with Next and insert a CD or DVD if required.

Depending on the add-on's content, it may be necessary to accept additional license agreements.

5.9 System roles

To simplify the installation, the installer offers predefined use cases that tailor the system for the selected scenario.

System Role
Figure 5.8: System role

Choose the System Role that meets your requirements best. The availability of system roles depends on your selection of modules and extensions. The dialog is omitted under the following conditions:

  • The combination of base product and modules does not allow roles to be chosen.

  • The combination of base product and modules only allows a single role.

With the default selection, the following system roles are available:

GNOME Desktop (Wayland)

Installs a fully featured GNOME desktop environment, including office suite, e-mail client, Web browser, and file manager. It is optimized for installation on physical systems, using the Wayland technology. Does not support accessing the desktop from a remote machine.

Dependencies: Basesystem, Desktop Applications, SUSE Linux Enterprise Workstation Extension

GNOME Desktop (X11)

Installs a fully featured GNOME desktop environment, including office suite, e-mail client, Web browser, and file manager. Comes with support for accessing the desktop from a remote machine.

Dependencies: Basesystem, Desktop Applications, SUSE Linux Enterprise Workstation Extension

GNOME Desktop (Basic)

Installs a GNOME desktop environment with only essential graphical applications (for example file manager, Web browser). It is using the X11 technology.

Dependencies: Basesystem, Desktop Applications

IceWM Desktop (Minimal)

Installs a lightweight IceWM desktop environment with only a bare minimum of graphical applications (for example xterm). It is using the X11 technology.

Dependencies: Basesystem

5.10 Partitioning

5.10.1 Important information

Warning
Warning: Read this section carefully

Read this section carefully before continuing with Section 5.10.2, “Suggested partitioning”.

Custom partitioning on UEFI machines

A UEFI machine requires an EFI system partition that must be mounted to /boot/efi. This partition must be formatted with the FAT32 file system.

If an EFI system partition is already present on your system (for example from a previous Windows installation) use it by mounting it to /boot/efi without formatting it.

If no EFI system partition is present on your UEFI machine, make sure to create it. The EFI system partition must be a physical partition or RAID 1. Other RAID levels, LVM and other technologies are not supported. It needs to be formatted with the FAT32 file system.

Custom partitioning and Snapper

SUSE Linux Enterprise Desktop can be configured to use snapshots which provide the ability to do rollbacks of system changes.

SUSE Linux Enterprise Desktop uses Snapper together with Btrfs for this feature. Btrfs needs to be set up with snapshots enabled for the root partition.

If the disk is smaller than 16 GB, all Snapper features and automatic snapshots are disabled to prevent the system partition / from running out of space.

Being able to create system snapshots that enable rollbacks requires important system directories to be mounted on a single partition, for example /usr and /var. Only directories that are excluded from snapshots may reside on separate partitions, for example /usr/local, /var/log, and /tmp.

If snapshots are enabled, the installer will automatically create single snapshots during and immediately after the installation.

For details, see Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper”.

Important
Important: Btrfs snapshots and root partition size

Snapshots may take considerable storage space. Generally, the older a snapshot is or the larger the changeset it covers, the more storage space the snapshot takes. And the more snapshots you keep, the more disk space you need.

To prevent the root partition running full with snapshot data, you need to make sure it is big enough. In case you do frequent updates or other installations, consider at least 30 GB for the root partition. If you plan to keep snapshots activated for a system upgrade or a service pack migration (to be able to roll back), you should consider 40 GB or more.

Btrfs data volumes

Using Btrfs for data volumes is supported on SUSE Linux Enterprise Desktop 15 SP6. For applications that require Btrfs as a data volume, consider creating a separate file system with quota groups disabled. This is already the default for non-root file systems.

Btrfs on an encrypted root partition

The default partitioning setup suggests the root partition as Btrfs. To encrypt the root partition, make sure to use the GPT partition table type instead of the MSDOS type. Otherwise the GRUB2 boot loader may not have enough space for the second stage loader.

Supported software RAID volumes

Installing to and booting from existing software RAID volumes is supported for Disk Data Format (DDF) volumes and Intel Matrix Storage Manager (IMSM) volumes. IMSM is also known by the following names:

Mount points for FCoE and iSCSI devices

FCoE and iSCSI devices will appear asynchronously during the boot process. While the initrd guarantees that those devices are set up correctly for the root file system, there are no such guarantees for any other file systems or mount points like /usr. Hence any system mount points like /usr or /var are not supported. To use those devices, ensure correct synchronization of the respective services and devices.

Handling of Windows partitions in proposals

In case the disk selected for the suggested partitioning proposal contains a large Windows FAT or NTFS partition, it will automatically be resized to make room for the SUSE Linux Enterprise Desktop installation. To avoid data loss it is strongly recommended to

  • make sure the partition is not fragmented (run a defragmentation program from Windows prior to the SUSE Linux Enterprise Desktop installation)

  • double-check the suggested size for the Windows partition is big enough

  • back up your data prior to the SUSE Linux Enterprise Desktop installation

To adjust the proposed size of the Windows partition, use the Expert Partitioner.

5.10.2 Suggested partitioning

Define a partition setup for SUSE Linux Enterprise Desktop in this step.

Suggested Partitioning
Figure 5.9: Suggested partitioning

The installer creates a proposal for one of the available disks containing a root partition formatted with Btrfs and a swap partition. If one or more swap partitions have been detected on the available hard disks, these partitions will be used. You have several options to proceed:

Next

To accept the proposal without any changes, click Next to proceed with the installation workflow.

Guided setup

To adjust the proposal, choose Guided Setup. First, choose which hard disks and partitions to use. In the Partitioning Scheme screen, you can enable Logical Volume Management (LVM) and activate disk encryption. Afterward specify the Filesystem Options. You can adjust the file system for the root partition and create a separate home and swap partitions. If you plan to suspend your machine, make sure to create a separate swap partition and check Enlarge to RAM Size for Suspend. If the root file system format is Btrfs, you can also enable or disable Btrfs snapshots here.

Expert Partitioner

To create a custom partition setup click Expert Partitioner. Select either Start with Current Proposal if you want start with the suggested disk layout, or Start with Existing Partitions to ignore the suggested layout and start with the existing layout on the disk. You can Add, Edit, Resize, or Delete partitions.

You can also set up logical volume management (LVM), configure software RAID and device mapping (DM), encrypt partitions, mount NFS shares and manage tmpfs volumes with the Expert Partitioner. To fine-tune settings such as the subvolume and snapshot handling for each Btrfs partition, choose Btrfs. For more information about custom partitioning and configuring advanced features, refer to Section 7.1, “Using the Expert Partitioner.

Warning
Warning: Disk space units

Note that for partitioning purposes, disk space is measured in binary units, rather than in decimal units. For example, if you enter sizes of 1GB, 1GiB or 1G, they all signify 1 GiB (Gibibyte), as opposed to 1 GB (Gigabyte).

Binary

1 GiB = 1 073 741 824 bytes.

Decimal

1 GB = 1 000 000 000 bytes.

Difference

1 GiB ≈ 1.07 GB.

5.11 Clock and time zone

In this dialog, select your region and time zone. Both are preselected according to the installation language.

Clock and Time Zone
Figure 5.10: Clock and time zone

To change the preselected values, either use the map or the drop-down boxes for Region and Time Zone. When using the map, point the cursor at the rough direction of your region and left-click to zoom. Now choose your country or region by left-clicking. Right-click to return to the world map.

To set up the clock, choose whether the Hardware Clock is Set to UTC. If you run another operating system on your machine, such as Microsoft Windows, it is likely your system uses local time instead. If you run Linux on your machine, set the hardware clock to UTC and have the switch from standard time to daylight saving time performed automatically.

Important
Important: Set the hardware clock to UTC

The switch from standard time to daylight saving time (and vice versa) can only be performed automatically when the hardware clock (CMOS clock) is set to UTC. This also applies if you use automatic time synchronization with NTP, because automatic synchronization will only be performed if the time difference between the hardware and system clock is less than 15 minutes.

Since a wrong system time can cause serious problems (missed backups, dropped mail messages, mount failures on remote file systems, etc.), it is strongly recommended to always set the hardware clock to UTC.

If a network is already configured, you can configure time synchronization with an NTP server. Click Other Settings to either alter the NTP settings or to Manually set the time. See Book “Administration Guide”, Chapter 39 “Time synchronization with NTP” for more information on configuring the NTP service. When finished, click Accept to continue the installation.

If running without NTP configured, consider setting SYSTOHC=no (sysconfig variable) to avoid saving unsynchronized time into the hardware clock.

5.12 Create new user

Create a local user in this step.

Create New User
Figure 5.11: Create new user

After entering the first name and last name, either accept the proposal or specify a new User name that will be used to log in. Only use lowercase letters (a-z), digits (0-9) and the characters . (dot), - (hyphen) and _ (underscore). Special characters, umlauts and accented characters are not allowed.

Finally, enter a password for the user. Re-enter it for confirmation (to ensure that you did not type something else by mistake). To provide effective security, a password should be at least six characters long and consist of uppercase and lowercase letters, numbers and special characters (7-bit ASCII). Umlauts or accented characters are not allowed. Passwords you enter are checked for weakness. When entering a password that is easy to guess (such as a dictionary word or a name) you will see a warning. It is a good security practice to use strong passwords.

Important
Important: User name and password

Remember both your user name and the password because they are needed each time you log in to the system.

If you install SUSE Linux Enterprise Desktop on a machine with one or more existing Linux installations, YaST allows you to import user data such as user names and passwords. Select Import User Data from a Previous Installation and then Choose Users for import.

If you do not want to configure any local users (for example when setting up a client on a network with centralized user authentication), skip this step by choosing Next and confirming the warning. Network user authentication can be configured at any time later in the installed system; refer to Book “Administration Guide”, Chapter 6 “Managing users with YaST” for instructions.

Two additional options are available:

Use this password for system administrator

If checked, the same password you have entered for the user will be used for the system administrator root. This option is suitable for stand-alone workstations or machines in a home network that are administrated by a single user. When not checked, you are prompted for a system administrator password in the next step of the installation workflow (see Section 5.13, “Authentication for the system administrator root).

Automatic login

This option automatically logs the current user in to the system when it starts. This is mainly useful if the computer is operated by only one user.

Warning
Warning: Automatic login

With the automatic login enabled, the system boots straight into your desktop with no authentication. If you store sensitive data on your system, you should not enable this option if the computer can also be accessed by others.

In an environment where users are centrally managed (for example by NIS or LDAP) you should skip the creation of local users. Select Skip User Creation in this case.

5.13 Authentication for the system administrator root

If you have not chosen Use this Password for System Administrator in the previous step, you will be prompted to enter a password for the system administrator root or provide a public SSH key. Otherwise, this configuration step is skipped.

Authentication for the System Administrator root
Figure 5.12: Authentication for the system administrator root

Enter the password for the system administrator root. For verification purposes, the password for root must be entered twice. Do not forget the password as it cannot be retrieved later.

Tip
Tip: Passwords and keyboard layout

It is recommended to only use US ASCII characters. In case of a system error or when you need to start your system in rescue mode, the keyboard may not be localized.

To change the root password later in the installed system, run YaST and start Security and Users › User and Group Management.

Important
Important: The root user

root is the name of the system administrator or superuser. Its user ID (uid) is 0. Unlike regular users, the root account has unlimited privileges.

Do not forget the root password

Only root has the privileges to change the system configuration, install programs, manage users and set up new hardware. To carry out such tasks, the root password is required. Do not forget the password as it cannot be retrieved later.

Do not use the root user for daily work

Logging in as root for daily work is rather risky: Commands from root are usually executed without additional confirmation, so a single mistake can lead to an irretrievable loss of system files. Only use the root account for system administration, maintenance and repair.

Do not rename the root user account

YaST will always name the system administrator root. While it is technically possible to rename the root account, certain applications, scripts or third-party products may rely on the existence of a user called root. While such a configuration always targets individual environments, necessary adjustments could be overwritten by vendor updates, so this becomes an ongoing task rather than a one-time setting. This is especially true in very complex setups involving third-party applications, where it needs to be verified with every vendor involved whether a rename of the root account is supported.

As the implications for renaming the root account cannot be foreseen, SUSE does not support renaming the root account.

Usually, the idea behind renaming the root account is to hide it or make it unpredictable. However, /etc/passwd requires 644 permissions for regular users, so any user of the system can retrieve the login name for the user ID 0. For better ways to secure the root account, refer to Book “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5 “Restricting root logins” and Book “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5.3 “Restricting SSH logins”.

If you want to access the system remotely via SSH using a public key, import a key from a removable storage device or an existing partition. After the installation is finished, you can log in through SSH using the provided SSH key.

Procedure 5.1: Adding a public SSH key for user root

To import a public SSH key from a medium partition, perform the following steps:

  1. The public SSH key is located in your ~/.ssh directory and has the file extension .pub. Copy it to a removable storage device or an existing partition that is not formatted during installation.

  2. If your key is on a removable storage device, insert it into your computer and click Refresh. You should see the device in the drop-down box under Import Public Key.

  3. Click Browse, select the public SSH key and confirm with Open.

  4. Proceed with Next.

If you have both set a password and added a public SSH key, and need remote access right after the installation, do not forget to open the SSH port in the Security section of the Installation Settings summary. If you set no password but only add a key, the port will be opened automatically to prevent you from being locked out of the newly installed system.

5.14 Installation settings

On the last step before the real installation takes place, you can alter installation settings suggested by the installer. To modify the suggestions, click the respective headline. After having made changes to a particular setting, you are always returned to the Installation Settings window, which is updated accordingly.

If you have added an SSH key for your root as mentioned in Procedure 5.1, make sure to open the SSH port in the Security settings.

Installation Settings
Figure 5.13: Installation settings

5.14.1 Software

SUSE Linux Enterprise Desktop contains several software patterns for various application purposes. The available choice of patterns and packages depends on your selection of modules and extensions.

Click Software to open the Software Selection and System Tasks screen where you can modify the pattern selection according to your needs. Select a pattern from the list and see a description in the right-hand part of the window.

Each pattern contains several software packages needed for specific functions (for example Multimedia or Office software). For a more detailed selection based on software packages to install, select Details to switch to the YaST Software Manager.

Software Selection and System Tasks
Figure 5.14: Software selection and system tasks

You can also install additional software packages or remove software packages from your system at any later time with the YaST Software Manager. For more information, refer to Book “Administration Guide”, Chapter 8 “Installing or removing software”.

By default, SUSE Linux Enterprise Desktop uses the Wayland display server protocol.

Tip
Tip: Adding secondary languages

The language you selected with the first step of the installation will be used as the primary (default) language for the system. You can add secondary languages from within the Software dialog by choosing Details › View › Languages.

5.14.2 Booting

The installer proposes a boot configuration for your system. Other operating systems found on your computer, such as Microsoft Windows or other Linux installations, will automatically be detected and added to the boot loader. However, SUSE Linux Enterprise Desktop will be booted by default. Normally, you can leave these settings unchanged. If you need a custom setup, modify the proposal according to your needs. For information, see Book “Administration Guide”, Chapter 18 “The boot loader GRUB 2”, Section 18.3 “Configuring the boot loader with YaST”.

Important
Important: Software RAID 1

Booting a configuration where /boot resides on a software RAID 1 device is supported, but it requires to install the boot loader into the MBR (Boot Loader Location › Boot from Master Boot Record). Having /boot on software RAID devices with a level other than RAID 1 is not supported.

5.14.3 Security

The CPU Mitigations refer to kernel boot command line parameters for software mitigations that have been deployed to prevent CPU side-channel attacks. Click the selected entry to choose a different option. For details, see Book “Administration Guide”, Chapter 18 “The boot loader GRUB 2” CPU Mitigations.

By default, the Firewall is enabled on all configured network interfaces. To completely disable firewalld, click disable (not recommended).

Note
Note: Firewall settings

When the firewall is activated, all interfaces are assigned to the public zone, where all ports are closed by default, ensuring maximum security. The only port you can open during the installation is port 22 (SSH), to allow remote access. Other services requiring network access (such as FTP, Samba, Web server, etc.) will only work after having adjusted the firewall settings. Refer to Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls” for configuration details.

Note
Note: Firewall settings for receiving updates

By default, the firewall on SUSE Linux Enterprise Desktop only blocks incoming connections. If your system is behind another firewall that blocks outgoing traffic, make sure to allow connections to https://scc.suse.com/ and https://updates.suse.com on ports 80 and 443 in order to receive updates.

The SSH service is enabled by default, but its port (22) is closed in the firewall. Click open to open the port or disable to disable the service. Note that if SSH is disabled, remote logins will not be possible. Refer to Book “Security and Hardening Guide”, Chapter 22 “Securing network operations with OpenSSH” for more information.

Tip
Tip: Existing SSH host keys

If you install SUSE Linux Enterprise Desktop on a machine with existing Linux installations, the installation routine imports an SSH host key. It chooses the host key with the most recent access time by default. See also Section 5.14.7, “Import SSH host keys and configuration.

If you are performing a remote administration over VNC, you can also specify whether the machine should be accessible via VNC after the installation. Note that enabling VNC also requires you to set the Default systemd Target to graphical.

The default Major Linux Security Module is AppAmpor. To disable it, select None as module in the Security settings. This allows you to deselect the AppAmor pattern in the Software settings (Section 5.14.1, “Software).

5.14.4 Security Profiles

Important
Important: Availability in SUSE Linux Enterprise 15 SP4

This feature is available for SUSE Linux Enterprise 15 SP4 GM via installer self-update or using the QU2 media.

This category allows hardening your system with OpenSCAP security policies. The first policy that was implemented is the Security Technical Implementation Guide (STIG) by the Defense Information Systems Agency (DISA).

Click to enable the security policy. Non-compliant installation settings will be listed with the rule they violate. Some settings can be adjusted automatically by clicking fix rule. For settings that require user input, click modify settings to open the respective settings screen.

Tip
Tip: Checking policy compliance during installation

If you do not want to wait for the Installation Settings screen, but want the installer to check the settings from the beginning of the installation process, boot the system with the boot parameter YAST_SECURITY_POLICY=POLICY. To check for compliance with the DISA STIG, use YAST_SECURITY_POLICY=stig. For more information about boot parameters, refer to Chapter 4, Boot parameters.

The installer does not check all rules of the profile, only those necessary for the installation or that are hard to fix afterward. To apply the remaining rules, a full SCAP remediation is performed on first boot. You can also perform a scan only or do nothing and manually remediate the system later with OpenSCAP. For more information, refer to the articles Hardening SUSE Linux Enterprise with STIG and Hardening SUSE Linux Enterprise with OpenSCAP.

5.14.5 Network configuration

This category displays the current network settings, as automatically configured after booting into the installation (see Section 5.5) or as manually configured during the installation process. By default, wicked is used for server installations and NetworkManager for desktop workloads.

If you want to check or adjust the network settings, click Network Configuration. This takes you to the YaST Network Settings module. For details, see Book “Administration Guide”, Chapter 23 “Basic networking”, Section 23.4 “Configuring a network connection with YaST”.

Important
Important: Support for NetworkManager

SUSE only supports NetworkManager for desktop workloads with SLED or the Workstation extension. All server certifications are done with wicked as the network configuration tool, and using NetworkManager may invalidate them. NetworkManager is not supported by SUSE for server workloads.

5.14.6 Default systemd target

SUSE Linux Enterprise Desktop can boot into two different targets (formerly known as runlevels). The graphical target starts a display manager, whereas the multi-user target starts the command line interface.

The default target is graphical. In case you have not installed the X Window System patterns, you need to change it to multi-user. If the system should be accessible via VNC, you need to choose graphical.

5.14.7 Import SSH host keys and configuration

If an existing Linux installation on your computer was detected, YaST will import the most recent SSH host key found in /etc/ssh by default, optionally including other files in the directory as well. This makes it possible to reuse the SSH identity of the existing installation, avoiding the REMOTE HOST IDENTIFICATION HAS CHANGED warning on the first connection. Note that this item is not shown in the installation summary if YaST has not discovered any other installations. You have the following choices:

I would like to import SSH keys from a previous install:

Select this option to import the SSH host key and optionally the configuration of an installed system. You can select the installation to import from in the option list below.

Import SSH Configuration

Enable this to copy other files in /etc/ssh to the installed system in addition to the host keys.

5.14.8 System

This screen lists all the hardware information the installer could obtain about your computer. When opened for the first time, the hardware detection is started. Depending on your system, this may take some time. Select any item in the list and click Details to see detailed information about the selected item. Use Save to File to save a detailed list to either the local file system or a removable device.

Advanced users can also change the PCI ID Setup and kernel settings by choosing Kernel Settings. A screen with two tabs opens:

PCI ID setup

Each kernel driver contains a list of device IDs of all devices it supports. If a new device is not in any driver's database, the device is treated as unsupported, even if it can be used with an existing driver. You can add PCI IDs to a device driver here. Only advanced users should attempt to do so.

To add an ID, click Add and select whether to Manually enter the data, or whether to choose from a list. Enter the required data. The SysFS Dir is the directory name from /sys/bus/pci/drivers—if empty, the driver name is used as the directory name. Existing entries can be managed with Edit and Delete.

Kernel settings

Change the Global I/O Scheduler here. If Not Configured is chosen, the default setting for the respective architecture will be used. This setting can also be changed at any time later from the installed system. Refer to Book “System Analysis and Tuning Guide”, Chapter 13 “Tuning I/O performance” for details on I/O tuning.

Also activate the Enable SysRq Keys here. These keys will let you issue basic commands (such as rebooting the system or writing kernel dumps) in case the system crashes. Enabling these keys is recommended when doing kernel development. Refer to https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html for details.

5.15 Performing the installation

After configuring all installation settings, click Install in the Installation Settings window to start the installation. Some software may require a license confirmation. If your software selection includes such software, license confirmation dialogs are displayed. Click Accept to install the software package. When not agreeing to the license, click I Disagree and the software package will not be installed. In the dialog that follows, confirm with Install again.

The installation usually takes between 15 and 30 minutes, depending on the system performance and the selected software scope. After having prepared the hard disk and having saved and restored the user settings, the software installation starts. Choose Details to switch to the installation log or Release Notes to read important up-to-date information that was not available when the manuals were printed.

After the software installation has completed, the system reboots into the new installation where you can log in. To customize the system configuration or to install additional software packages, start YaST.

6 Registering SUSE Linux Enterprise and managing modules/extensions

To get technical support and product updates, you need to register and activate SUSE Linux Enterprise Desktop with the SUSE Customer Center. It is recommended to register during the installation, since this will enable you to install the system with the latest updates and patches available. However, if you are offline or want to skip the registration step, you can register at any time later from the installed system.

Modules and extensions add features to your system and allow you to customize the system according to your needs. These components also need to be registered and can be managed with YaST or command line tools. For more details also refer to the Article “Modules and Extensions Quick Start”.

Note
Note: SUSE account

Registering with the SUSE Customer Center requires a SUSE account. In case you do not have a SUSE account yet, go to the SUSE Customer Center home page (https://scc.suse.com/) to create one.

Tip
Tip: Deregistering a system

To completely deregister a system including all modules and extensions use the command line tool SUSEConnect. Deregistering a system removes its entry on the registration server and removes all repositories for modules, extensions, and the product itself.

> sudo SUSEConnect -d

6.1 Registering during the installation

The easiest and recommended way to register is during the installation. It not only allows you to install the latest patch level of SUSE Linux Enterprise Desktop, but also gives you access to all modules and extensions without having to provide additional installation media. This also applies to all modules or extensions you install. For details on the registration process, refer to Section 5.6, “Registration”.

If the system was successfully registered during installation, YaST adds online repositories provided by SUSE Customer Center. This prevents problems if local installation sources are no longer available and ensures that you always get the latest updates from the online repositories.

6.2 Registering from the installed system

If you skipped the registration during the installation or want to re-register your system, you can do it at any time using the YaST module Product Registration or the command-line tool SUSEConnect.

6.2.1 Registering with SUSEConnect

Registering the system, along with modules and extensions, can be done from the command line using SUSEConnect. For information on that topic, refer to the inline documentation with man 8 SUSEConnect

Procedure 6.1: Product registration with SUSEConnect
  1. To register SUSE Linux Enterprise Desktop with SUSE Customer Center run SUSEConnect as follows:

    > sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS

    To register with a local registration server, provide the URL of the server:

    > sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS \
    --url "https://suse_register.example.com/"

    Replace REGISTRATION_CODE with the registration code you received with your copy of SUSE Linux Enterprise Desktop. Replace EMAIL_ADDRESS with the E-mail address associated with the SUSE account you or your organization uses to manage subscriptions.

    This process will register the Basesystem Module , SUSE Linux Enterprise Workstation Extension and Desktop Applications Module and add the associated repositories to your system.

  2. SUSE Linux Enterprise Desktop including the two default repositories is now registered. In case you want to register additional modules or extensions, proceed as outlined in Section 6.3, “Managing modules and extensions in a running system”.

6.3 Managing modules and extensions in a running system

You can add and remove modules and extensions even after a system is installed and registered. You can use either YaST or SUSEConnect to do that. For additional information, refer to the Article “Modules and Extensions Quick Start”.

6.3.1 Adding modules and extensions with YaST

  1. Start YaST › Software › System Extensions.

    Extension and Module Selection dialog
  2. To add modules or extensions, select all components you want to install. Note that all extensions require additional registration codes.

  3. All additional components are registered with the registration server and the associated repositories are added to your system.

  4. The YaST package installer opens to install release-packages for each module and, depending on your choice of modules and extensions, additional packages. It is strongly recommended not to deselect any of the preselected packages; you may, however, add additional packages.

    Choose Accept and Finish to conclude the process.

Tip
Tip: Module dependencies

Similar to software packages, which may depend on other packages to function, a module may have dependencies on other modules. If this is the case, the modules on which it depends are automatically selected for installation.

6.3.2 Deleting modules and extensions with YaST

  1. Start YaST › Software › Add-On Products.

    Installed Add-on Products dialog
  2. Choose the module or extension that should be removed and click Delete. Confirm the warning saying that all packages from the selected component will be removed.

  3. The YaST Software Manager opens and lists all installed packages from the deleted module or extension. Click Accept to remove all of them. It is strongly recommended to do so, because you will no longer get updates for packages from deleted modules or extensions. In case you keep packages, make sure to at least remove the *-release package for each module or extension that gets deleted.

    Proceed with Accept and then OK.

Warning
Warning: Deleting modules

Note that you should never delete the Basesystem Module. It is also not recommended to delete the , SUSE Linux Enterprise Workstation Extension and Desktop Applications Module.

Warning
Warning: No updates for packages from deleted modules and extensions

If you choose to keep packages from deleted modules or extensions, you will no longer receive updates for these packages. Because this includes security fixes, keeping such packages may introduce a security risk to your system.

6.3.3 Adding or deleting modules and extensions with SUSEConnect

  1. Run SUSEConnect -list-extensions to get an overview of available extensions:

    > sudo SUSEConnect -list-extensions
    AVAILABLE EXTENSIONS AND MODULES
    
      Basesystem Module 15 SP6 x86_64 (Installed)
      Deactivate with: SUSEConnect -d -p sle-module-basesystem/15.6/x86_64
    
        Desktop Applications Module 15 SP6 x86_64 (Installed)
        Deactivate with: SUSEConnect -d -p sle-module-desktop-applications/15.6/x86_64
    
          Development Tools Module 15 SP6 x86_64
          Activate with: SUSEConnect    -p sle-module-development-tools/15.6/x86_64
    
          SUSE Linux Enterprise Workstation Extension 15 SP6 x86_64 (Installed)
          Deactivate with: SUSEConnect -d -p sle-we/15.6/x86_64
    
        SUSE Cloud Application Platform Tools Module 15 SP6 x86_64
        Activate with: SUSEConnect    -p sle-module-cap-tools/15.6/x86_64
    
        SUSE Package Hub 15 SP6 x86_64
        Activate with: SUSEConnect    -p PackageHub/15.6/x86_64
    
    MORE INFORMATION
    
    You can find more information about available modules here:
    https://www.suse.com/products/server/features/modules.html
  2. Run the appropriate command to add or delete a component. Note that adding extensions requires additional registration codes.

Warning
Warning: Deleting modules

Do not delete the Basesystem Module. It is also not recommended to delete the , SUSE Linux Enterprise Workstation Extension and Desktop Applications Module.

Important
Important: No automatic installation or removal of packages

SUSEConnect only adds or removes modules and extensions. It registers or derigisters the components and enables or disables their repositories, but it does not install or remove any packages. If you want this to be done automatically, use YaST to manage modules and extensions.

When adding a module or extension, SUSEConnect does not install default packages or patterns. To do this manually, use Zypper or YaST › Software Management.

When deleting a module or extension, SUSEConnect does not perform a cleanup. Packages from the module or extension remain installed on the system, but are longer updated from a repository. To list these orphaned packages, run zypper packages --orphaned. To remove one or more packages, run zypper remove PACKAGE [ANOTHER_PACKAGE]. Alternatively use YaST › Software Management and then View › Package Classification › Orphaned Packages to list and delete orphaned packages.

Warning
Warning: No updates for packages from deleted modules and extensions

If you choose to keep packages from deleted modules or extensions, you will no longer receive updates for these packages. Because this includes security fixes, keeping such packages may introduce a security risk to your system.

6.4 SUSEConnect keep-alive timer

From version 0.3.33, the SUSEConnect package ships with two systemd units:

  • suseconnect-keepalive.service: a service which runs the command SUSEConnect --keep-alive on demand.

  • suseconnect-keepalive.timer: a timer which runs the service suseconnect-keepalive.service once a day.

These units are responsible for keeping the system information up-to-date with the SUSE Customer Center or registration server, and to provide accurate data about subscription usage.

The command SUSEConnect --keep-alive updates the last time a system has been seen and its hardware information with the registration service.

Note
Note: The timer is enabled automatically

When the SUSEConnect package is installed or updated, and its version is equal to or greater than the one described above, the keep-alive timer will be enabled automatically.

Tip
Tip: Disabling the SUSEConnect keep-alive timer

If you prefer to not have the SUSEConnect keep-alive timer running on your system, you can disable it with systemctl:

> sudo systemctl disable --now suseconnect-keepalive.timer

Once the timer is disabled, subsequent updates to the SUSEConnect package will not reenable it.

7 Expert Partitioner

Sophisticated system configurations require specific disk setups. You can perform all common partitioning tasks during the installation.

To get persistent device naming with block devices, use the block devices below /dev/disk/by-id or /dev/disk/by-uuid.

Logical Volume Management (LVM) is a disk partitioning scheme that is designed to be much more flexible than the physical partitioning used in standard setups. Its snapshot functionality enables easy creation of data backups. Redundant Array of Independent Disks (RAID) offers increased data integrity, performance, and fault tolerance. SUSE Linux Enterprise Desktop also supports multipath I/O . There is also the option to use iSCSI as a networked disk.

Warning
Warning: Disk space units

Note that for partitioning purposes, disk space is measured in binary units, rather than in decimal units. For example, if you enter sizes of 1GB, 1GiB or 1G, they all signify 1 GiB (Gibibyte), as opposed to 1 GB (Gigabyte).

Binary

1 GiB = 1 073 741 824 bytes.

Decimal

1 GB = 1 000 000 000 bytes.

Difference

1 GiB ≈ 1.07 GB.

7.1 Using the Expert Partitioner

Using the Expert Partitioner (Figure 7.1, “The YaST partitioner”), you can add, delete, resize, and edit partitions, as well as access the soft RAID, and LVM configuration.

Warning
Warning: Repartitioning the running system

Although it is possible to repartition your system while it is running, the risk of making a mistake that causes data loss is very high. Try to avoid repartitioning your installed system and always create a complete backup of your data before attempting to do so.

The YaST partitioner
Figure 7.1: The YaST partitioner

All existing or suggested partitions on all connected hard disks are displayed in the list of Available Storage in the YaST Expert Partitioner dialog. Entire hard disks are listed as devices without numbers, such as /dev/sda. Partitions are listed as parts of these devices, such as /dev/sda1. The size, type, encryption status, file system, and mount point of the hard disks and their partitions are also displayed. The mount point describes where the partition appears in the Linux file system tree.

Several functional views are available on the left hand System View. These views can be used to collect information about existing storage configurations, configure functions (like RAID, Volume Management, Crypt Files), and view file systems with additional features, such as Btrfs, NFS, or TMPFS.

If you run the expert dialog during installation, any free hard disk space is also listed and automatically selected. To provide more disk space to SUSE Linux Enterprise Desktop, free the needed space by going from the bottom toward the top in the list of partitions.

7.1.1 Partition tables

SUSE Linux Enterprise Desktop allows to use and create different partition tables. In some cases the partition table is called disk label. The partition table is important to the boot process of your computer. To boot your machine from a partition in a newly created partition table, make sure that the table format is supported by the firmware.

To change the partition table, click the relevant disk name in the System View and choose Expert › Create New Partition Table.

7.1.1.1 Master boot record

The master boot record (MBR) is the legacy partition table used on IBM PCs. It is sometimes also called an MS-DOS partition table. The MBR only supports four primary partitions. If the disk already has an MBR, SUSE Linux Enterprise Desktop allows you to create additional partitions in it which can be used as the installation target.

The limit of four partitions can be overcome by creating an extended partition. The extended partition itself is a primary partition and can contain more logical partitions.

UEFI firmware usually supports booting from MBR in the legacy mode.

7.1.1.2 GPT partition table

UEFI computers use a GUID Partition Table (GPT) by default. SUSE Linux Enterprise Desktop will create a GPT on a disk if no other partition table exists.

Old BIOS firmware does not support booting from GPT partitions.

You need a GPT partition table to use one of the following features:

  • More than four primary partitions

  • UEFI Secure Boot

  • Use disks larger than 2 TB

Note
Note: Mislabeled partitions created with Parted 3.1 or earlier versions

GPT partitions created with Parted 3.1 or earlier versions use the Microsoft Basic Data partition type instead of the newer Linux-specific GPT GUID. Newer versions of Parted set the misleading flag msftdata on such partitions. This causes various disk tools to label the partition as a Windows Data Partition or similar.

To remove the flag, run:

# parted DEVICE set PARTITION_NUMBER msftdata off

7.1.2 Partitions

The YaST Partitioner can create and format partitions with several file systems. The default file system used by SUSE Linux Enterprise Desktop is Btrfs. For details, see Section 7.1.2.2, “Btrfs partitioning”.

Other commonly used file systems are available: Ext2, Ext3, Ext4, FAT, XFS, Swap, and UDF.

7.1.2.1 Creating a partition

To create a partition select Hard Disks and then a hard disk with free space. The actual modification can be done in the Partitions tab:

  1. Click Add to create a new partition. When using MBR, specify to create a primary or extended partition. Within the extended partition, you can create several logical partitions. For details, see Section 7.1.1, “Partition tables”.

  2. Specify the size of the new partition. You can either choose to occupy all the free unpartitioned space, or enter a custom size.

  3. Select the file system to use and a mount point. YaST suggests a mount point for each partition created. To use a different mount method, like mount by label, select Fstab Options.

  4. Specify additional file system options if your setup requires them. This is necessary, for example, if you need persistent device names. For details on the available options, refer to Section 7.1.3, “Editing a partition”.

  5. Click Finish to apply your partitioning setup and leave the partitioning module.

    If you created the partition during installation, you are returned to the installation overview screen.

7.1.2.2 Btrfs partitioning

The default file system for the root partition is Btrfs. For details, see Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper” . The root file system is the default subvolume and it is not listed in the list of created subvolumes. As a default Btrfs subvolume, it can be mounted as a normal file system.

Important
Important: Btrfs on an encrypted root partition

The default partitioning setup suggests the root partition as Btrfs with /boot being a directory. To encrypt the root partition, make sure to use the GPT partition table type instead of the default MSDOS type. Otherwise the GRUB2 boot loader may not have enough space for the second stage loader.

It is possible to create snapshots of Btrfs subvolumes—either manually, or automatically based on system events. For example when making changes to the file system, zypper invokes the snapper command to create snapshots before and after the change. This is useful if you are not satisfied with the change zypper made and want to restore the previous state. As snapper invoked by zypper creates snapshots of the root file system by default, it makes sense to exclude specific directories from snapshots. This is the reason YaST suggests creating the following separate subvolumes:

/boot/grub2/i386-pc, /boot/grub2/x86_64-efi, /boot/grub2/powerpc-ieee1275, /boot/grub2/s390x-emu

A rollback of the boot loader configuration is not supported. The directories listed above are architecture-specific. The first two directories are present on AMD64/Intel 64 machines, the latter two on IBM POWER and on IBM Z, respectively.

/home

If /home does not reside on a separate partition, it is excluded to avoid data loss on rollbacks.

/opt

Third-party products usually get installed to /opt. It is excluded to avoid uninstalling these applications on rollbacks.

/srv

Contains data for Web and FTP servers. It is excluded to avoid data loss on rollbacks.

/tmp

All directories containing temporary files and caches are excluded from snapshots.

/usr/local

This directory is used when manually installing software. It is excluded to avoid uninstalling these installations on rollbacks.

/var

This directory contains many variable files, including logs, temporary caches, third party products in /var/opt, and is the default location for virtual machine images and databases. Therefore this subvolume is created to exclude all of this variable data from snapshots and has Copy-On-Write disabled.

Tip
Tip: Size of Btrfs partition

Since saved snapshots require more disk space, it is recommended to reserve enough space for Btrfs. While the minimum size for a root Btrfs partition with snapshots and default subvolumes is 16 GB, SUSE recommends at least 32 GB, or more if /home does not reside on a separate partition.

7.1.2.3 Managing Btrfs subvolumes using YaST

Subvolumes of a Btrfs partition can be now managed with the YaST Expert Partitioner module. You can add new or delete existing subvolumes.

Procedure 7.1: Btrfs subvolumes with YaST
  1. Choose Btrfs in the left side pane.

  2. Select the Btrfs partition whose subvolumes you need to manage.

  3. Depending on whether you want to edit, add, or delete subvolumes, do the following:

    1. To edit a subvolume, select it from the list and click Edit. You can then disable copy-on-write (check noCoW) for the volume or limit its size. Click Accept to finish.

    2. To add a new subvolume, click Add Subvolume, and enter its path. Optionally, you can disable copy-on-write (check noCoW) for the volume or limit its size. Click Accept to finish.

    3. To delete a subvolume, select it from the list and click Delete. Confirm the deletion by clicking Yes.

    4. Btrfs subvolumes in YaST partitioner
      Figure 7.2: Btrfs subvolumes in YaST partitioner
  4. Leave the partitioner with Finish.

7.1.3 Editing a partition

When you create a new partition or modify an existing partition, you can set various parameters. For new partitions, the default parameters set by YaST are usually sufficient and do not require any modification. To edit your partition setup manually, proceed as follows:

  1. Select the partition.

  2. Click Edit to edit the partition and set the parameters:

    File system ID

    Even if you do not want to format the partition at this stage, assign it a file system ID to ensure that the partition is registered correctly. Typical values are Linux, Linux swap, Linux LVM, and Linux RAID.

    File System

    To change the partition file system, click Format Partition and select file system type in the File System list.

    SUSE Linux Enterprise Desktop supports several types of file systems. Btrfs is the Linux file system of choice for the root partition because of its advanced features. It supports copy-on-write functionality, creating snapshots, multi-device spanning, subvolumes, and other useful techniques. XFS, Ext3, and Ext4 are journaling file systems. These file systems can restore the system very quickly after a system crash, using write processes logged during the operation. Ext2 is not a journaling file system, but it is adequate for smaller partitions because it does not require much disk space for management.

    The default file system for the root partition is Btrfs. The default file system for additional partitions is XFS.

    The UDF file system can be used on optical rewritable and non-rewritable media, USB flash drives and hard disks. It is supported by multiple operating systems.

    Swap is a special format that allows the partition to be used as a virtual memory. Create a swap partition of at least 256 MB. However, if you use up your swap space, consider adding memory to your system instead of adding swap space.

    Warning
    Warning: Changing the file system

    Changing the file system and reformatting partitions irreversibly deletes all data from the partition.

    For details on the various file systems, refer to Storage Administration Guide.

    Encrypt Device

    If you activate the encryption, all data is written to the hard disk in encrypted form. This increases the security of sensitive data, but reduces the system speed, as the encryption takes some time to process. More information about the encryption of file systems is provided in Section 7.2, “Device encryption” and Book “Security and Hardening Guide”, Chapter 12 “Encrypting partitions and files”.

    Mount Point

    Specify the directory where the partition should be mounted in the file system tree. Select from YaST suggestions or enter any other name.

    Fstab Options

    Specify various parameters contained in the global file system administration file (/etc/fstab). The default settings should suffice for most setups. You can, for example, change the file system identification from the device name to a volume label. In the volume label, use all characters except / and space.

    To get persistent devices names, use the mount option Device ID, UUID or LABEL. In SUSE Linux Enterprise Desktop, persistent device names are enabled by default.

    If you prefer to mount the partition by its label, you need to define one in the Volume label text entry. For example, you could use the partition label HOME for a partition intended to mount to /home.

    If you intend to use quotas on the file system, use the mount option Enable Quota Support. This must be done before you can define quotas for users in the YaST User Management module. For further information on how to configure user quota, refer to Book “Administration Guide”, Chapter 6 “Managing users with YaST”, Section 6.3.3 “Managing quotas”.

  3. Select Finish to save the changes.

Note
Note: Resize file systems

To resize an existing file system, select the partition and use Resize. Note, that it is not possible to resize partitions while mounted. To resize partitions, unmount the relevant partition before running the partitioner.

7.1.4 Expert options

After you select a hard disk device (like sda) in the System View pane, you can access the Expert menu in the lower right part of the Expert Partitioner window. The menu contains the following commands:

Create new partition table

This option helps you create a new partition table on the selected device.

Warning
Warning: Creating a new partition table

Creating a new partition table on a device irreversibly deletes all partitions and their data from that device.

Clone this disk

This option helps you clone the device partition layout (but not the data) to other available disk devices.

7.1.5 Advanced options

After you select the host name of the computer (the top-level of the tree in the System View pane), you can access the Configure menu in the lower right part of the Expert Partitioner window. The menu contains the following commands:

Configure iSCSI

To access SCSI over IP block devices, you first need to configure iSCSI. This results in additionally available devices in the main partition list.

Configure multipath

Selecting this option helps you configure the multipath enhancement to the supported mass storage devices.

7.1.6 More partitioning tips

The following section includes a few hints and tips on partitioning that should help you make the right decisions when setting up your system.

7.1.6.1 Cylinder numbers

Note, that different partitioning tools may start counting the cylinders of a partition with 0 or with 1. When calculating the number of cylinders, you should always use the difference between the last and the first cylinder number and add one.

7.1.6.2 Using swap

Swap is used to extend the available physical memory. It is then possible to use more memory than physical RAM available. The memory management system of kernels before 2.4.10 needed swap as a safety measure. Then, if you did not have twice the size of your RAM in swap, the performance of the system suffered. These limitations no longer exist.

Linux uses a page called Least Recently Used (LRU) to select pages that might be moved from memory to disk. Therefore, running applications have more memory available and caching works more smoothly.

If an application tries to allocate the maximum allowed memory, problems with swap can arise. There are three major scenarios to look at:

System with no swap

The application gets the maximum allowed memory. All caches are freed, and thus all other running applications are slowed. After a few minutes, the kernel's out-of-memory kill mechanism activates and kills the process.

System with medium sized swap (128 MB–512 MB)

At first, the system slows like a system without swap. After all physical RAM has been allocated, swap space is used as well. At this point, the system becomes very slow and it becomes impossible to run commands from remote. Depending on the speed of the hard disks that run the swap space, the system stays in this condition for about 10 to 15 minutes until the out-of-memory kill mechanism resolves the issue. Note that you will need a certain amount of swap if the computer needs to perform a suspend to disk. In that case, the swap size should be large enough to contain the necessary data from memory (512 MB–1GB).

System with lots of swap (several GB)

It is better to not have an application that is out of control and swapping excessively in this case. If you use such application, the system will need many hours to recover. In the process, it is likely that other processes get timeouts and faults, leaving the system in an undefined state, even after terminating the faulty process. In this case, do a hard machine reboot and try to get it running again. Lots of swap is only useful if you have an application that relies on this feature. Such applications (like databases or graphics manipulation programs) often have an option to directly use hard disk space for their needs. It is advisable to use this option instead of using lots of swap space.

If your system is not out of control, but needs more swap after some time, it is possible to extend the swap space online. If you prepared a partition for swap space, add this partition with YaST. If you do not have a partition available, you can also use a swap file to extend the swap. Swap files are generally slower than partitions, but compared to physical RAM, both are extremely slow so the actual difference is negligible.

Procedure 7.2: Adding a swap file manually

To add a swap file in the running system, proceed as follows:

  1. Create an empty file in your system. For example, to add a swap file with 128 MB swap at /var/lib/swap/swapfile, use the commands:

    > sudo mkdir -p /var/lib/swap
    > sudo dd if=/dev/zero of=/var/lib/swap/swapfile bs=1M count=128
  2. Initialize this swap file with the command

    > sudo mkswap /var/lib/swap/swapfile
    Note
    Note: Changed UUID for swap partitions when formatting via mkswap

    Do not reformat existing swap partitions with mkswap if possible. Reformatting with mkswap will change the UUID value of the swap partition. Either reformat via YaST (which will update /etc/fstab) or adjust /etc/fstab manually.

  3. Activate the swap with the command

    > sudo swapon /var/lib/swap/swapfile

    To disable this swap file, use the command

    > sudo swapoff /var/lib/swap/swapfile
  4. Check the current available swap spaces with the command

    > cat /proc/swaps

    Note that at this point, it is only temporary swap space. After the next reboot, it is no longer used.

  5. To enable this swap file permanently, add the following line to /etc/fstab:

    /var/lib/swap/swapfile swap swap defaults 0 0

7.1.7 Partitioning and LVM

From the Expert Partitioner, access the LVM configuration by clicking the Volume Management item in the System View pane. However, if a working LVM configuration already exists on your system, it is automatically activated upon entering the initial LVM configuration of a session. In this case, all disks containing a partition (belonging to an activated volume group) cannot be repartitioned. The Linux kernel cannot reread the modified partition table of a hard disk when any partition on this disk is in use. If you already have a working LVM configuration on your system, physical repartitioning should not be necessary. Instead, change the configuration of the logical volumes.

At the beginning of the physical volumes (PVs), information about the volume is written to the partition. To reuse such a partition for other non-LVM purposes, it is advisable to delete the beginning of this volume. For example, in the VG system and PV /dev/sda2, do this with the command:

dd if=/dev/zero of=/dev/sda2 bs=512 count=1
Warning
Warning: File system for booting

The file system used for booting (the root file system or /boot) must not be stored on an LVM logical volume. Instead, store it on a normal physical partition.

7.2 Device encryption

Linux Unified Key Setup (LUKS) is the standard for Linux disk encryption. It provides a standardized on-disk format and enables users to transport or migrate data seamlessly.

LUKS is used to encrypt block devices. The contents of the encrypted device are arbitrary, and therefore any file system can be encrypted, including swap partitions. All necessary setup information, like encryption keys and parameters, such as cipher type and key size, is stored in the partition header.

Encryption is done with a multi-layer approach. First, the block device is encrypted using a master key. Then, this master key is encrypted with each active user keys. User keys are derived from passphrases, FIDO2 security keys, TPMs or smart cards. This multi-layer approach allows users to change their passphrase without re-encrypting the whole block device.

For more information about LUKS, refer to Book “Security and Hardening Guide”, Chapter 13 “Storage encryption for hosted applications with cryptctl”.

7.2.1 Encryption methods

To encrypt a device, follow the instructions in Section 7.1.3, “Editing a partition”.

Tip
Tip: Enabling LUKS2 support in YaST

LUKS2 encryption is supported by the YaST Partitioner as of SUSE Linux Enterprise 15 SP4, but needs to be enabled explicitly. There are two ways to do this:

  1. At boot time, by adding the parameter to YAST_LUKS2_AVAILABLE to the kernel command line. For information about boot parameters, refer to Chapter 4, Boot parameters.

  2. During installation in the YaST configuration:

    • In the graphical interface, press CtrlAltShiftC.

    • In the text interface, press CtrlD and then ShiftC.

    Check Enable Experimental LUKS2 Encryption Support and exit the configuration screen with OK.

If you do not enable LUKS2 support, the Encryption method selection is not visible and you only need to enter the encryption password.

Regular LUKS1

This method allows to encrypt the device using LUKS1. You have to provide the encryption password. Additional passwords—up to eight in total—can be added later with cryptsetup luksAddKey.

Regluar LUKS2

LUKS2 uses a newer version of the header format, which is resilient to corruption, and supports up to 32 user keys and device labels. You have to provide the encryption password and the password-based key derivation function (PBKDF) that will be used to protect that passphrase (see Section 7.2.2, “Password-based key derivation functions”).

Pervasive LUKS2 (only on IBM Z)

This method allows to encrypt the device using LUKS2 with a master secure key processed by a Crypto Express cryptographic coprocessor configured in CCA mode. If the cryptographic system already contains a secure key associated to this volume, that key will be used. Otherwise, a new secure key will be generated and registered in the system. You need to provide an encryption password that will be used to protect the access to that master key. Moreover, when there are several APQNs in the system, you can select which ones to use.

For more information about pervasive encryption, refer to https://www.ibm.com/docs/en/linux-on-systems?topic=security-pervasive-encryption.

Encryption with Volatile Random Key (only for swap devices)

This method encrypts a swap device with a randomly generated key at boot and therefore does not support hibernation to hard disk. The swap device is re-encrypted on every boot, and its previous content is destroyed. To avoid data loss, disable hibernation and configure your system to shut down instead.

In addition to the encryption key, the device label and the UUID change every time the swap is re-encrypted, so neither is a valid option to mount a randomly encrypted swap device. Make sure the swap device is referenced by a stable name that is not subject to change on every reboot in the /etc/crypttab file. For example, for a swap partition it is safer to use the udev device id or path instead of the partition device name, since that device name may be assigned to a different partition during the next boot. If that happens, a wrong device could be encrypted instead of your swap!

YaST tries to use stable names in /etc/crypttab, unless it is configured to always use device names (see the Settings section of the partitioner). But for some devices, finding a fully stable name may not be possible. Only use encryption with volatile keys if you are sure about the implications.

Protected Swap (only for swap devices)

This method encrypts a swap device with a volatile protected AES key without requiring a cryptographic coprocessor. It is an improvement over the Encryption with Volatile Random Key method and all considerations for that method still apply.

Secure Swap (only for swap devices)

This method encrypts a swap device with a volatile secure AES key generated from a cryptographic coprocessor. It is an improvement over the Encryption with Volatile Random Key method and all considerations for that method still apply.

7.2.2 Password-based key derivation functions

The password-based key derivation function (PBKDF) to use depends on the context, the hardware capabilities and the needed level of compatibility with other system components:

PBKDF2

PBKDF2 is the function that LUKS1 uses. It is defined in RFC 2898.

Argon2i

Argon2 is a function designed to be more secure and to require a lot of memory to be computed. It is defined in RFC 9106. Argon2i is a variant of Argon2 optimized to resist side-channel attacks by accessing the memory array in a password-independent order.

Argon2id

Argon2id is a hybrid version of Argon2. It follows the Argon2i approach for the first half pass over memory and the Argon2d (not supported by YaST) approach to limit GPU cracking attacks for subsequent passes. RFC 9106 recommends using Argon2id if you do not know the difference between the types or you consider side-channel attacks to be a viable threat.

While Argon2 is more secure, there are still use cases for PBKDF2:

  • As an intentional security feature, Argon2 requires a lot more memory to be computed. This may result in problems on some systems. If the strength of the password can be fully assured, then using PBKDF2 may still be secure and save memory.

  • grub2 offers limited support to boot from devices encrypted with LUKS2, but only if PBKDF2 is used. This means you cannot use Argon2 for a file system that contains the /boot directory. Note that even if PBKDF2 is used, some manual grub2 configuration may be needed to boot from a LUKS2 device.

For more information on configuring device encryption with LUKS, use the Help button in the installer and refer to Book “Security and Hardening Guide”, Chapter 13 “Storage encryption for hosted applications with cryptctl”.

7.3 LVM configuration

This section explains specific steps to take when configuring LVM.

Warning
Warning: Back up your data

Using LVM is sometimes associated with increased risk such as data loss. Risks also include application crashes, power failures, and faulty commands. Save your data before implementing LVM or reconfiguring volumes. Never work without a backup.

The YaST LVM configuration can be reached from the YaST Expert Partitioner (see Section 7.1, “Using the Expert Partitioner) within the Volume Management item in the System View pane. The Expert Partitioner allows you to manage hard disks and partitions, as well as setting up RAID and LVM configurations.

7.3.1 Create physical volume

The first task is to create physical volumes that provide space to a volume group:

  1. Select a hard disk from Hard Disks.

  2. Change to the Partitions tab.

  3. Click Add and enter the desired size of the PV on this disk.

  4. Use Do not format partition and change the File System ID to 0x8E Linux LVM. Do not mount this partition.

  5. Repeat this procedure until you have defined all the desired physical volumes on the available disks.

7.3.2 Creating volume groups

If no volume group exists on your system, you must add one (see Figure 7.3, “Creating a volume group”). It is possible to create additional groups by clicking Volume Management in the System View pane, and then on Add Volume Group. One single volume group is usually sufficient.

  1. Enter a name for the VG, for example, system.

  2. Select the desired Physical Extend Size. This value defines the size of a physical block in the volume group. All the disk space in a volume group is handled in blocks of this size.

  3. Add the prepared PVs to the VG by selecting the device and clicking Add. Selecting several devices is possible by holding Ctrl while selecting the devices.

  4. Select Finish to make the VG available to further configuration steps.

Creating a volume group
Figure 7.3: Creating a volume group

If you have multiple volume groups defined and want to add or remove PVs, select the volume group in the Volume Management list and click Resize. In the following window, you can add PVs to or remove them from the selected volume group.

7.3.3 Configuring logical volumes

After the volume group has been filled with PVs, define the LVs which the operating system should use in the next dialog. Choose the current volume group and change to the Logical Volumes tab. Add, Edit, Resize, and Delete LVs as needed until all space in the volume group has been occupied. Assign at least one LV to each volume group.

Logical volume management
Figure 7.4: Logical volume management

Click Add and go through the wizard-like pop-up that opens:

  1. Enter the name of the LV. For a partition that should be mounted to /home, a name like HOME could be used.

  2. Select the type of the LV. It can be either Normal Volume, Thin Pool, or Thin Volume. Note that you need to create a thin pool first, which can store individual thin volumes. The big advantage of thin provisioning is that the total sum of all thin volumes stored in a thin pool can exceed the size of the pool itself.

  3. Select the size and the number of stripes of the LV. If you have only one PV, selecting more than one stripe is not useful.

  4. Choose the file system to use on the LV and the mount point.

By using stripes it is possible to distribute the data stream in the LV among several PVs (striping). However, striping a volume can only be done over different PVs, each providing at least the amount of space of the volume. The maximum number of stripes equals to the number of PVs, where Stripe "1" means "no striping". Striping only makes sense with PVs on different hard disks, otherwise performance will decrease.

Warning
Warning: Striping

YaST cannot verify your entries concerning striping at this point. Mistakes made here will show later when the LVM is implemented on disk.

If you have already configured LVM on your system, the existing logical volumes can also be used. Before continuing, assign appropriate mount points to these LVs. With Finish, return to the YaST Expert Partitioner and finish your work there.

7.4 Soft RAID

This section describes actions required to create and configure various types of RAID. .

7.4.1 Soft RAID configuration

The YaST RAID configuration can be reached from the YaST Expert Partitioner, described in Section 7.1, “Using the Expert Partitioner. This partitioning tool enables you to edit and delete existing partitions and create new ones to be used with soft RAID:

  1. Select a hard disk from Hard Disks.

  2. Change to the Partitions tab.

  3. Click Add and enter the desired size of the raid partition on this disk.

  4. Use Do not Format the Partition and change the File System ID to 0xFD Linux RAID. Do not mount this partition.

  5. Repeat this procedure until you have defined all the desired physical volumes on the available disks.

For RAID 0 and RAID 1, at least two partitions are needed—for RAID 1, usually exactly two and no more. If RAID 5 is used, at least three partitions are required, RAID 6 and RAID 10 require at least four partitions. It is recommended to use partitions of the same size only. The RAID partitions should be located on different hard disks to decrease the risk of losing data if one is defective (RAID 1 and 5) and to optimize the performance of RAID 0. After creating all the partitions to use with RAID, click RAID › Add RAID to start the RAID configuration.

In the next dialog, choose between RAID levels 0, 1, 5, 6 and 10. Then, select all partitions with either the Linux RAID or Linux native type that should be used by the RAID system. No swap or DOS partitions are shown.

RAID partitions
Figure 7.5: RAID partitions

To add a previously unassigned partition to the selected RAID volume, first click the partition then Add. Assign all partitions reserved for RAID. Otherwise, the space on the partition remains unused. After assigning all partitions, click Next to select the available RAID Options.

In this last step, set the file system to use, encryption and the mount point for the RAID volume. After completing the configuration with Finish, see the /dev/md0 device and others indicated with RAID in the Expert Partitioner.

7.4.2 Troubleshooting

Check the file /proc/mdstat to find out whether a RAID partition is damaged. If the system fails, shut down the machine and replace the defective hard disk with a new one partitioned the same way. Then restart your system and run mdadm /dev/mdX --add /dev/sdX. Replace 'X' with your particular device identifiers. This integrates the hard disk automatically into the RAID system and fully reconstructs it.

Note that although you can access all data during the rebuild, you may encounter some performance issues until the RAID has been fully rebuilt.

7.4.3 More information

Configuration instructions and more details for soft RAID can be found at:

Linux RAID mailing lists are available, such as https://marc.info/?l=linux-raid.

8 Remote installation

The installation of SUSE® Linux Enterprise Desktop can be performed entirely over the network. This chapter describes how to provide the required environment for booting, installing and controlling the installation via the network.

8.1 Overview

For a remote installation you need to consider how to boot, how to control the installation, and the source of the installation data. All available options can be combined with each other, if they are available for your hardware platform.

Boot method

Depending on the hardware, several options for booting a system exist. Common options are DVD, USB drive or PXE boot. For more information about your platform, refer to Part I, “Installation preparation”.

Data source

Most commonly, DVDs or USB drives are used as a source for installing SUSE Linux Enterprise Desktop. Alternatively, installation servers can be used. In this case, use the install boot parameter to specify the source. For details, refer to Section 4.3.3, “Specifying the installation source”.

Installation methods

Instead of using a keyboard and monitor directly attached to the target machine, the installation can be performed via SSH, VNC, or by using the serial console of a machine. This is described in the sections Section 8.3, “Monitoring installation via VNC”, Section 8.4, “Monitoring installation via SSH” and Section 8.5, “Installation via serial console”.

8.2 Scenarios for remote installation

This section introduces the most common installation scenarios for remote installations. For each scenario, carefully check the list of prerequisites and follow the procedure outlined for that scenario. If in need of detailed instructions for a particular step, follow the links provided for each one of them.

8.2.1 Installation from source media via VNC

This type of installation still requires some degree of physical access to the target system to boot for installation. The installation is controlled by a remote workstation using VNC to connect to the installation program. User interaction is required as with the manual installation in Chapter 5, Installation steps.

For this type of installation, make sure that the following requirements are met.

  • Target system with a working network connection.

  • Controlling system with a working network connection and VNC viewer software or JavaScript-enabled browser (Firefox, Chromium, Internet Explorer, Opera, etc.).

  • Installation DVD or USB flash drive.

To perform this kind of installation, proceed as follows:

  1. Boot the target system using the installation medium (USB flash drive) of the SUSE Linux Enterprise Desktop media kit.

  2. When the boot screen of the target system appears, use the boot parameters prompt to set the VNC options and static network configuration, if required. For information about boot parameters, see Chapter 4, Boot parameters.

    1. Boot parameters for a static network configuration:

      netdevice=NETDEVICE hostip=IP_ADDRESS netmask=NETMASK gateway=IP_GATEWAY vnc=1 VNCPassword=PASSWORD
    2. Boot parameters for a dynamic (DHCP) network configuration:

      vnc=1 VNCPassword=PASSWORD
  3. The target system boots to a text-based environment and shows the network address and display number. VNC installations announce themselves over OpenSLP, provided the firewall settings are configured appropriately. They can be found using slptool as described in Section 8.3.1, “Preparing for VNC installation”.

  4. On the controlling workstation, open a VNC viewer or Web browser and connect to the target system using the provided network address and display number as described in Section 8.3, “Monitoring installation via VNC”.

  5. Perform the installation as described in Chapter 5, Installation steps.

8.2.2 Network installation using VNC

This type of installation does not require a direct interaction with the target machine. The system is booted via PXE and the installation data is fetched from a server.

To perform this type of installation, make sure that the following requirements are met.

  • At least one machine that can be used for installing a DHCP, NFS, HTTP, FTP, TFTP, or SMB server.

  • Target system capable of PXE boot, networking, and Wake on LAN, plugged in and connected to the network.

  • Controlling system with a working network connection and VNC viewer software or JavaScript-enabled browser (Firefox, Chromium, Microsoft Edge, Opera, etc.).

To perform this type of installation, proceed as follows.

  1. Set up the server that contains the installation data.

  2. Set up a DHCP and TFTP server for the network. Add the required boot parameters to enable the VNC server.

  3. Enable PXE boot in the target machine firmware.

  4. Initiate the boot process of the target system using Wake on LAN.

  5. On the controlling workstation, open a VNC viewing application or Web browser and connect to the target system.

  6. Perform the installation as described in Chapter 5, Installation steps.

8.2.3 Installation from source media via SSH

This type of installation still requires some degree of physical access to the target system to boot for installation and to determine the IP address of the installation target. The installation itself is entirely controlled from a remote workstation using SSH to connect to the installer. User interaction is required as with the regular installation described in Chapter 5, Installation steps.

For this type of installation, make sure that the following requirements are met.

  • Target system with working network connection.

  • Controlling system with working network connection and working SSH client software.

  • Installation DVD or USB flash drive.

To perform this kind of installation, proceed as follows:

  1. Set up the installation target and installation server.

  2. Boot the target system using the installation medium (USB flash drive) of the SUSE Linux Enterprise Desktop media kit.

  3. When the boot screen of the target system appears, use the boot parameters prompt to set the SSH options and, if required, the static network configuration. For information about boot parameters, see Chapter 4, Boot parameters.

    1. Boot parameters for a static network configuration:

      netdevice=NETDEVICE hostip=IP_ADDRESS netmask=NETMASK gateway=IP_GATEWAY ssh=1 ssh.password=PASSWORD
    2. Boot parameters for a dynamic (DHCP) network configuration:

      ssh=1 ssh.password=PASSWORD
  4. The target system boots to a text-based environment, giving the network address under which the graphical installation environment can be addressed by any SSH client.

  5. On the controlling workstation, open a terminal window and connect to the target system as described in Section 8.4.2, “Connecting to the installation program”.

  6. Perform the installation as described in Chapter 5, Installation steps.

8.2.4 Installation from network via SSH

This type of installation does not require a direct interaction with the target machine. The system is booted via PXE and the installation data is fetched from a server.

To perform this type of installation, make sure that the following requirements are met:

  • At least one machine that can be used for installing a DHCP, NFS, HTTP, FTP, TFTP, or SMB server.

  • Target system capable of PXE boot, networking, and Wake on LAN, plugged in and connected to the network.

  • Controlling system with working network connection and SSH viewer software.

To perform this type of installation, proceed as follows.

  1. Set up the server that contains the installation data.

  2. Set up a DHCP and TFTP server for the network. Add the required boot parameters to enable the SSH server.

  3. Enable PXE boot in the target machine firmware.

  4. Initiate the boot process of the target system using Wake on LAN.

  5. On the controlling workstation, open an SSH client software and connect to the target system.

  6. Perform the installation as described in Chapter 5, Installation steps.

8.3 Monitoring installation via VNC

Using a VNC viewer, you can remotely control the installation of SUSE Linux Enterprise Desktop from virtually any operating system. This section introduces the setup using a VNC viewer or a Web browser.

8.3.1 Preparing for VNC installation

To enable VNC on the installation target, specify the appropriate boot parameters at the initial boot for installation (see Chapter 4, Boot parameters). The target system boots into a text-based environment and waits for a VNC client to connect to the installation program.

The installation program announces the IP address and display number needed to connect for installation. If you have physical access to the target system, this information is provided right after the system booted for installation. Enter this data when your VNC client software prompts for it and provide your VNC password.

Because the installation target announces itself via OpenSLP, you can retrieve the address information of the installation target via an SLP browser. There is no need for physical access to the installation target provided your network setup and all machines support OpenSLP:

Procedure 8.1: Locating VNC installations via OpenSLP
  1. Run slptool findsrvtypes | grep vnc to get a list of all services offering VNC. The VNC installation targets should be available under a service named YaST.installation.suse.

  2. Run slptool findsrvs YaST.installation.suse to get a list of installations available. Use the IP address and the port (usually 5901) provided with your VNC viewer.

8.3.2 Connecting to the installation program

There are two ways to connect to a VNC server (the installation target in this case). You can either start a VNC viewer or connect using a JavaScript-enabled Web browser.

Using VNC, you can install a Linux system from any other operating system, including other Linux distributions, Windows, or macOS.

On a Linux machine, make sure that the package tightvnc is installed. On a Windows machine, install the Windows port of this application (see https://www.tightvnc.com/download.html).

To connect to the installer running on the target machine, proceed as follows.

  1. Start the VNC viewer.

  2. Enter the IP address and display number of the installation target:

    IP_ADDRESS:DISPLAY_NUMBER

    This opens a window displaying the YaST screen as in a regular local installation.

Instead of a VNC viewer, you can use a JavaScript-enabled browser that has JavaScript support enabled to perform the installation.

Note that the browser VNC connection is not encrypted.

To perform a VNC installation, proceed as follows.

  1. Launch the Web browser and enter the following at the address prompt:

    http://IP_ADDRESS_OF_TARGET:5801
  2. When prompted, enter the VNC password. This opens a window with the YaST screen as in a regular local installation.

8.4 Monitoring installation via SSH

Using an SSH client, you can perform the installation remotely via SSH.

8.4.1 Preparing for SSH installation

In addition to installing the required software package (OpenSSH for Linux and PuTTY for Windows), you need to specify the appropriate boot parameters to enable SSH for installation. See Chapter 4, Boot parameters for details. OpenSSH is installed by default on any SUSE Linux–based operating system.

8.4.2 Connecting to the installation program

After you have started the SSH installation, use this procedure to connect to the SSH session.

  1. Retrieve the installation target's IP address. If you have physical access to the target machine, obtain the IP address that the installation routine provides from the console after the initial boot. Otherwise, obtain the IP address that has been assigned to the target machine in the DHCP server configuration.

  2. Run the following command in the terminal:

    ssh -X root@TARGET_IP_ADDRESS

    Replace TARGET_IP_ADDRESS with the actual IP address of the installation target.

  3. When prompted for a user name, enter root.

  4. When prompted, enter the password that has been set with the SSH boot parameter. If the authentication is successful, you should see a command-line prompt for the installation target appear.

  5. Enter yast to launch the installation program. This opens a window showing the YaST screen as described in Chapter 5, Installation steps.

8.5 Installation via serial console

For this installation method, you need a computer connected by a null modem cable to the target machine where SUSE Linux Enterprise Desktop will be installed. Both machines must support the serial console. Certain firmware implementations are already configured to send the boot console output to a serial console. In this case, no additional configuration is required.

If the firmware does not use the serial console for the boot console output, set the following boot parameter for the installation: console=TTY,BAUDRATE. For further information, see Chapter 4, Boot parameters.

BAUDRATE needs to be replaced by the baud rate for the interface. Valid values are 115200, 38400, or 9600. TTY needs to be replaced by the name of the interface. On most computers, there is one or more serial interfaces. Depending on the hardware, the names of the interfaces may vary:

  • ttyS0 for APM

  • ttyAMA0 for Server Base System Architecture (SBSA)

  • ttyPS0 for Xilinx

For the installation, you need a terminal program like minicom or screen. To initiate the serial connection, launch the screen program in a local console by entering the following command:

> screen /dev/ttyUSB0 115200

This means that screen listens to the first serial port with a baud rate of 115200. From this point on, the installation proceeds similarly to the text-based installation over this terminal.

9 Troubleshooting

This section covers several common installation problems and describes possible solutions.

9.1 Checking media

If you encounter any problems using the SUSE Linux Enterprise Desktop installation media, check its integrity. Boot from the media and choose More › Check Installation Media from the boot menu. A minimal system boots and lets you choose which device to check. Select the respective device and confirm with OK to perform the check.

On a running system, start YaST and choose Software › Media Check. Insert the medium and click Start Check. The integrity check may take time.

If errors are detected during the check, do not use this medium for installation. Media problems may, for example, occur when having burned the medium on DVD yourself. Burning the media at a low speed (4x) helps to avoid problems.

9.2 No bootable drive available

If your computer cannot boot from USB or DVD drive, you have several alternatives.

Using an external USB flash drive or DVD drive

Linux supports most existing USB flash drives and DVD drives. If the system has no USB flash drive or DVD drive, it is still possible that an external drive, connected through USB, FireWire, or SCSI, can be used to boot the system. Sometimes a firmware update may help if you encounter problems.

Network boot via PXE

If the machine lacks both a USB flash drive and DVD drive, but it has a working Ethernet connection, you can perform a network-based installation. See Section 8.2.2, “Network installation using VNC” and Section 8.2.4, “Installation from network via SSH” for details.

USB flash drive

You can use a USB flash drive if the machine lacks a DVD drive and a network connection. For details, see:

9.3 Booting from installation media fails

The machine may fail to boot from the installation media due to an incorrect boot sequence setting in BIOS. The USB flash drive or DVD drive must be set as the first boot device in the BIOS boot sequence.

Procedure 9.1: Changing the BIOS boot sequence
  1. Enter the BIOS using the proper key shown by the boot routines and wait for the BIOS screen to appear.

  2. To change the boot sequence in an AWARD BIOS, look for the BIOS FEATURES SETUP entry. Other manufacturers may have a different name for this, such as ADVANCED CMOS SETUP. When you have found the entry, select it and confirm with Enter.

  3. Look for a subentry called BOOT SEQUENCE or BOOT ORDER. Change the settings by pressing Page ↑ or Page ↓ until the USB flash drive or DVD drive is listed first.

  4. Exit the BIOS setup screen by pressing Esc. To save the changes, select SAVE & EXIT SETUP, or press F10. To save the modified settings, press Y.

Procedure 9.2: Changing the boot sequence in an SCSI BIOS (Adaptec host adapter)
  1. Open the setup by pressing CtrlA.

  2. Select Disk Utilities. The connected hardware components are now displayed.

    Make note of the SCSI ID of your USB flash drive or DVD drive.

  3. Exit the menu with Esc.

  4. Open Configure Adapter Settings. Under Additional Options, select Boot Device Options and press Enter.

  5. Enter the ID of the USB flash drive or DVD drive and press Enter again.

  6. Press Esc twice to return to the start screen of the SCSI BIOS.

  7. Exit this screen and confirm with Yes to boot the computer.

Regardless of what language and keyboard layout the installed system will be using, most BIOS configurations use the US keyboard layout as shown below.

US keyboard layout
Figure 9.1: US keyboard layout

9.4 Boot failure

Some hardware types, mainly very old or very recent ones, fail to boot. Reasons can be missing support for hardware in the installation kernel or drivers causing problems on some specific hardware.

If installation fails using the standard Installation mode, try the following.

  1. With the installation media still in the drive, reboot the machine with CtrlAltDel or using the hardware reset button.

  2. When the boot screen appears, press F5, use the arrow keyboard keys to navigate to No ACPI, and press Enter to boot and initiate the installation process. This option disables the support for ACPI power management techniques.

  3. Proceed with the installation as described in Chapter 5, Installation steps.

If this fails, proceed as above, but choose Safe Settings instead. This option disables ACPI and DMA support. This option works with most hardware.

If both options fail, use the boot parameters prompt to specify the kernel parameters to enable support for the hardware in use. For more information about the parameters available as boot parameters, refer to the kernel documentation located in /usr/src/linux/Documentation/kernel-parameters.txt.

Tip
Tip: Obtaining kernel documentation

Install the kernel-source package to view the kernel documentation.

There are other ACPI-related kernel parameters that can be entered at the boot prompt prior to booting for installation:

acpi=off

This parameter disables the complete ACPI subsystem on your computer. This may be useful if your computer cannot handle ACPI or if you think ACPI in your computer causes trouble.

acpi=force

Always enable ACPI even if your computer has a BIOS released before 2000. This parameter also enables ACPI if it is set in addition to acpi=off.

acpi=noirq

Do not use ACPI for IRQ routing.

acpi=ht

Run only enough ACPI to enable hyper-threading.

acpi=strict

Be less tolerant of platforms that are not strictly ACPI-compliant.

pci=noacpi

Disable PCI IRQ routing of the new ACPI system.

pnpacpi=off

Enable this option to avoid issues caused by incorrectly configured device resources in BIOS.

notsc

Disable the time stamp counter. This option can be used to work around timing problems on your systems. It is a recent feature, so if you see regressions on your machine, especially time related or even total hangs, this option is worth a try.

nohz=off

Disable the nohz feature. If your machine hangs, enabling this option may help.

When you have determined the right parameter combination, YaST automatically writes them to the boot loader configuration to make sure that the system boots properly next time.

If errors occur when the kernel is loaded or during the installation, select Memory Test in the boot menu to check the memory. If Memory Test returns an error, this usually indicates a hardware error.

9.5 Graphical installer fails to start

The machine boots into the installation interface, and the graphical installer does not start when you select Installation.

There are several ways to deal with this situation.

  • Select another screen resolution for the installation dialogs.

  • Select Text Mode for installation.

  • Perform a remote installation via VNC using the graphical installer.

Procedure 9.3: Change screen resolution for installation
  1. Boot for installation.

  2. Press F3 to open a menu from which to select a lower resolution for installation purposes.

  3. Select Installation and proceed with the installation as described in Chapter 5, Installation steps.

Procedure 9.4: Installation in text mode
  1. Boot for installation.

  2. Press F3 and select Text Mode.

  3. Select Installation and proceed with the installation as described in Chapter 5, Installation steps.

Procedure 9.5: VNC installation
  1. Boot for installation.

  2. Enter the following text at the boot parameters prompt:

    vnc=1 vncpassword=SOME_PASSWORD

    Replace SOME_PASSWORD with the password to use for VNC installation.

  3. Select Installation then press Enter to start the installation.

    Instead of starting right into the graphical installation routine, the system continues to run in a text mode. The system then halts, displaying a message containing the IP address and port number at which the installer can be reached via a browser interface or a VNC viewer application.

  4. When using a browser to access the installer, launch the browser and enter the address information provided by the installation routines on the future SUSE Linux Enterprise Desktop machine and press Enter:

    http://IP_ADDRESS_OF_MACHINE:5801

    A dialog opens in the browser window prompting you for the VNC password. Enter it and proceed with the installation as described in Chapter 5, Installation steps.

    Important
    Important: Cross-platform support

    Installation via VNC works with any browser under any operating system, provided Java support is enabled.

    Provide the IP address and password to your VNC viewer when prompted. A window opens, displaying the installation dialogs. Proceed with the installation as usual.

9.6 Only minimal boot screen is displayed

You inserted the medium into the drive, the BIOS routines are finished, and the system launches a minimal, text-based interface. This may happen on any machine that does not have sufficient graphics memory for rendering a graphical boot screen.

Although the text boot screen looks minimal, it provides nearly the same functionality as the graphical one.

Boot options

Unlike the graphical interface, the different boot parameters cannot be selected using the cursor keys of your keyboard. The boot menu of the text-mode boot screen provides keywords that can be entered at the boot prompt. These keywords match the options in the graphical version. Enter your choice and press Enter to launch the boot process.

Custom boot options

After selecting a boot parameter, enter the appropriate keyword at the boot prompt or enter some custom boot parameters as described in Section 9.4, “Boot failure”. To launch the installation process, press Enter.

Screen resolutions

Use the function keys (F1 ... F12) to determine the screen resolution for installation. If you need to boot in text mode, choose F3.

Part III Customizing installation images

10 Prepare a disk for cloning with the system cleanup tool

The clone-master-clean-up tool that ships with SUSE Linux Enterprise Desktop makes it possible to remove data from the disk that you do not want to include in a clone. This chapter describes how to use the tool.

10.1 Cleaning up unique system identifiers

Warning
Warning: Do not use the tool on a production system

As the cleanup tool removes essential system configuration data, it is not recommended to use it on a system that is used in production. Run the tool on the cloned image instead.

The clone-master-clean-up tool removes the following data:

  • swap files

  • Zypper repositories

  • SSH host and client keys

  • temporary directories, like /tmp/*

  • Postfix data

  • HANA firewall script

  • systemd journal

  1. To install clone-master-clean-up, run the following command:

    > sudo zypper install clone-master-clean-up
  2. Configure the tool by editing the /etc/sysconfig/clone-master-clean-up file. Here, you can specify which specific data the tool should remove.

  3. Run the script to perform a cleanup:

    > sudo clone-master-clean-up

11 Customizing installation images with mksusecd

mksusecd is a useful tool for creating a customized installation image. Use it to modify the regular SUSE Linux Enterprise installation images, add or remove files, create a minimal network installation image, customize boot options or software repositories, and create a minimal boot image as an alternative to booting a system from a PXE server.

11.1 Installing mksusecd

In SLE 15, mksusecd is in the Development Tools module. If this module is not enabled, you must enable it first. Find the exact module name and SUSEConnect activation command with zypper:

> zypper search-packages mksusecd
Following packages were found in following modules:

Package              Module or Repository
-------------------- -------------------------------------------------------------------
---------------------- -----------------------------------------------------------------
mksusecd             Development Tools Module (sle-module-development-tools/15.4/x86_64)
                       SUSEConnect --product sle-module-development-tools/15.4/x86_64

To activate the respective module or product, use SUSEConnect --product.
Use SUSEConnect --help for more details.

Enable the module with SUSEConnect:

> sudo SUSEConnect --product sle-module-development-tools/15.4/x86_64

Install mksusecd:

> sudo zypper in mksusecd

Run mksusecd --help to see a complete list of commands.

After you create your custom image, either burn it to a CD/DVD medium using your preferred disk-writing program, or create a bootable USB flash drive using the dd command. Make sure the device is not mounted, then run the following command:

# dd if=myinstaller.iso of=/dev/SDB bs=4M

Then your new bootable device is ready to use.

11.2 Creating a minimal boot image

Use mksusecd to create a minimal boot image to start client machines from a CD/DVD or USB flash drive, instead of starting them from a PXE boot server. The minimal boot image launches the kernel and initrd, and then the remaining installation files are fetched from a local NFS server (see Section 13.1, “Setting up an installation server using YaST”).

Run the following command to create the minimal ISO image:

> sudo mksusecd --create min-install.iso \
--net=nfs://192.168.1.1:/srv/install/ARCH/OS_VERSION/SP_VERSION/cd1  \
/srv/tftpboot/EFI/ARCH/boot

Replace the NFS server address with your own. Replace ARCH with the directory corresponding to the target system architecture. Also replace OS_version and SP_VERSION (service pack) according to your paths in Section 13.1, “Setting up an installation server using YaST”.

11.3 Setting default kernel boot parameters

Rather than waiting for a boot prompt to enter your custom kernel boot parameters, configure them in a custom mksusecd image:

> sudo mksusecd --create install.iso \
--boot "textmode=1 splash=silent mitigations=auto"

Verify that your custom parameters load correctly after start-up by querying /proc:

> cat /proc/cmdline

11.4 Customizing modules, extensions, and repositories

SUSE Linux Enterprise 15 supports Modules (not to be confused with kernel modules) and Extensions for different product components. These are add-ons to the default Basesystem, such as Development Tools, Desktop Applications, and SUSE Linux Enterprise Live Patching. For more information refer to the Modules and Extensions Quick Start guide.

With mksusecd you can create an installation image containing all additional Modules and Extensions you want. Start by querying existing images, like this example for SUSE Linux Enterprise 15 SP6:

> sudo mksusecd --list-repos SLE-15-SP6-Full-ARCH-GM-media1.iso
Repositories:
  Basesystem-Module [15.6-0]
  SUSE-CAP-Tools-Module [15.6-0]
  Containers-Module [15.6-0]
  Desktop-Applications-Module [15.6-0]
  Development-Tools-Module [15.6-0]
  HPC-Module [15.6-0]
  Legacy-Module [15.6-0]
  Live-Patching [15.6-0]
  Public-Cloud-Module [15.6-0]
  Python2-Module [15.6-0]
  SAP-Applications-Module [15.6-0]
  Server-Applications-Module [15.6-0]
  Transactional-Server-Module [15.6-0]
  Web-Scripting-Module [15.6-0]
  SLEHA15-SP6 [15.6-0]
  SLE-15-SP6-HPC [15.6-0]
  SLED15-SP6 [15.6-0]
  SLES15-SP6 [15.6-0]
  SLE-15-SP6-SAP [15.6-0]
  SLEWE15-SP6 [15.6-0]
  [...]

Create a new installation image that is built from the Modules, Extensions, and repositories that you select, and automatically enable them:

> sudo mksusecd --create myinstaller.iso --enable-repos auto \
--include-repos Basesystem-Module,Desktop-Applications-Module \
SLE-15-SP6-Full-ARCH-GM-media1.iso

This example creates an image for installation from the internet. To create an image for offline installation, additionally add the repository of the base product, for example SLES15-SP6 for SUSE Linux Enterprise Server.

> sudo mksusecd --create myinstaller.iso --enable-repos auto \
   --include-repos SLES15-SP6,Basesystem-Module,Desktop-Applications-Module \
   SLE-15-SP6-Full-ARCH-GM-media1.iso

Replace --enable-repos auto with --enable-repos ask to have the installer present a dialog for choosing modules.

Note
Note: AutoYaST control file

When using the --enable-repos option, mksusecd adds an add_on_products.xml file for use with AutoYaST to the new image. Modules in this file do not need to be listed in the in the AutoYaST control file.

11.5 Creating a minimal netinstall ISO

To create a minimal installation image to launch a network installation, use the --nano option:

> sudo mksusecd --create netinstall.iso \
--nano SLE-15-SP6-Online-ARCH-GM-media1.iso

11.6 Change default repository

To set a different repository, such as your own local repository, use the --net option:

> sudo mksusecd --create localinstall.iso \
--net "https://example.com/local" SLE-15-SP6-Online-ARCH-GM-media1.iso

12 Customizing installation images manually

You can customize the standard SUSE Linux Enterprise installation images by editing a file in the installation ISO image, media.1/products. Add modules and extensions to create a single customized installation image. Then copy your custom image to a CD, DVD, or USB flash drive to create a customized bootable installation medium. See the SUSE Best Practices paper on How to Create a Custom Installation Medium for SUSE Linux Enterprise 15 for complete instructions.

Part IV Setting up an installation server

13 Setting up a network installation source

This chapter describes how to create a server that provides the data required for installing SUSE Linux Enterprise Desktop over the network.

Depending on the operating system of the machine used as the network installation source for SUSE Linux Enterprise Desktop, there are several options for the server configuration. The easiest way to set up an installation server is to use YaST.

Tip
Tip: Installation server operating system

You can even use a Microsoft Windows machine as the installation server for your Linux deployment. See Section 13.5, “Managing an SMB repository” for details.

13.1 Setting up an installation server using YaST

YaST offers a graphical tool for creating network repositories. It supports HTTP, FTP, and NFS network installation servers.

  1. Log in to the machine that should act as installation server.

  2. Install the package yast2-instserver:

    > sudo zypper in yast2-instserver
  3. Start YaST › Miscellaneous › Installation Server.

  4. Select the repository type (HTTP, FTP, or NFS). The selected service is started automatically every time the system starts. If a service of the selected type is already running on your system and you want to configure it manually for the server, deactivate the automatic configuration of the server service with Do Not Configure Any Network Services. In both cases, define the directory in which the installation data should be made available on the server.

  5. Configure the required repository type. This step relates to the automatic configuration of server services. It is skipped when automatic configuration is deactivated.

    Define an alias for the root directory of the FTP or HTTP server on which the installation data should be found. The repository will later be located under ftp://Server-IP/Alias/Name (FTP) or under http://Server-IP/Alias/Name (HTTP). Name stands for the name of the repository, which is defined in the following step. If you selected NFS in the previous step, define wild cards and export options. The NFS server will be accessible under nfs://Server-IP/Name.

    Tip
    Tip: Firewall settings

    Make sure that the firewall settings of your server system allow traffic on ports for HTTP, NFS, and FTP. If they currently do not, enable Open Port in Firewall or check Firewall Details first.

  6. Configure the repository. Before the installation media are copied to their destination, define the name of the repository (ideally, an easily remembered abbreviation of the product and version). YaST allows providing ISO images of the media instead of copies of the installation DVDs. If you want this, activate the relevant check box and specify the directory path under which the ISO files can be found locally. Depending on the product to distribute using this installation server, it might be necessary to add media, such as service pack DVDs as extra repositories. To announce the installation server on the network via OpenSLP, activate the appropriate option.

    Tip
    Tip: Announcing the repository

    Consider announcing your repository via OpenSLP if your network setup supports this option. This saves you from entering the network installation path on every target machine. The target systems are booted using the SLP boot parameter and find the network repository without any further configuration. For details on this option, refer to Chapter 4, Boot parameters.

  7. Configuring extra repositories. YaST follows a specific naming convention to configure add-on CD or service pack CD repositories. Configuration is accepted only if the repository name of the add-on CDs starts with the repository name of the installation media. In other words, if you chose SLES12SP1 as repository name for DVD1 then you should select SLES12SP1addon as repository name for DVD2.

  8. Upload the installation data. The most lengthy step in configuring an installation server is copying the actual installation media. Insert the media in the sequence requested by YaST and wait for the copying procedure to end. When the sources have been fully copied, return to the overview of existing repositories and close the configuration by selecting Finish.

    Your installation server is now fully configured and ready for service. It is automatically started every time the system is started. No further intervention is required. You only need to configure and start this service correctly manually if you deactivated the automatic configuration of the selected network service with YaST as an initial step.

To deactivate a repository, select the repository to remove then select Delete. The installation data are removed from the system. To deactivate the network service, use the respective YaST module.

If your installation server needs to provide the installation data for more than one product of the product version, start the YaST installation server module. Then select Add in the overview of existing repositories to configure the new repository.

Warning
Warning: YaST installation server will conflict with RMT server

Configuring a server to be an installation server with YaST automatically installs and configures the Apache Web server, listening on port 80.

However, configuring a machine to be an RMT server (Repository Mirroring Tool) automatically installs the NGINX Web server and configures it to listen on port 80.

Do not try to enable both these functions on the same server. It is not possible for a single server to host both simultaneously.

13.2 Setting up an NFS repository manually

Important
Important

This assumes that you are using some kind of SUSE Linux-based operating system on the machine that will serve as installation server. If this is not the case, turn to the other vendor's documentation on NFS instead of following these instructions.

Setting up an NFS source for installation is done in two main steps. First, create the directory structure holding the installation data and copy the installation media over to this structure. Second, export the directory holding the installation data to the network.

To create a directory to hold the installation data, proceed as follows:

  1. Log in as root.

  2. Create a directory that will hold all installation data and change into this directory. For example:

    # mkdir -p /srv/install/PRODUCT/PRODUCTVERSION
    # cd /srv/install/PRODUCT/PRODUCTVERSION

    Replace PRODUCT with an abbreviation of the product name and PRODUCTVERSION with a string that contains the product name and version (for example, /srv/install/SLES/15.1).

  3. For each installation medium contained in the media kit, execute the following commands:

    1. Copy the entire content of the installation medium into the installation server directory:

      # cp -a /media/PATH_TO_YOUR_MEDIA_DRIVE .

      Replace PATH_TO_YOUR_MEDIA_DRIVE with the actual mount point of the installation medium.

    2. Rename the directory to the medium number:

      # mv PATH_TO_YOUR_MEDIA_DRIVE DVDX

      Replace X with the actual number of the installation medium.

On SUSE Linux Enterprise Desktop, you can export the repository with NFS using YaST. Proceed as follows:

  1. Log in as root.

  2. Start YaST › Network Services › NFS Server.

  3. Select Start and Open Port in Firewall and click Next.

  4. Select Add Directory and browse for the directory containing the installation sources, in this case, PRODUCTVERSION.

  5. Select Add Host and enter the host names of the machines to which to export the installation data. Instead of specifying host names here, you could also use wild cards, ranges of network addresses, or the domain name of your network. Enter the appropriate export options or leave the default, which works fine in most setups. For more information about the syntax used in exporting NFS shares, read the exports man page.

  6. Click Finish. The NFS server holding the SUSE Linux Enterprise Desktop repository is automatically started and integrated into the boot process.

To export the repository manually via NFS instead of using the YaST NFS Server module, proceed as follows:

  1. Log in as root.

  2. Open the file /etc/exports and enter the following line:

    /PRODUCTVERSION *(ro,root_squash,sync)

    This exports the directory /PRODUCTVERSION to any host that is part of this network or to any host that can connect to this server. To limit the access to this server, use netmasks or domain names instead of the general wild card *. Refer to the export man page for details. Save and exit this configuration file.

  3. To add the NFS service to the list of servers started during system boot, execute the following commands:

    # systemctl enable nfsserver
  4. Start the NFS server with systemctl start nfsserver. If you need to change the configuration of your NFS server later, modify the configuration file and restart the NFS daemon with systemctl restart nfsserver.

Announcing the NFS server via OpenSLP makes its address known to all clients in your network.

  1. Log in as root.

  2. Create the /etc/slp.reg.d/install.suse.nfs.reg configuration file with the following lines:

    # Register the NFS Installation Server
    service:install.suse:nfs://$HOSTNAME/PATH_TO_REPOSITORY/DVD1,en,65535
    description=NFS Repository

    Replace PATH_TO_REPOSITORY with the actual path to the installation source on your server.

  3. Start the OpenSLP daemon with systemctl start slpd.

13.3 Setting up an FTP repository manually

Creating an FTP repository is very similar to creating an NFS repository. An FTP repository can be announced over the network using OpenSLP as well.

  1. Create a directory holding the installation sources as described in Section 13.2, “Setting up an NFS repository manually”.

  2. Configure the FTP server to distribute the contents of your installation directory:

    1. Log in as root and install the package vsftpd using the YaST software management.

    2. Enter the FTP server root directory:

      # cd /srv/ftp
    3. Create a subdirectory holding the installation sources in the FTP root directory:

      # mkdir REPOSITORY

      Replace REPOSITORY with the product name.

    4. Mount the contents of the installation repository into the change root environment of the FTP server:

      # mount --bind PATH_TO_REPOSITORY /srv/ftp/REPOSITORY

      Replace PATH_TO_REPOSITORY and REPOSITORY with values matching your setup. If you need to make this permanent, add it to /etc/fstab.

    5. Start vsftpd with vsftpd.

  3. Announce the repository via OpenSLP, if this is supported by your network setup:

    1. Create the /etc/slp.reg.d/install.suse.ftp.reg configuration file with the following lines:

      # Register the FTP Installation Server
      service:install.suse:ftp://$HOSTNAME/REPOSITORY/DVD1,en,65535
      description=FTP Repository

      Replace REPOSITORY with the actual name of the repository directory on your server. The service: line should be entered as one continuous line.

    2. Start the OpenSLP daemon with systemctl start slpd.

13.4 Setting up an HTTP repository manually

Creating an HTTP repository is very similar to creating an NFS repository. An HTTP repository can be announced over the network using OpenSLP as well.

  1. Create a directory holding the installation sources as described in Section 13.2, “Setting up an NFS repository manually”.

  2. Configure the HTTP server to distribute the contents of your installation directory:

    1. Install the Web server Apache.

    2. Enter the root directory of the HTTP server (/srv/www/htdocs) and create the subdirectory that will hold the installation sources:

      # mkdir REPOSITORY

      Replace REPOSITORY with the product name.

    3. Create a symbolic link from the location of the installation sources to the root directory of the Web server (/srv/www/htdocs):

      # ln -s /PATH_TO_REPOSITORY/srv/www/htdocs/REPOSITORY
    4. Modify the configuration file of the HTTP server (/etc/apache2/default-server.conf) to make it follow symbolic links. Replace the following line:

      Options None

      with

      Options Indexes FollowSymLinks
    5. Reload the HTTP server configuration using systemctl reload apache2.

  3. Announce the repository via OpenSLP, if this is supported by your network setup:

    1. Create the /etc/slp.reg.d/install.suse.http.reg configuration file with the following lines:

      # Register the HTTP Installation Server
      service:install.suse:http://$HOSTNAME/REPOSITORY/DVD1/,en,65535
      description=HTTP Repository

      Replace REPOSITORY with the actual path to the repository on your server. The service: line should be entered as one continuous line.

    2. Start the OpenSLP daemon using systemctl start slpd.

13.5 Managing an SMB repository

Using SMB, you can import the installation sources from a Microsoft Windows server and start your Linux deployment even with no Linux machine around.

To set up an exported Windows Share holding your SUSE Linux Enterprise Desktop repository, proceed as follows:

  1. Log in to your Windows machine.

  2. Create a new directory that will hold the entire installation tree and name it INSTALL, for example.

  3. Export this share according to the procedure outlined in your Windows documentation.

  4. Enter this share and create a subdirectory, called PRODUCT. Replace PRODUCT with the actual product name.

  5. Enter the INSTALL/PRODUCT directory and copy each medium to a separate directory, such as DVD1 and DVD2.

To use an SMB mounted share as a repository, proceed as follows:

  1. Boot the installation target.

  2. Select Installation.

  3. Press F4 for a selection of the repository.

  4. Choose SMB and enter the Windows machine's name or IP address, the share name (INSTALL/PRODUCT/DVD1, in this example), user name, and password. The syntax looks like this:

    smb://workdomain;user:password@server/INSTALL/DVD1

    After you press Enter, YaST starts and you can perform the installation.

13.6 Using ISO images of the installation media on the server

Instead of copying physical media into your server directory manually, you can also mount the ISO images of the installation media into your installation server and use them as a repository. To set up an HTTP, NFS or FTP server that uses ISO images instead of media copies, proceed as follows:

  1. Download the ISO images and save them to the machine to use as the installation server.

  2. Log in as root.

  3. Choose and create an appropriate location for the installation data, as described in Section 13.2, “Setting up an NFS repository manually”, Section 13.3, “Setting up an FTP repository manually”, or Section 13.4, “Setting up an HTTP repository manually”.

  4. Create subdirectories for each installation medium.

  5. To mount and unpack each ISO image to the final location, issue the following command:

    # mount -o loop PATH_TO_ISO PATH_TO_REPOSITORY/PRODUCT/MEDIUMX

    Replace PATH_TO_ISO with the path to your local copy of the ISO image. Replace PATH_TO_REPOSITORY with the source directory of your server. Replace PRODUCT with the product name and replace MEDIUMX with the type (CD or DVD) and number of media you are using.

  6. Repeat the previous step to mount all ISO images needed for your product.

  7. Start your installation server as usual, as described in Section 13.2, “Setting up an NFS repository manually”, Section 13.3, “Setting up an FTP repository manually”, or Section 13.4, “Setting up an HTTP repository manually”.

To automatically mount the ISO images at boot time, add the respective mount entries to /etc/fstab. An entry according to the previous example would look like the following:

PATH_TO_ISO PATH_TO_REPOSITORY/PRODUCTMEDIUM auto loop

14 Preparing network boot environment

This chapter describes how to configure a DHCP and a TFTP server that provide the required infrastructure for booting with PXE.

SUSE® Linux Enterprise Desktop can be installed via a Preboot Execution Environment (PXE). The client hardware needs to support booting via PXE. The network needs to provide a DHCP server and a TFTP server providing the required data to the clients. This chapter guides you through setting up the required servers.

PXE only boots a kernel and initrd. This can be used to boot into an installation environment or into live systems. To set up the installation sources, see Chapter 13, Setting up a network installation source.

This section covers the configuration tasks needed in complex boot scenarios. It contains ready-to-apply configuration examples for DHCP, PXE boot, TFTP, and Wake on LAN.

The examples assume that the DHCP, TFTP and NFS server reside on the same machine with the IP 192.168.1.1. All services can reside on different machines without any problems. Make sure to change the IP addresses as required.

14.1 Setting up a DHCP server

A DHCP server provides both dynamic (Section 14.1.1, “Dynamic address assignment”) and static IP address assignments (Section 14.1.2, “Assigning static IP addresses”) to your network clients. It advertises servers, routes, and domains. For TFTP servers, DHCP also provides the kernel and initrd files. Which files are loaded depends on the architecture of the target machine, and whether legacy BIOS or UEFI boot is used. The clients transmit their architecture type in their DHCP requests. Based on this information, the DHCP server decides which files the client must download for booting.

Warning
Warning: PXE and AutoYaST installation failure

Starting with SUSE Linux Enterprise 15.0, there are special conditions that cause PXE boot and AutoYaST installations to fail. See Section 14.1.3, “PXE and AutoYaST installation failures” for more information and the solution.

14.1.1 Dynamic address assignment

The following example shows how to set up a DHCP server that dynamically assigns IP addresses to clients, and advertises servers, routers, domains, and boot files.

  1. Log in as root to the machine hosting the DHCP server.

  2. Enable the DHCP server by executing systemctl enable dhcpd.

  3. Append the following lines to a subnet configuration of your DHCP server's configuration file located under /etc/dhcpd.conf:

    # The following lines are optional
    option domain-name "my.lab";
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    option ntp-servers 192.168.1.1;
    ddns-update-style none;
    default-lease-time 3600;
    
    # The following lines are required
    option arch code 93 = unsigned integer 16; # RFC4578
    subnet 192.168.1.0 netmask 255.255.255.0 {
     next-server 192.168.1.1;
     range 192.168.1.100 192.168.1.199;
     default-lease-time 3600;
     max-lease-time 3600;
     if option arch = 00:07 or option arch = 00:09 {
       filename "/EFI/x86/grub.efi";
     }
     else if option arch = 00:0b {
       filename "/EFI/aarch64/bootaa64.efi";
     }
     else  {
       filename "/BIOS/x86/pxelinux.0";
     }
    }

    This configuration example uses the subnet 192.168.1.0/24 with the DHCP, DNS and gateway on the server with the IP 192.168.1.1. Make sure that all IP addresses are changed according to your network layout. For more information about the options available in dhcpd.conf, refer to the dhcpd.conf manual page.

  4. Restart the DHCP server by executing systemctl restart dhcpd.

14.1.2 Assigning static IP addresses

A DHCP server may also assign static IP addresses and host names to network clients. One use case is assigning static addresses to servers. Another use case is restricting which clients may join the network to those with assigned static IP addresses, and providing no dynamic address pools.

Modify the above DHCP configuration according to the following example:

group {
 host test {
   hardware ethernet MAC_ADDRESS;
   fixed-address IP_ADDRESS;
   }
}

The host statement assigns a host name to the installation target. To bind the host name and IP address to a specific host, you must specify the client's hardware (MAC) address. Replace all the variables used in this example with the actual values that match your environment, then save your changes and restart the DHCP server.

14.1.3 PXE and AutoYaST installation failures

Starting with SUSE Linux Enterprise 15.0 and ISC DHCP 4.3.x, there are special circumstances that cause PXE boot and AutoYaST installations to fail. If your DHCP server does not have a pool of available dynamic IP addresses, but allows only pre-defined static addresses per client, and the clients send RFC 4361 client identifiers, then PXE/AutoYaST installations will not work. (Allowing only addresses assigned to specific network clients, and providing no dynamic address pools, prevents random machines from joining the network.)

When a new system starts in PXE, it sends a request to the DHCP server and identifies itself using a client identifier constructed from the hardware type plus the MAC address of the network interface. This is an RFC 2132 client-id. The DHCP server then offers the assigned IP address. Next, the installation kernel is loaded, and sends another DHCP request, but this client-id is different, and is sent in RFC 4361 format. The DHCP server will not recognize this as the same client, and will look for a free dynamic IP address, which is not available, and the installation stops.

The solution is to configure clients to send RFC 2132 client IDs. To send an RFC 2132 client-id during the installation, use linuxrc to pass the following ifcfg command:

ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67,
DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67

The traditionally-used RFC 2132 DHCPv4 client-id on Ethernet is constructed from the hardware type (01 for Ethernet) and followed by the hardware address (the MAC address), for example:

01:52:54:00:02:c2:67

The RFC 4361 DHCPv4 client-id attempts to correct the problem of identifying a machine that has more than one network interface. The new DHCPv4 client-id has the same format as the DHCPv6 client-id. It starts with the 0xff prefix, instead of the hardware type, followed by the DHCPv6 IAID (the interface-address association ID that describes the interface on the machine), followed by the DHCPv6 Unique Identifier (DUID), which uniquely identifies the machine.

Using the above hardware type-based and hardware address-based DUID, the new RFC 4361 DHCPv4 client-id would be:

  • Using the last bytes of the MAC address as the IAID: ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • When the IAID is a simple incremented number: ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

The xx:xx:xx:xx field in the DUID-Link-Layer Timestamp (DUID-LLT) is a creation time stamp. A DUID-Link-Layer (DUID-LL) (00:03:00:01:$MAC) does not have a time stamp.

For more information on using linuxrc, see the AutoYaST Guide. Also see man 4 initrd, and the documentation for the options dhcp4 "create-cid", dhcp6 "default-duid" in man 5 wicked-config, wicked duid --help, and wicked iaid --help.

14.2 Setting up a TFTP server

The following procedure describes how to prepare the server so that the client machines with UEFI and BIOS can boot remotely using files exported by TFTP.

14.2.1 Installing a TFTP server

To install a TFTP server, use the following procedure:

  1. Install the tftp package.

    > sudo zypper in tftp
  2. Review the tftpd configuration in /etc/sysconfig/tftp and add or change options as required. Refer to man 8 tftpd for more details. The TFTP daemon works without changing the configuration. The default root directory for the files is /srv/tftpboot.

  3. Ensure that tftpd is started at boot time, and restart it to read the new configuration.

    > sudo systemctl enable tftp.socket
    > sudo systemctl restart tftp.socket

14.2.2 Installing files for boot

SUSE Linux Enterprise Desktop provides the required files for booting via PXE on BIOS or UEFI machines. The following hardware architectures are supported:

  • AMD64/Intel 64

  • AArch64

  • POWER

  • IBM Z

Files required to boot from a specific hardware architecture are included in an RPM package. Install it on the machine running the TFTP server:

> sudo zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE

Replace OS_VERSION with the version number of your SUSE Linux Enterprise Desktop installation, for example SLE-15-SP3-x86_64, and replace ARCHITECTURE with the architecture of your system, for example x86_64. So the resulting text would look like this: tftpboot-installation-SLE-15-SP3-x86_64. Run zypper se tftpboot to search for all available versions and architectures.

The files will be installed in /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE. You can also copy the files for other versions and architectures of SUSE Linux Enterprise Desktop to the /srv/tftpboot directory.

Tip
Tip: Serving different architectures

The client and server hardware architecture can vary. For example, you can run an AMD64/Intel 64 TFTP server and provide a bootable environment for AArch64 client machines by installing the tftpboot-installation-SLE-15-SP3-aarch64 package.

Note
Note: Existing /srv/tftpboot/ directory

If the directory /srv/tftpboot/ already exists on your machine, then all files will be installed to /usr/share/tftpboot-installation/. This is the case if you are upgrading your PXE server from a previous SLES release.

To fix this problem, copy the files manually from /usr/share/tftpboot-installation/ to /srv/tftpboot/. Alternatively, remove /srv/tftpboot/ and reinstall the tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE package.

14.2.3 Configuring PXELINUX

Open the file /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default in an editor. Replace the path for the install parameter according to your setup as described in Chapter 13, Setting up a network installation source. Also replace TFTP_SERVER with the IP address of the TFTP server. For an overview of the PXELINUX configuration options, see Section 14.3, “PXELINUX configuration options”.

default linux

# install
label linux
  ipappend 2
  kernel boot/ARCHITECTURE/loader/linux
  append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH

display  message
implicit 1
prompt  1
timeout  50

For details about the boot parameters that are used in the append line, see Section 4.3, “List of important boot parameters”.

If required, edit the /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message to display a message in the boot menu.

14.2.4 Preparing PXE boot for EFI with GRUB2

Normally, the GRUB2 configuration files require no modifications. However, the default settings do not include a network resource for the installation system. To perform a full SUSE Linux Enterprise Desktop installation via network, you need to specify the install parameter in the linuxefi instruction of the /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg file. Refer to Section 4.3.3, “Specifying the installation source” for further information about the install parameter.

14.3 PXELINUX configuration options

The options listed here are a subset of all the options available for the PXELINUX configuration file.

APPEND OPTIONS

Adds one or more options to the kernel command line. These are added for both automatic and manual boots. The options are added at the very beginning of the kernel command line, usually permitting explicitly entered kernel options to override them.

APPEND -

Appends nothing. APPEND with a single hyphen as argument in a LABEL section can be used to override a global APPEND.

DEFAULT KERNEL_OPTIONS...

Sets the default kernel command line. When PXELINUX boots automatically, it executes the specified entries, appending the auto option.

If no configuration file exists or no DEFAULT entry is defined in the configuration file, the default is the kernel name linux with no options.

IFAPPEND FLAG

Adds a specific option to the kernel command line depending on the FLAG value. The IFAPPEND option is available only on PXELINUX. FLAG expects a value, described in Table 14.1, “Generated and added kernel command line options from IFAPPEND:

Table 14.1: Generated and added kernel command line options from IFAPPEND

Argument

Generated kernel command line / Description

1

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

The placeholders are replaced based on the input from the DHCP/BOOTP or PXE boot server.

Note, this option is not a substitute for running a DHCP client in the booted system. Without regular renewals, the lease acquired by the PXE BIOS will expire, making the IP address available for reuse by the DHCP server.

2

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

This option is useful to avoid timeouts when the installation server probes one LAN interface after another until it gets a reply from a DHCP server. This option allows an initrd program to determine from which interface the system has been booted. linuxrc reads this option and uses this network interface.

4

SYSUUID=SYSTEM_UUID

Adds UUIDs in lowercase hexadecimals, see /usr/share/doc/packages/syslinux/pxelinux.txt

LABEL LABEL KERNEL IMAGE APPEND OPTIONS...

Indicates that if LABEL is entered as the kernel to boot, PXELINUX should instead boot IMAGE and the specified APPEND options should be used. They replace the ones specified in the global section of the file, before the first LABEL command. The default for IMAGE is the same as LABEL and, if no APPEND is given, the default is to use the global entry (if any). Up to 128 LABEL entries are permitted.

PXELINUX uses the following syntax:

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Labels are mangled as if they were file names and they must be unique after mangling. For example, the two labels v2.6.30 and v2.6.31 would not be distinguishable under PXELINUX because both mangle to the same DOS file name.

The kernel does not need to be a Linux kernel. It can also be a boot sector or a COMBOOT file.

LOCALBOOT TYPE

On PXELINUX, specifying LOCALBOOT 0 instead of a KERNEL option means invoking this particular label and causes a local disk boot instead of a kernel boot.

Argument

Description

0

Perform a normal boot

4

Perform a local boot with the Universal Network Driver Interface (UNDI) driver still resident in memory

5

Perform a local boot with the entire PXE stack, including the UNDI driver, still resident in memory

All other values are undefined. If you do not know what the UNDI or PXE stacks are, specify 0.

TIMEOUT TIME-OUT

Indicates how long to wait at the boot prompt until booting automatically, in units of 1/10 second. The time-out is canceled when the user types anything on the keyboard, assuming the user will complete the command begun. A time-out of zero disables the time-out completely (this is also the default). The maximum possible time-out value is 35996 (just less than one hour).

PROMPT flag_val

If flag_val is 0, displays the boot prompt only if Shift or Alt is pressed or Caps Lock or Scroll Lock is set (this is the default). If flag_val is 1, always displays the boot prompt.

F2  FILENAME
F1  FILENAME
..etc...
F9  FILENAME
F10 FILENAME

Displays the indicated file on the screen when a function key is pressed at the boot prompt. This can be used to implement preboot online help (presumably for the kernel command line options). For backward compatibility with earlier releases, F10 can be also entered as F0. Note that there is currently no way to bind file names to F11 and F12.

14.4 Preparing the target system for PXE boot

Prepare the system's BIOS for PXE boot by including the PXE option in the BIOS boot order.

Warning
Warning: BIOS boot order

Do not place the PXE option ahead of the hard disk boot parameter in the BIOS. Otherwise this system would try to re-install itself every time you boot it.

14.5 Using wake-on-LAN for remote wakeups

Wake-on-LAN (WOL) is an Ethernet standard for remotely waking up a computer by sending it a wakeup signal over a network. This signal is called the magic packet. Install WOL on client machines to enable remote wakeups, and on every machine you want to use for sending the wakeup signal. The magic packet is broadcast over UDP port 9 to the MAC address of the network interface on the client machine.

When computers are shut down they usually are not turned all the way off, but remain in a low power mode. When the network interface supports WOL, it listens for the magic packet wakeup signal when the machine is powered off. You can send the magic packet manually, or schedule wakeups in a cron job on the sending machine.

14.5.1 Prerequisites

WOL works with both wired and wireless Ethernet cards that support it.

You may need to enable WOL in your system BIOS/UEFI.

Check your BIOS/UEFI settings for PXE boot, and make sure it is disabled to prevent accidental re-installations.

Adjust your firewall to allow traffic over UDP port 9.

14.5.2 Verifying wired Ethernet support

Run the following command to see if a wired Ethernet interface supports WOL:

> sudo ethtool eth0 | grep -i wake-on
Supports Wake-on: pumbg
Wake-on: g

The example output shows that eth0 supports WOL, indicated by the g flag on the Supports Wake-on line. Wake-on: g shows that WOL is already enabled, so this interface is ready to receive wakeup signals. If WOL is not enabled, enable it with this command:

> sudo ethtool -s eth0 wol g

14.5.3 Verifying wireless interface support

Wakeup-over-wifi, or WoWLAN, requires a wireless network interface that supports WoWLAN. Test it with the iw command, which is provided by the iw package:

> sudo zypper in iw

Find your device name:

> sudo iw dev
phy#0
        Interface wlan2
                ifindex 3
                wdev 0x1
                addr 9c:ef:d5:fe:01:7c
                ssid accesspoint
                type managed
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm

In this example, the device name to use for querying WoWLAN support is phy#0. This example shows that it is not supported:

> sudo iw phy#0 wowlan show
command failed: Operation not supported (-95)

This example shows an interface that supports WoWLAN, but is not enabled:

> sudo iw phy#0 wowlan show
WoWLAN is disabled

Enable it:

> sudo iw phy#0 wowlan enable magic-packet
WoWLAN is enabled:
* wake up on magic packet

14.5.4 Installing and testing WOL

To use WOL, install the wol package on the client and sending machines:

> sudo zypper in wol

Install wol-udev-rules on your client machines. This package installs a udev rule that enables WOL automatically at start-up.

Get the MAC address of the network interface on the client machine:

> sudo ip addr show eth0|grep ether
link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff

In the example output, 7c:ef:a5:fe:06:7c is the MAC address.

Shut down your client machine, and send it a wakeup signal from another computer on the same subnet:

> wol 7c:ef:a5:fe:06:7c

If your target machine and second device are on the same network but in different subnets, specify the broadcast address for your target machine:

> wol -i 192.168.0.63 7c:ef:a5:fe:06:7c

Because WOL relies on broadcast domains, the sending machine must be on the same network, though it can be in a different network segment.

It is possible to send the magic packet from a different network. One way is with port forwarding, if your router supports port forwarding to a broadcast address. A more secure method is to connect to a host inside your network via SSH, and send the magic packet from there.

15 Setting up a UEFI HTTP Boot server

This chapter describes how to set up and configure a UEFI HTTP Boot server.

15.1 Introduction

HTTP Boot combines DHCP, DNS and HTTP to make it possible to boot and deploy systems over the network. HTTP Boot can be used as a high-performance replacement for PXE. HTTP Boot allows to boot a server from a URI over HTTP, quickly transferring large files, such as the Linux kernel and root file system, from servers outside of your local network.

15.1.1 Configuring the client machine

Enabling HTTP Boot on a physical client machine depends on your specific hardware. Consult the documentation for further information on how to enable HTTP Boot on your particular machine.

15.1.2 Preparation

The setup described here uses 192.168.111.0/24 (IPv4) and 2001:db8:f00f:cafe::/64 (IPv6) IP subnets and the server IP addresses are 192.168.111.1(IPv4) and 2001:db8:f00f:cafe::1/64 (IPv6) as examples. Adjust these values to match your specific setup.

Install the following packages on the machine that you plan to use as an HTTP Boot server: dhcp-server, apache2 (or lighttpd), and dnsmasq.

15.2 Configuring the server

15.2.1 DNS server

While configuring the DNS server is optional, this does allow you to assign a user-friendly name to the HTTP Boot server. To set up the DNS server, add the following to the /etc/dnsmasq.conf file:

interface=eth0
addn-hosts=/etc/dnsmasq.d/hosts.conf

Assign a domain name to the IP addresses in the /etc/dnsmasq.d/hosts.conf file:

192.168.111.1 www.httpboot.local
2001:db8:f00f:cafe::1 www.httpboot.local

Start the DNS server.

systemctl start dnsmasq
Note
Note: Use the shim boot loader

Because of a change in UEFI 2.7, we recommend using a shim boot loader from SLE 15 or newer to avoid potential errors caused by the additional DNS node.

15.2.1.1 Configuring the DHCPv4 server

Before setting up the DHCP servers, specify the network interface for them in /etc/sysconfig/dhcpd:

DHCPD_INTERFACE="eth0"
DHCPD6_INTERFACE="eth0"

This way, the DHCP servers provide the service on the eth0 interface only.

To set up a DHCPv4 server for both PXE Boot and HTTP Boot, add the following configuration to the /etc/dhcpd.conf file:

option domain-name-servers 192.168.111.1;
option routers 192.168.111.1;
default-lease-time 14400;
ddns-update-style none;
class "pxeclients" {
  match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
  option vendor-class-identifier "PXEClient";
  next-server 192.168.111.1;
  filename "/bootx64.efi";
}
class "httpclients" {
  match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
  option vendor-class-identifier "HTTPClient";
  filename "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
}
subnet 192.168.111.0 netmask 255.255.255.0 {
  range dynamic-bootp 192.168.111.100 192.168.111.120;
  default-lease-time 14400;
  max-lease-time 172800;
}

Note that the DHCPv4 server must use the HTTPClient parameter for the vendor class ID, as the client uses it to identify an HTTP Boot offer.

Start the DHCP daemon:

systemctl start dhcpd

15.2.1.2 Configuring the DHCPv6 server

To set up the DHCPv6 server, add the following configuration to /etc/dhcpd6.conf:

option dhcp6.bootfile-url code 59 = string;
option dhcp6.vendor-class code 16 = {integer 32, integer 16, string};
subnet6 2001:db8:f00f:cafe::/64 {
        range6 2001:db8:f00f:cafe::42:10 2001:db8:f00f:cafe::42:99;
        option dhcp6.bootfile-url "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
        option dhcp6.name-servers 2001:db8:f00f:cafe::1;
        option dhcp6.vendor-class 0 10 "HTTPClient";
}

This configuration defines the type of the boot URL, the vendor class, and other required options. Similar to the DHCPv4 settings, it is necessary to provide the boot URL, which must have an IPv6 address. It is also necessary to specify the vendor class option. In DHCPv6, it consists of the enterprise number and the vendor class data (length and the content). Since the HTTP Boot driver ignores the enterprise number, you can set it to 0. The content of the vendor class data needs to be HTTPClient; otherwise, the client ignores the offer.

The older HTTP Boot implementation, which does not follow RFC 3315, requires a different configuration:

option dhcp6.bootfile-url code 59 = string;
option dhcp6.vendor-class code 16 = string;
        subnet6 2001:db8:f00f:cafe::/64 {
        range6 2001:db8:f00f:cafe::42:10 2001:db8:f00f:cafe::42:99;
        option dhcp6.bootfile-url "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi;
	option dhcp6.name-servers 2001:db8:f00f:cafe::1;
	option dhcp6.vendor-class "HTTPClient";
}

Start the dhcpv6 daemon.

systemctl start dhcpd6
15.2.1.2.1 Setting up the DHCPv6 server for both PXE and HTTP boot

Using the following configuration, it is possible to configure the DHCPv6 server for both PXE Boot and HTTP Boot:

option dhcp6.bootfile-url code 59 = string;
option dhcp6.vendor-class code 16 = {integer 32, integer 16, string};

subnet6 2001:db8:f00f:cafe::/64 {
        range6 2001:db8:f00f:cafe::42:10 2001:db8:f00f:cafe::42:99;

        class "PXEClient" {
	        match substring (option dhcp6.vendor-class, 6, 9);
	}

        subclass "PXEClient" "PXEClient" {
	        option dhcp6.bootfile-url "tftp://[2001:db8:f00f:cafe::1]/bootloader.efi";
	}

	class "HTTPClient" {
	        match substring (option dhcp6.vendor-class, 6, 10);
	}

	subclass "HTTPClient" "HTTPClient" {
	        option dhcp6.bootfile-url "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
		option dhcp6.name-servers 2001:db8:f00f:cafe::1;
		option dhcp6.vendor-class 0 10 "HTTPClient";
	}
}

It is also possible to match the vendor class to a specific architecture, as follows:

class "HTTPClient" {
        match substring (option dhcp6.vendor-class, 6, 21);
	}

subclass "HTTPClient" "HTTPClient:Arch:00016" {
        option dhcp6.bootfile-url "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
	option dhcp6.name-servers 2001:db8:f00f:cafe::1;
	option dhcp6.vendor-class 0 10 "HTTPClient";
}

In this example, HTTPClient:Arch:00016 refers to an AMD64/Intel 64 HTTP Boot client. This configuration allows the server to serve different architectures simultaneously.

15.2.1.2.2 Configuring firewall

If DHCPv6 packets are dropped by the RP filter in the firewall, check its log. In case it contains the rpfilter_DROP entry, disable the filter using the following configuration in /etc/firewalld/firewalld.conf:

IPv6_rpfilter=no

15.2.1.3 Deploying a TFTP server (optional)

To provide support for both PXE Boot and HTTP Boot, deploy a TFTP server. Install the tftp and start the service:

 systemctl start tftp.socket
systemctl start tftp.service

It is also necessary to install a specific tftpboot-installation package for use with PXE Boot. Run the zypper se tftpboot command, to list of the available tftp-installation packages, then install the package for the desired system version and architecture, for example tftpboot-installation-SLE-15-SP3-x86_64 For example, tftpboot-installation-SLE-VERSION-x86_64 (replace VERSION with the actual version). Copy the content of the SLE-VERSION-x86_64 directory to the root directory of the TFTP server:

cp -r /usr/share/tftpboot-installation/SLE-VERSION-x86_64 /srv/tftpboot

For more information, refer to /usr/share/tftpboot-installation/SLE-VERSION-x86_64/README

15.2.1.4 Setting up the HTTP server

Create the sle/ directory under the /srv/www/htdocs/ directory and copy the entire content of the first system ISO image to the /srv/www/htdocs/sle/ directory. Then edit the /srv/www/htdocs/sle/EFI/BOOT/grub.cfg file. Use the following example as a reference:

timeout=60
default=1

menuentry 'Installation IPv4' --class opensuse --class gnu-linux --class gnu --class os {
    set gfxpayload=keep
    echo 'Loading kernel ...'
    linux /sle/boot/x86_64/loader/linux install=http://www.httpboot.local/sle
    echo 'Loading initial ramdisk ...'
    initrd /sle/boot/x86_64/loader/initrd
}

menuentry 'Installation IPv6' --class opensuse --class gnu-linux --class gnu --class os {
    set gfxpayload=keep
    echo 'Loading kernel ...'
    linux /sle/boot/x86_64/loader/linux install=install=http://www.httpboot.local/sle ipv6only=1 ifcfg=*=dhcp6,DHCLIENT6_MODE=managed
    echo 'Loading initial ramdisk ...'
    initrd /sle/boot/x86_64/loader/initrd
}
15.2.1.4.1 Configuring lighttpd

To enable the support for both IPv4 and IPv6 in lighttpd, modify /etc/lighttpd/lighttpd.conf as follows:

##
## Use IPv6?
##
#server.use-ipv6 = "enable"
$SERVER["socket"] == "[::]:80" {  }

Start the lighttpd daemon:

systemctl start lighttpd
15.2.1.4.2 Configuring apache2

Apache requires no additional configuration. Start the apache2 daemon:

systemctl start apache2

15.2.1.5 Enabling SSL support for the HTTP server (optional)

To use the HTTPS Boot, you need to convert an existing server certificate into the DER format and enroll it into the client's firmware.

Assuming you already have a certificate installed on your server, convert it into the DER format for use with the client using the following command:

openssl x509 -in CERTIFICATE.crt -outform der -out CERTIFICATE.der
15.2.1.5.1 Enroll the server certificate into the client firmware

The exact procedure of enrolling the converted certificate depends on the specific implementation of the client's firmware. For certain hardware, you need to enroll the certificate manually via the firmware UI using an external storage device with the certificate on it. Machines with Redfish support can enroll the certificate remotely. Consult the documentation for your specific hardware for more information on enrolling certificates.

15.2.1.5.2 Enabling SSL support in lighttpd

Since lighttpd needs the private key and the certificate in the same file, unify them using the following command:

cat CERTIFICATE.crt server.key > CERTIFICATE.pem

Copy CERTIFICATE.pem to the /etc/ssl/private/ directory.

cp server-almighty.pem /etc/ssl/private/
chown -R root:lighttpd /etc/ssl/private/server-almighty.pem
chmod 640 /etc/ssl/private/server-almighty.pem

Make sure that mod_openssl is listed in the server.modules section of the /etc/lighttpd/modules.conf file, for example:

server.modules = (
  "mod_access",
  "mod_openssl",
)

Add the following lines to SSL Support section in /etc/lighttpd/lighttpd.conf:

# IPv4
$SERVER["socket"] == ":443" {
    ssl.engine                 = "enable"
    ssl.pemfile                = "/etc/ssl/private/server-almighty.pem"
}
# IPv6
$SERVER["socket"] == "[::]:443" {
    ssl.engine                 = "enable"
    ssl.pemfile                = "/etc/ssl/private/server-almighty.pem"
}

Restart lighttpd to activate SSL support:

systemctl restart lighttpd
15.2.1.5.3 Enabling SSL support in Apache

Open the /etc/sysconfig/apache2 file and add the SSL flag as follows:

APACHE_SERVER_FLAGS="SSL"

Make sure that the ssl module is listed in APACHE_MODULES, for example:

Next, copy the private key and the certificate to the /etc/apache2/ directory.

cp server.key /etc/apache2/ssl.key/
chown wwwrun /etc/apache2/ssl.key/server.key
chmod 600 /etc/apache2/ssl.key/server.key
cp server.crt /etc/apache2/ssl.crt/

Create the ssl vhost configuration.

cd /etc/apache2/vhosts.d
cp vhost-ssl.template vhost-ssl.conf

Edit /etc/apache2/vhosts.d/vhost-ssl.conf to change the private key and the certificate:

SSLCertificateFile /etc/apache2/ssl.crt/server.crt
 SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

Restart Apache to activate the SSL support:

systemctl restart apache2
15.2.1.5.4 Modify the DHCP configuration

Replace the http:// prefix with https:// in dhcpd.conf/dhcpd6.conf and restart the DHCP server.

systemctl restart dhcpd
systemctl restart dhcpd6

15.3 Booting the client via HTTP boot

If the firmware already supports HTTP boot, plug in the cable and choose the correct boot option.

16 Deploying customized preinstallations

Rolling out customized preinstallations of SUSE Linux Enterprise Desktop to many identical machines spares you from installing each one of them separately and provides a standardized installation for the end users.

With YaST firstboot, create customized preinstallation images and determine the workflow for the final personalization steps that involve end user interaction (as opposed to AutoYaST, which allows completely automated installations).

Creating a custom installation, rolling it out to your hardware, and personalizing the final product involves the following steps:

  1. Prepare the master machine whose disk needs to be cloned to the client machines. For more information, refer to Section 16.1, “Preparing the master machine”.

  2. Customize the firstboot workflow. For more information, refer to Section 16.2, “Customizing the firstboot installation”.

  3. Clone the master machine's disk and roll this image out to the clients' disks. For more information, refer to Section 16.3, “Cloning the master installation”.

  4. Have the end user personalize the instance of SUSE Linux Enterprise Desktop. For more information, refer to Section 16.4, “Personalizing the installation”.

16.1 Preparing the master machine

To prepare a master machine for a firstboot workflow, proceed as follows:

  1. Insert the installation media into the master machine.

  2. Boot the machine.

  3. Perform a normal installation including all necessary configuration steps, and make sure to select the yast2-firstboot package for installation.

  4. To define your own workflow of YaST configuration steps for the end user or to add your own YaST modules to this workflow, proceed to Section 16.2, “Customizing the firstboot installation”. Otherwise proceed directly to Step 5.

  5. Enable firstboot as root:

    Create an empty file /var/lib/YaST2/reconfig_system to trigger firstboot's execution. This file will be deleted after the firstboot configuration has been successfully accomplished. Create this file using the following command:

    touch /var/lib/YaST2/reconfig_system
  6. Proceed to Section 16.3, “Cloning the master installation”.

16.2 Customizing the firstboot installation

Customizing the firstboot installation workflow may involve several components. Customizing them is recommended. If you do not make any changes, firstboot performs the installation using the default settings. The following options are available:

To customize any of these components, modify the following configuration files:

/etc/sysconfig/firstboot

Configure various aspects of firstboot (such as release notes, scripts, and license actions).

/etc/YaST2/firstboot.xml

Configure the installation workflow by enabling or disabling components or adding custom ones.

Provide translations for such a customized installation workflow, as described in Section 16.2.6, “Providing translations of the installation workflow”.

Tip
Tip: Alternative location of the control file

/etc/YaST2/firstboot.xml is the default path for the control file, installed by the yast2-firstboot package. If you need to define a different location for the control file, edit /etc/sysconfig/firstboot, and change the FIRSTBOOT_CONTROL_FILE variable to your preferred location.

If you want to customize more than the workflow components, refer to the control.xml documentation at https://doc.opensuse.org/projects/YaST/SLES11/tdg/inst_in_general_chap.html#product_control.

16.2.1 Customizing YaST messages

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:

  1. Log in as root.

  2. Open the /etc/sysconfig/firstboot configuration file and apply the following changes:

    1. Set FIRSTBOOT_WELCOME_DIR to the directory path where you want to store the files containing the welcome message and the localized versions, for example:

      FIRSTBOOT_WELCOME_DIR="/usr/share/firstboot/"
    2. If your welcome message has file names other than welcome.txt and welcome_locale.txt (where locale matches the ISO 639 language codes such as cs or de), specify the file name pattern in FIRSTBOOT_WELCOME_PATTERNS. For example:

      FIRSTBOOT_WELCOME_PATTERNS="mywelcome.txt"

      If unset, the default value of welcome.txt is assumed.

  3. Create the welcome file and the localized versions and place them in the directory specified in the /etc/sysconfig/firstboot configuration file.

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.

16.2.2 Customizing the license action

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:

halt

The firstboot installation is aborted and the entire system shuts down. This is the default setting.

continue

The firstboot installation continues.

abort

The firstboot installation is aborted, but the system attempts to boot.

Make your choice and set LICENSE_REFUSAL_ACTION to the appropriate value.

16.2.3 Customizing the release notes

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:

  1. Create your own release notes file. Use the RTF format as in the example file in /usr/share/doc/release-notes and save the result as RELEASE-NOTES.en.rtf (for English).

  2. Store optional localized versions next to the original version and replace the en part of the file name with the actual ISO 639 language code, such as de for German.

  3. Open the firstboot configuration file from /etc/sysconfig/firstboot and set FIRSTBOOT_RELEASE_NOTES_PATH to the actual directory where the release notes files are stored.

16.2.4 Customizing the workflow

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

  • Language Selection

  • Welcome

  • License Agreement

  • Time and Date

  • Users

  • Root Password

  • Finish Setup

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.

Example 16.1: Configuring the proposal screens
    …
    <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>

1

The container for all proposals that should be part of the firstboot workflow.

2

The container for an individual proposal.

3

The internal name of the proposal.

4

The mode of this proposal. Do not make any changes here. For a firstboot installation, this must be set to installation.

5

The stage of the installation process at which this proposal is invoked. Do not make any changes here. For a firstboot installation, this must be set to firstboot.

6

The label to be displayed on the proposal.

7

The container for all modules that are part of the proposal screen.

8

One or more modules that are part of the proposal screen.

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.

Example 16.2: Configuring the workflow section
    <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:

enable_back

Include the Back button in all dialogs.

enable_next

Include the Next button in all dialogs.

archs

Specify the hardware architectures on which this workflow should be used.

Example 16.3: Configuring the list of 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>

1

The container for all components of the workflow.

2

The module definition.

3

The label displayed with the module.

4

The switch to enable or disable this component in the workflow.

5

The module name. The module itself must be located under /usr/share/YaST2/clients.

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

  1. Open the firstboot configuration file at /etc/YaST2/firstboot.xml.

  2. Delete or add proposal screens or change the order of the existing ones:

    • To delete an entire proposal, remove the proposal element including all its sub-elements from the proposals section and remove the respective module element (with sub-elements) from the workflow.

    • To add a new proposal, create a new proposal element and fill in all the required sub-elements. Make sure that the proposal exists as a YaST module in /usr/share/YaST2/clients.

    • To change the order of proposals, move the respective module elements containing the proposal screens around in the workflow. Note that there may be dependencies on other installation steps that require a certain order of proposals and workflow components.

  3. Apply your changes and close the configuration file.

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:

  1. Open the /etc/YaST2/firstboot.xml configuration file.

  2. Change the value for the enabled element from true to false to disable the module or from false to true to enable it again.

    <module>
        <label>Time and Date</label>
        <enabled config:type="boolean">true</enabled>
        <name>firstboot_timezone</name>
    </module>
  3. Apply your changes and close the configuration file.

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

  1. Create your own YaST module and store the module file module_name.rb in /usr/share/YaST2/clients.

  2. Open the /etc/YaST2/firstboot.xml configuration file.

  3. Determine at which point in the workflow your new module should be run. In doing so, make sure that any dependencies on other steps in the workflow are taken into account and resolved.

  4. Create a new module element inside the modules container and add the appropriate sub-elements:

    <modules config:type="list">
         …
         <module>
            <label>my_module</label>
            <enabled config:type="boolean">true</enabled>
            <name>filename_my_module</name>
         </module>
    </modules>
    1. Enter the label to be displayed on your module in the label element.

    2. Make sure that enabled is set to true to have your module included in the workflow.

    3. Enter the file name of your module in the name element. Omit the full path and the .rb suffix.

  5. Apply your settings and close the configuration file.

Tip
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.

16.2.5 Configuring additional scripts

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:

  1. Open the /etc/sysconfig/firstboot configuration file and make sure that the path specified for SCRIPT_DIR is correct. The default value is /usr/share/firstboot/scripts.

  2. Create your shell script, store it in the specified directory, and apply the appropriate file permissions.

16.2.6 Providing translations of the installation workflow

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:

  1. For example, change the textdomain setting from:

    <textdomain>firstboot</textdomain>

    to the following:

    <textdomain>firstboot-oem</textdomain>
  2. Use xgettext to extract the translatable strings to the translation template file (.pot file), for example to firstboot-oem.pot:

    xgettext -L Glade -o firstboot-oem.pot /etc/YaST2/firstboot.xml
  3. Start the translation process. Then package the translated files (.LL_code.po files) the same way as translations of the other projects and install the compiled firstboot-oem.mo files.

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
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.

16.3 Cloning the master installation

Clone the master machine's disk using any of the imaging mechanisms available to you, and roll these images out to the target machines. For more information about imaging, see https://doc.suse.com/kiwi/.

16.4 Personalizing the installation

When the cloned disk image is booted, firstboot starts and the installation proceeds exactly as laid out in Section 16.2.4, “Customizing the workflow”. Only the components included in the firstboot workflow configuration are started. All other installation steps are skipped. The end user adjusts language, keyboard, network, and password settings to personalize the workstation. After this process is finished, a firstboot installed system behaves as any other instance of SUSE Linux Enterprise Desktop.

A Imaging and creating products

To adapt the operating system better to your deployment, you can create custom media for use as an appliance or live system with KIWI NG. KIWI NG can be used either on a local machine or online in SUSE Studio Express (OBS).

With KIWI NG, you can create Live CDs, Live DVDs, flash disks to use on Linux-supported hardware platforms and virtual disks for virtualization and cloud systems (like Xen, KVM, VMware, EC2 and more). Images created by KIWI NG can also be used in a PXE environment to boot from the network.

This guide does not cover topics related to KIWI NG in depth, as there is separate documentation available:

  • For more information, see the KIWI NG documentation at https://doc.suse.com/kiwi/ (also available in the package kiwi-doc).

  • SUSE Studio Express on Open Build Service can be used to create OS images online. It supports creating virtual appliances and live systems, based on either openSUSE or SUSE Linux Enterprise. For more information and documentation, see https://studioexpress.opensuse.org/.