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.

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.

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.

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:

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.

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:

Figure 3.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:

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: 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:

Figure 3.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 Esc–0. A complete list of parameters is available at https://en.opensuse.org/Linuxrc.

Important: Configuring the network interface

The settings discussed in this section apply only to the network interface used during installation.

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.

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

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 7, Remote installation.

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: 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 4.6, “Registration” for details).

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/

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:

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:

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

During installation and upgrade, YaST can update itself as described in Section 4.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/

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

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.

Unlocking of encrypted devices using TPM 2.0 or FIDO2 in the installer is supported as of SUSE Linux Enterprise 15 SP4. To enable this feature, add:

YAST_LUKS2_AVAILABLE

Please note that you need a separate, unencrypted boot partition in order to encrypt the root file system.

Important: Technology Preview

Please note that in SLE15 SP4, this feature is a technology preview and, therefore, not fully supported. For more information, refer to https://documentation.suse.com/sles/15-SP4/html/SLES-all/preface-deployment.html.

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

The process can be broken down into two different parts:

4.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: 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 3.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 3.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.

4.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: 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.

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

Note: Only one repository

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

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.

Figure 4.4: SUSE Customer Center registration #

  

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: 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: 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.

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:

SLES    cc36aae1
SLED    309105d4

sle-we  5eedd26a
sle-live-patching 8c541494

<?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: Limitations

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

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

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-SP5-Full-ARCH-GM-media1.iso image.

Figure 4.5: Installing without registration #

  

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: 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-SP5-Online-ARCH-GM-media1.iso or SLE-15-SP5-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-SP5-Full-ARCH-GM-media1.iso would be:

dd if=SLE-15-SP5-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!

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

Figure 4.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:

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.

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.

Figure 4.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: 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.

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: 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.

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: 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: 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: 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 4.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 4.14.1, “Software”).

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: 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 3, 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.

This category displays the current network settings, as automatically configured after booting into the installation (see Section 4.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: 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.

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.

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:

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:

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

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.

6.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: 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

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 6.1.2.2, “Btrfs partitioning”.

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

6.1.2.2 Btrfs partitioning #

  

The default file system for the root partition is Btrfs. For details, see . 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: 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: 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.

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:

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.

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:

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:

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

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: 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.

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

If no volume group exists on your system, you must add one (see Figure 6.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.

Figure 6.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.

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.

Figure 6.4: Logical volume management #

  

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

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: 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.

The YaST RAID configuration can be reached from the YaST Expert Partitioner, described in Section 6.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:

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.

Figure 6.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.

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.

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.

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 4, Installation steps.

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

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.

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 4, Installation steps.

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

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:

To enable VNC on the installation target, specify the appropriate boot parameters at the initial boot for installation (see Chapter 3, 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:

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).

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.

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 3, Boot parameters for details. OpenSSH is installed by default on any SUSE Linux–based operating system.

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

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.

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.

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:

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.

To install a TFTP server, use the following procedure:

SUSE Linux Enterprise Desktop provides the required files for booting via PXE on BIOS or UEFI machines. The following hardware architectures are supported:

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: 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: 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.

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 12, 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 13.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 3.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.

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 3.3.3, “Specifying the installation source” for further information about the install parameter.