As of SUSE Linux Enterprise Server 15 SP2, this includes the following base products:

If you are installing onto a computer or VM that has access to the Internet, then to install any of the products listed above, it is only necessary to download the SLE-15-SP2-Online-ARCH-GM-media1.iso image for the desired architecture.

Note: Installing SUSE Manager

To install any SUSE Manager products, the target machine must have direct access to the SUSE Customer Center or to an RMT server.

Except for SUSE Manager, you do not require access to the Internet, or to the SUSE Customer Center or to an RMT server, to install the other listed products.

For offline installation, additionally download the SLE-15-SP2-Full-ARCH-GM-media1.iso image for the desired architecture.

There is an additional, second Packages medium, but this contains only source code and is not required for installation.

Tip: Full Media Size

The size of the full installation media SLE-15-SP2-Online-ARCH-GM-media1.iso exceeds the capacity of a dual layer DVD. Therefore you can only boot it from a USB flash drive.

For the installation media and the VM Guest images, SUSE offers two variants:

You only need either the GM or the QU media, not both. Which to choose, the GM or the QU version, depends on your needs and preferences. If you have newer hardware, the QU version might be the better choice. The installation procedure is identical for both variants.

For both variants it is recommended to install the latest updates released since creating the images during or immediately after installation.

SUSE Linux Enterprise Server is normally installed as an independent operating system. With virtualization it is also possible to run multiple instances of SUSE Linux Enterprise Server on the same hardware. However, the installation of the VM Host Server is performed like a typical installation with some additional packages. The installation of virtual guests is described in Book “Virtualization Guide”, Chapter 8 “Guest Installation”.

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:

To simplify the installation process and avoid accidental installations, the default setting on the installation medium for SUSE Linux Enterprise Server is that your system is booted from the first hard disk. At this point, an installed boot loader normally takes over control of the system. This means that the boot medium can stay in the drive during the installation. To start the installation, choose one of the installation possibilities in the boot menu of the media.

SUSE Linux Enterprise Server is normally installed as an independent operating system. With virtualization it is also possible to run multiple instances of SUSE Linux Enterprise Server on the same hardware. However, the installation of the VM Host Server is performed like a typical installation with some additional packages. The installation of virtual guests is described in Book “Virtualization Guide”, Chapter 8 “Guest Installation”.

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

To simplify the installation process and avoid accidental installations, the default setting on the installation DVD for SUSE Linux Enterprise Server is that your system is booted from the first hard disk. At this point, an installed boot loader normally takes over control of the system. This means that the boot DVD can stay in the drive during an installation. To start the installation, choose one of the installation possibilities in the boot menu of the media.

The primary processor on the Raspberry Pi's System-on-Chip (SoC) is the Broadcom VideoCore Graphics Processing Unit (GPU), not the Arm Central Processing Unit (CPU). It is the GPU which starts initializing the hardware from a first-stage boot loader in the on-chip Boot Read-Only Memory (Boot ROM). Only a few configuration options can influence the Boot ROM; see Section 3.6.1.2, “OTP Memory”.

The Raspberry Pi 3 hardware does not have any built-in firmware. Instead, its second-stage boot loader firmware bootcode.bin is loaded from the boot medium every time the machine is powered on. It in turn loads the third-stage boot loader start.elf.

The Raspberry Pi 4 hardware has a small Electrically Erasable Programmable Read-Only Memory (EEPROM) for the second-stage boot loader. Apart from that, its boot sequence is similar to that of the Raspberry Pi 3, loading the third-stage boot loader start4.elf from the boot medium.

Warning: EEPROM Update on Raspberry Pi 4

An update of the second-stage boot loader can be performed by booting from a specially prepared microSD card.

Only insert boot media that you trust, and verify that no file called recovery.bin is unintentionally present.

If an armstub8.bin file is present, it will be loaded as a fourth-stage boot loader at AArch64 Exception Level 3 (EL3). Otherwise, a minimal integrated stub will be used.

Note: EL3 Security Considerations

Code loaded for EL3 (often called BL31) will reside in memory, and Linux may attempt hypercalls into EL3 throughout its runtime.

Verify that your boot media have no armstub8.bin file unintentionally present. SUSE Linux Enterprise Server 15 SP2 does not include it.

Beware that the Raspberry Pi's SoC does not provide TrustZone secure memory. Both the OS on the CPU and any software on the GPU may access its RAM. It is therefore unsuited for cryptographic EL0-s applications. SUSE Linux Enterprise Server does not provide an EL1-s Trusted Execution Environment (TEE) for that reason.

SUSE Linux Enterprise Server for the Raspberry Pi is configured to load a fifth-stage boot loader called Das U-Boot.

3.6.1.2 OTP Memory #

  

The SoC also has a very small amount of One-Time Programmable Memory (OTP memory). This can be used to configure some settings, such as whether the Boot ROM should attempt to boot from USB devices or over Ethernet.

This OTP memory is described on the Raspberry Pi Foundation Web site: https://www.raspberrypi.org/documentation/hardware/raspberrypi/otpbits.md

Warning: One-Time Programmable Only

Configuration settings written into OTP memory cannot be reversed.

The most common use case for OTP memory will be enabling USB boot on Raspberry Pi 3 Model B or Compute Module 3.

3.6.1.2.1 Enabling USB Boot Mode for Raspberry Pi 3 Model B #

  

To permanently allow booting from connected USB mass storage devices on Raspberry Pi 3 Model B, and from its on-board USB Ethernet, prepare a microSD card as described in Section 3.6.3, “Deploying an Appliance Image”. Before unmounting or ejecting the card and booting from it, add to its FAT partition a text file extraconfig.txt (Section 3.6.1.1, “Config.txt”) with the following setting:

program_usb_boot_mode=1

Then continue to boot from the modified microSD card as usual. Once you see output from the U-Boot or GRUB boot loaders or the Linux kernel, you can remove power and then the microSD card. Your device should now be able to boot from USB (Section 3.6.4, “Installation from USB Media”).

Note that once USB boot mode has been enabled for Raspberry Pi 3 Model B, USB boot mode cannot be disabled again (Section 3.6.1.2, “OTP Memory”).

For more details, refer to the Raspberry Pi Foundation Web site: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

For the Raspberry Pi Compute Module 3, the setting required is the same, but the deployment of the modified image is a little more complicated.

There is no battery-backed Real-Time Clock (RTC) on the Raspberry Pi itself.

Note: Time Synchronization

The lack of a Real-Time Clock means that Raspberry Pi devices need to be configured to fetch the time from a network server by Network Time Protocol.

However, base boards for the Raspberry Pi Compute Modules may feature an RTC.

It is also possible to connect an RTC via the GPIO connector, using Hardware Attached on Top (HATs) or other expansion boards.

Either way, check whether the respective RTC chipset is supported by SUSE Linux Enterprise Server. The connected RTC will need to be described to the operating system via a Device Tree Overlay (Section 3.6.1.1, “Config.txt”). For example, the MyPi base board might use:

dtparam=i2c1=on
dtoverlay=i2c-rtc,ds1307

The most common method to deploy an operating system onto Raspberry Pi hardware is to copy a pre-installed system image onto a boot medium, usually a microSD card. This is the simplest and easiest method.

SUSE provides a preconfigured bootable image of SUSE Linux Enterprise Server for Raspberry Pi hardware. This comes with the Btrfs file system, with compression enabled to improve performance and reduce wear on microSD media.

A microSD card with a minimum size of 8 GB is recommended. Faster cards will give better system performance. On the first boot, the operating system automatically expands the file system to fill the card. This means that the first boot will be substantially slower than subsequent boots.

The process of writing the card image onto microSD media is described in the Raspberry Pi Quick Start.

Some models of Raspberry Pi allow booting from USB mass storage devices. This will then allow deploying SUSE Linux Enterprise Server on Raspberry Pi similar to server platforms.

Installation can be performed from a removable USB medium, such as a memory stick, onto a microSD card in the machine's internal slot. Alternatively, it can be performed from a removable USB medium onto another USB medium, such as a USB-connected hard disk.

Note: USB Bandwidth Limitations

Note that the Ethernet controller on the Raspberry Pi 3 is connected to the device's on-board USB 2.0 bus.

Therefore an operating system running from a disk attached via USB must share the total 480 Mbps bandwidth of the USB 2.0 controller. This will limit performance, and could significantly impact network performance.

This limitation does not apply to the Raspberry Pi 4.

Newer models of Raspberry Pi 3 with BCM2837 B0 silicon (silver instead of black chip), including Raspberry Pi 3 Model B+ and Compute Module 3+, allow booting from USB-connected storage devices by default.

On older models, such as Raspberry Pi 3 Model B or Compute Module 3, USB boot can be enabled by booting from a specially prepared microSD card once. See Section 3.6.1.2, “OTP Memory” for instructions.

Because of the hardware's lack of on-board firmware (Section 3.6.1, “Boot Process”), network-booting the Raspberry Pi using PXE is more complex than with more conventional computers.

The process of setting up a PXE boot server for x86 and Arm is described in the SUSE Best Practices document How to Set Up a Multi-PXE Installation Server.

The Raspberry Pi Foundation publishes information on how to boot using PXE one Raspberry Pi from another Raspberry Pi: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

For more information, consult the following resources:

SUSE Linux Enterprise Server runs on the following platforms:

5.1.1.1 Memory Requirements #

  

Different installation methods have different memory requirements during installation. At least 1 GB of memory is recommended for the text-mode installation under z/VM, LPAR, and KVM. Installation in the graphical mode requires at least 1.5 GB of memory.

Note: Memory Requirements with Remote Installation Sources

A minimum of 512 MB of memory is required for installation from NFS, FTP, and SMB installation sources, or when VNC is used. Keep in mind that memory requirements also depend on the number of devices visible to the z/VM guest or the LPAR image. Installation with many accessible devices (even if unused for the installation) may require more memory.

Documentation about restrictions and requirements for this release of SUSE Linux Enterprise Server be found on IBM developerWorks at https://developer.ibm.com/technologies/linux/. We recommend to use the highest service level available. Contact IBM support for minimum requirements.

For z/VM, the following versions are supported:

Since it might be necessary to activate the VM APARs before installing the new MicroCode levels, clarify the order of installation with IBM support.

When installing SUSE Linux Enterprise Server via non-Linux–based NFS or FTP, you might experience problems with NFS or FTP server software. The Windows* standard FTP server can cause errors, so we recommend performing installation via SMB on these machines.

To connect to the SUSE Linux Enterprise Server installation system, one of the following methods is required (SSH or VNC are recommended):

Tip: Additional Information

Before installing SUSE Linux Enterprise Server on IBM Z, consult the README file located in the root directory of the first installation medium of SUSE Linux Enterprise Server.

This section provides a list of hardware for IBM Z supported by SUSE Linux Enterprise Server. Next, the level of the MicroCode (MCL) used in your IBM Z system, which is very important for the installation, is covered. Additional software to install and use for installation is mentioned at the end of this section.

5.2.1.1 Hardware #

  

SUSE Linux Enterprise Server runs on the following platforms:

• IBM zEnterprise System z196 (2817)

• IBM zEnterprise System z114 (2818)

• IBM zEnterprise EC12 (zEC12) (2827)

• IBM zEnterprise BC12 (zBC12) (2828)

• IBM z Systems z13 (2964)

• IBM z Systems z13s (2965)

• IBM z Systems z14 (3906)

• IBM z Systems z14 ZR1 (3907)

• IBM z Systems z15 (8561)

• IBM LinuxONE Emperor (2964)

• IBM LinuxONE Rockhopper (2965)

• IBM LinuxONE Emperor II (3906)

• IBM LinuxONE Rockhopper II (3907)

• IBM LinuxONE Emperor III (8561)

5.2.1.1.1 Memory Requirements #

  

Different installation methods have different memory requirements during installation. After installation is completed, the system administrator may reduce memory to the desired size. At least 1 GB of memory is recommended for the text-mode installation under z/VM, LPAR, and KVM. Installation in the graphical mode requires at least 1.5 GB of memory.

Note: Memory Requirements with Remote Installation Sources

A minimum of 512 MB of memory is required for installation from NFS, FTP, and SMB installation sources, or when VNC is used. Keep in mind that the number of devices visible to the z/VM guest or LPAR image affects memory requirements. Installation with many accessible devices (even if unused for the installation) may require more memory.

5.2.1.1.2 Disk Space Requirements #

  

The disk requirements depend largely on the installation. Commonly, you need more space than the installation software itself needs to have a system that works properly. Minimal requirements for different selections are:

800 MB	Minimal Installation
1.4 GB	Minimal Installation + Base System
2.6 GB	Default Installation
3.6 GB+	Recommended (this is with graphical desktop, development packages, and Java).

5.2.1.1.3 Network Connection #

  

A network connection is required in order to communicate with your SUSE Linux Enterprise Server system. This can be one or several of the following connections or network cards:

• OSA Express Ethernet (including Fast and Gigabit Ethernet)

• HiperSockets or Guest LAN

• 10 GBE, VSWITCH

• RoCE (RDMA over Converged Ethernet)

The following interfaces are still included, but no longer supported:

• CTC (or virtual CTC)

• ESCON

• IP network interface for IUCV

For installations under KVM, make sure the following requirements are met to enable the VM Guest to access the network transparently:

• The virtual network interface is connected to a host network interface.

• The host network interface is connected to a network that the virtual server will join.

• If the host is configured to have a redundant network connection by grouping two independent OSA network ports into a bonded network interface, the identifier for the bonded network interface is bond0. If more than one bonded interface exists, it is bond1, bond2 etc.

• A non-redundant network connection setup requires the identifier of the single network interface. The identifier has the following format: enccw0.0.NNNN, where NNNN is the device number of the desired network interface.

5.2.1.3 Software #

  

When installing SUSE Linux Enterprise Server via non-Linux–based NFS or FTP, you might experience problems with NFS or FTP server software. The Windows* standard FTP server can cause errors, so installing via SMB on these machines is generally recommended.

To connect to the SUSE Linux Enterprise Server installation system, one of the following methods is required (SSH or VNC are recommended):

SSH with Terminal Emulation (xterm compatible)

SSH is a standard Unix tool that is present on most Unix or Linux systems. For Windows, you can use the Putty SSH client.

VNC Client

For Linux, the vncviewer VNC client is included in SUSE Linux Enterprise Server as part of the tightvnc package. For Windows, TightVNC is also available.

X Server

Find a suitable X server implementation on any Linux or Unix workstation. There are many commercial X Window System environments for Windows and macOS*. Some can be downloaded as free trial versions.

Tip: Additional Information

Before installing SUSE Linux Enterprise Server on IBM Z, consult the README file located in the root directory of the first installation medium of SUSE Linux Enterprise Server. This file complements this documentation.

This section gives an overview of the different types of installation possible with SUSE Linux Enterprise Server for IBM Z. SUSE Linux Enterprise Server can be installed in an LPAR, as a guest within z/VM, or as a guest within KVM.

Depending on the mode of installation (LPAR or z/VM), there are different possibilities for starting the installation process and IPLing the installed system.

This section provides the information needed to do an IPL for the first installation. Depending on the type of installation, different options need to be used. The VM reader, load from CD-ROM or server and load from an SCSI-attached DVD-ROM options are discussed. Installing the software packages, which is done over the network, does not require the IPL medium.

This section provides detailed information about making the SUSE Linux Enterprise Server IBM Z installation data accessible for installation. Depending on your computer and system environment, choose between NFS or FTP installation. If you are running Microsoft Windows workstations in your environment, you can use the Windows network (including the SMB protocol) to install SUSE Linux Enterprise Server on your IBM Z system.

Tip: IPL from DVD

It is possible to IPL from DVD and use the DVD as the installation medium. This is very convenient if you have restrictions setting up an installation server providing installation media over your network. The prerequisite is an FCP-attached SCSI DVD Drive.

Note: No Installation from Hard Disk

It is not possible to perform installation from a hard disk by putting the content of the DVD to a partition on a DASD.

5.3.1.1 Using a Linux Workstation or SUSE Linux Enterprise Server DVD #

  

You can use a Linux workstation in your computer environment to provide the installation data to the IBM Z installation process by NFS or FTP. If the Linux workstation runs SUSE Linux Enterprise Server, you can set up an installation server (NFS or FTP) using the YaST Installation Server module as described in Section 16.1, “Setting Up an Installation Server Using YaST”.

Important: Exporting Mounted Devices with NFS

Exporting the file system root (/) does not automatically export the mounted devices, such as DVD. Therefore, you need to explicitly name the mount point in /etc/exports:

/media/dvd  *(ro)

After changing this file, restart the NFS server with the command sudo systemctl restart nfsserver.

Setting up an FTP server on a Linux system involves the installation and configuration of server software like vsftpd. If you are using SUSE Linux Enterprise Server, refer to Book “Administration Guide”, Chapter 38 “Setting Up an FTP Server with YaST” for installation instructions. Downloading the installation data via anonymous login is not supported, therefore you need to configure the FTP server to support user authentication.

5.3.1.1.1 SUSE Linux Enterprise Server on DVD #

  

The first installation medium of the SUSE Linux Enterprise Server for IBM Z contains a bootable Linux image for Intel-based workstations and an image for IBM Z.

For Intel-based workstations, boot from this medium. When prompted, choose the desired answer language and keyboard layout and select Start rescue system. You need at least 64 MB RAM for this. No disk space is needed, because the entire rescue system resides in the workstation's RAM. This approach requires setting up the networking of the workstation manually.

For IBM Z, IPL your LPAR/VM guest from this medium as described in Section 5.3.4.1.2, “IPL from FCP-Attached SCSI DVD”. After entering your network parameters, the installation system treats the medium as the source of installation data. Because IBM Z cannot have an X11-capable terminal attached directly, choose between VNC or SSH installation. Refer to Section 11.3, “Monitoring Installation via VNC” or Section 11.4, “Monitoring Installation via SSH” for more information. SSH also provides a graphical installation by tunneling the X connection through SSH with ssh -X.

smb://DOMAIN;USER:PW@SERVERNAME/SHAREPATH

> sudo cobbler import --path=PATH1 --name=IDENTIFIER2 --arch=s390x

> sudo cobbler distro add --arch=s390 --breed=suse --name="IDENTIFIER"1 \
  --os-version=sles152 \
  --initrd=/srv/www/cobbler/ks_mirror/IDENTIFIER/boot/s390x/initrd3 \
  --kernel=/srv/www/cobbler/ks_mirror/IDENTIFIER/boot/s390x/linux4 \
  --kopts="install=http://cobbler.example.com/cobbler/ks_mirror/IDENTIFIER"5

> sudo cobbler distro edit \
--name=IDENTIFIER1 --os-version=sles102 --ksmeta=""3
--kopts="install=http://cobbler.example.com/cobbler/ks_mirror/IDENTIFIER"4

> sudo cobbler system add --name=linux01 --hostname=linux01.example.com \
--profile=IDENTIFIER --interface=qdio \
--ip-address=192.168.2.103 --subnet=192.168.2.255 --netmask=255.255.255.0 \
--name-servers=192.168.1.116 --name-servers-search=example.com \
--gateway=192.168.2.1 --kopts="KERNEL_OPTIONS"

--kopts=" \
AutoYaST=http://192.168.0.5/autoinst.xml \
Hostname=linux01.example.com \
Domain=example.com \
HostIP=192.168.2.103 \
Gateway=192.168.2.1 \
Nameserver=192.168.1.116 \
Searchdns=example.com \
InstNetDev=osa; \
Netmask=255.255.255.0 \
Broadcast=192.168.2.255 \
OsaInterface=qdio \
Layer2=0 \
PortNo=0 \
ReadChannel=0.0.0700 \
WriteChannel=0.0.0701 \
DataChannel=0.0.0702 \
DASD=600"

5.3.1.4 Installing from a USB Flash Drive of the HMC #

  

Installation of SUSE Linux Enterprise Server on IBM Z servers usually requires a network installation source. If this requirement cannot be fulfilled, SUSE Linux Enterprise Server allows you to use the USB flash drive of the Hardware Management Console (HMC) as an installation source for installation on an LPAR.

To perform installation from the USB flash drive of the HMC, proceed as follows:

• Add install=hmc:/ to the parmfile (see Section 5.5, “The Parmfile—Automating the System Configuration”) or kernel options.

• In the manual-mode installation using linuxrc, choose Start Installation, then Installation, and then Hardware Management Console. The installation medium must be in the HMC.

Important: Configure Network

Before starting the installation, specify a network configuration in linuxrc. You cannot do this via boot parameters, and it is very likely that you will need network access. In linuxrc, go to Start Installation, then choose Network Setup.

Important: Linux System Must Boot First

Before granting access to the media in the USB flash drive of the HMC, wait until the Linux system is booted. IPLing can disrupt the connection between the HMC and the LPAR. If the first attempt to use the described method fails, you can grant the access and retry the option HMC.

Note: Installation Repository

The USB flash drive is not kept as an installation repository, as the installation is a one-time procedure. If you need an installation repository, register and use the online repository.

This section describes SUSE Linux Enterprise Server installation steps for each installation mode. When the preparation steps described in the previous chapters have been completed, follow the overview of the desired installation mode.

As described in Section 5.3.1, “Making the Installation Data Available”, there are three different installation modes for Linux on IBM Z: LPAR, z/VM, and KVM guest installation.

Wait until the kernel has completed its start-up routines. If you perform the installation in basic mode or in an LPAR, open the Operating System Messages on the HMC or SE.

First, choose Start Installation in the linuxrc main menu. Then choose Start Installation or Update to start the installation process. Select Network as the installation medium, then select the type of network protocol to use for the installation. Section 5.3.1, “Making the Installation Data Available” describes how to make the installation data available for the various types of network connections. Currently, FTP, HTTP, NFS, and SMB/CIFS (Windows file sharing) are supported.

From the list of available devices, choose an OSA or HiperSockets network device for receiving the installation data. Although the list may contain CTC, ESCON, or IUCV devices, they are no longer supported on SUSE Linux Enterprise Server.

Choose the network device.

 1) IBM parallel CTC Adapter (0.0.0600)
 2) IBM parallel CTC Adapter (0.0.0601)
 3) IBM parallel CTC Adapter (0.0.0602)
 4) IBM Hipersocket (0.0.0800)
 5) IBM Hipersocket (0.0.0801)
 6) IBM Hipersocket (0.0.0802)
 7) IBM OSA Express Network card (0.0.0700)
 8) IBM OSA Express Network card (0.0.0701)
 9) IBM OSA Express Network card (0.0.0702)
10) IBM OSA Express Network card (0.0.f400)
11) IBM OSA Express Network card (0.0.f401)
12) IBM OSA Express Network card (0.0.f402)
13) IBM IUCV

> 4

Device address for read channel. (Enter '+++' to abort).
[0.0.0800]> 0.0.0800

Device address for write channel. (Enter '+++' to abort).
[0.0.0801]> 0.0.0801

Device address for data channel. (Enter '+++' to abort).
[0.0.0802]> 0.0.0802

Choose the network device.

 1) IBM parallel CTC Adapter (0.0.0600)
 2) IBM parallel CTC Adapter (0.0.0601)
 3) IBM parallel CTC Adapter (0.0.0602)
 4) IBM Hipersocket (0.0.0800)
 5) IBM Hipersocket (0.0.0801)
 6) IBM Hipersocket (0.0.0802)
 7) IBM OSA Express Network card (0.0.0700)
 8) IBM OSA Express Network card (0.0.0701)
 9) IBM OSA Express Network card (0.0.0702)
10) IBM OSA Express Network card (0.0.f400)
11) IBM OSA Express Network card (0.0.f401)
12) IBM OSA Express Network card (0.0.f402)
13) IBM IUCV

> 7

Enter the relative port number. (Enter '+++' to abort).
> 0

Device address for read channel. (Enter '+++' to abort).
[0.0.0700]> 0.0.0700

Device address for write channel. (Enter '+++' to abort).
[0.0.0701]> 0.0.0701

Device address for data channel. (Enter '+++' to abort).
[0.0.0702]> 0.0.0702

Enable OSI Layer 2 support?

0) <-- Back <--
1) Yes
2) No

> 1

MAC address. (Enter '+++' to abort).
> +++

Automatic configuration via DHCP?

0) <-- Back <--
1) Yes
2) No

> 2

Enter your IP address with network prefix.

You can enter more than one, separated by space, if necessary.
Leave empty for autoconfig.

Examples: 192.168.5.77/24 2001:db8:75:fff::3/64. (Enter '+++' to abort).
> 192.168.0.20/24

Enter your name server IP address.

You can enter more than one, separated by space, if necessary.
Leave empty if you don't need one.

Examples: 192.168.5.77 2001:db8:75:fff::3. (Enter '+++' to abort).
> 192.168.0.1

Enter your search domains, separated by a space:. (Enter '+++' to abort).
> example.com

Enter the IP address of your name server. Leave empty if you do not need one. (En
ter '+++' to abort).
> 192.168.0.1

After loading the installation system, linuxrc prompts you to choose what type of display to use to control the installation procedure. The available options include X11 (X Window System), VNC (Virtual Network Computing protocol), SSH (text mode or X11 installation via Secure Shell), or ASCII Console. The recommended options are VNC or SSH.

If the ASCII Console option is selected, YaST starts in text mode, and you can perform the installation directly within your terminal. See Book “Administration Guide”, Chapter 4 “YaST in Text Mode” for instructions on how to use YaST in the text mode. Using the ASCII Console is only useful when installing into LPAR.

Note: Terminal Emulation for ASCII Console

To be able to work with YaST in the text mode, it needs to run in a terminal with VT220/Linux emulation (also called ASCII console).

5.3.6.2 Initiating the Installation for the X Window System #

  

Important: X Authentication Mechanism

The direct installation with the X Window System relies on an authentication mechanism based on host names. This mechanism is disabled in current SUSE Linux Enterprise Server versions. We recommend performing the installation using SSH or VNC.

To remotely control an installation via X forwarding, follow these steps:

1. Make sure that the X server allows the client (the system that is installed) to connect. Set the variable DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" in the file /etc/sysconfig/displaymanager. Restart the X server and allow client binding to the server using xhost CLIENT_IP_ADDRESS.

2. When prompted at the installation system, enter the IP address of the machine running the X server.

3. Wait until YaST opens, then start the installation.

5.3.6.3 Initiating the Installation for SSH #

  

To connect to an installation system with the name earth via SSH, use the ssh -X earth command. If your workstation runs on Microsoft Windows, use the Putty tool available from http://www.chiark.greenend.org.uk/~sgtatham/putty/. Set Enable X11 forwarding in Putty under Connection › SSH › X11.

If you use another operating system, execute ssh -X earth to connect to an installation system with the name earth. X-Forwarding over SSH is supported if you have a local X server available. Otherwise, YaST provides a text interface over ncurses.

When prompted, enter the root user name and log in with your password. Enter yast.ssh to start YaST. YaST then guides you through the installation.

Important: Fixing YaST over SSH Issue

In certain situations, running the GUI version of YaST over SSH with X forwarding may fail with the following error message:

XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:11.0"

In this case you have two options.

• Run YaST with the QT_XCB_GL_INTEGRATION=none option, for example:

  QT_XCB_GL_INTEGRATION=none yast.ssh
  QT_XCB_GL_INTEGRATION=none yast2 disk

• Run the ncurses version of YaST application by disabling X forwarding or by specifying ncurses as the desired UI. To do the latter, use the yast2 disk --ncurses or YUI_PREFERED_BACKEND=ncurses yast2 disk command.

Proceed with the installation procedure as described in Chapter 8, Installation Steps.

On SLES 10 and 11 the boot process was handled by the zipl boot loader. To enable booting from Btrfs partitions and supporting system rollbacks with Snapper, the way SUSE Linux Enterprise Server is booted on IBM Z has changed.

GRUB 2 replaces zipl on SUSE Linux Enterprise Server for IBM Z. GRUB 2 on the AMD64/Intel 64 architecture includes device drivers on the firmware level to access the file system. On the mainframe there is no firmware and adding ccw to GRUB 2 would not only be a major undertaking, but would also require a reimplementation of zipl in GRUB 2. Therefore SUSE Linux Enterprise Server uses a two-stage approach:

For more details on the boot process, refer to Book “Administration Guide”, Chapter 12 “Introduction to the Boot Process”.

Important: Configuring the Network Interface

The settings described 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 19 “Basic Networking”, Section 19.5 “Configuring a Network Connection Manually”.

Each of the interfaces requires certain setup options:

I/O device auto-configuration is a mechanism that allows users to specify IDs and settings of I/O devices that should be automatically enabled in Linux. This information is specified for an LPAR via an HMC running in the DPM (Dynamic Partition Manager) mode.

Note

The I/O device auto-configuration functionality is available on systems with the DPM running. DPM runs by default on LinuxONE machines. For IBM Z, this functionality must be ordered.

In linuxrc, the DeviceAutoConfig parameter controls the use of I/O device auto-configuration data for IBM Z systems.

If device auto-config is disabled by the user, the kernel parameter rd.zdev=no-auto is added to the boot options of the target system.

To enable I/O auto-configuration using YaST, run the yast2 system_settings command, switch to the Kernel Settings section, and enable the Enable I/O device auto-configuration option.

To disable I/O auto-configuration in an AutoYaST profile, add the following kernel parameter in the append section of the global boot loader options. For example:

<bootloader>
  <global>
    <append>rd.zdev=no-auto</append>
  </global>
</bootloader>

For more context on the AutoYaST boot loader options, see Book “AutoYaST Guide”, Chapter 4 “Configuration and Installation Options”, Section 4.4 “The Boot Loader”.

During installation, the status of the auto-configuration setting is displayed in the Device Settings section of the Installation Settings' screen.

The maximum capacity of a parmfile is 860 characters. As a rule of thumb, the parmfile should contain a maximum of 10 lines with no more than 79 characters. When reading a parmfile, all lines are concatenated without adding white spaces, therefore the last character (79) of each line needs to be a Space.

To receive potential error messages on the console, use

linuxrclog=/dev/console

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb
instnetdev=osa osainterface=qdio layer2=1 osahwaddr=
pointopoint=192.168.0.1 hostip=192.168.0.2
nameserver=192.168.0.3 DeviceAutoConfig=1
install=nfs://192.168.0.4/SLES/SLES-12-Server/s390x/DVD1
autoyast=http://192.168.0.5/autoinst.xml
linuxrclog=/dev/console vnc=1 VNCPassword=testing

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb
AutoYast=nfs://192.168.1.1/autoinst/s390.xml
Hostname=zsystems.example.com HostIP=192.168.1.2
Gateway=192.168.1.3 Nameserver=192.168.1.4
InstNetDev=hsi layer2=0
Netmask=255.255.255.128 Broadcast=192.168.1.255
readchannel=0.0.702c writechannel=0.0.702d datachannel=0.0.702e
install=nfs://192.168.1.5/SLES-12-Server/s390x/DVD1/
ssh=1 ssh.password=testing linuxrclog=/dev/console

ro ramdisk_size=50000 MANUAL=0 PORTNO=1 ReadChannel=0.0.b140
WriteChannel=0.0.b141 DataChannel=0.0.b142
cio_ignore=all,!condev,!0.0.b140-0.0.b142,!0.0.e92c,!0.0.5000,!0.0.5040
HostIP= Gateway= Hostname=zsystems.example.com nameserver=192.168.0.1
Install=ftp://user:password@10.0.0.1/s390x/SLES15.0/INST/ usevnc=1
vncpassword=12345 InstNetDev=osa Layer2=1 OSAInterface=qdio ssl_certs=0
osahwaddr= domain=example.com self_update=0
vlanid=201

A general coverage of Linux on IBM Z can be found in the following documents:

These documents might not reflect the current state of Linux, but the principles of Linux deployment outlined there remain accurate.

Refer to the following documents for technical information about the Linux kernel and application topics. For the most recent versions of the documents, visit (https://developer.ibm.com/technologies/linux/).

A Redbook for Linux application development is available at http://www.redbooks.ibm.com:

Refer to the following Redbooks, Redpapers, and online resources for more complex IBM Z scenarios:

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

Figure 7.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 13 “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 Server. 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 Server, 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 13 “UEFI (Unified Extensible Firmware Interface)”, Section 13.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 7.2: The Boot Screen on Machines with UEFI #

  

GRUB 2 for EFI on SUSE Linux Enterprise Server 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. Configure additional network interfaces in the installed system by following the instructions given in Book “Administration Guide”, Chapter 19 “Basic Networking”, Section 19.5 “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.

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 11, Remote Installation.

By default, updates for SUSE Linux Enterprise Server are delivered by the SUSE Customer Center. If your network provides a so called 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 8.7, “Registration” for details).

The data that supportconfig (see Book “Administration Guide”, Chapter 42 “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 8.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.

The process can be broken down into two different parts:

8.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 out 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 7.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 7.4.1, “Providing Data to Access an RMT 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 everybody on the local network could announce a registration server.

   4. By querying the SUSE Customer Center.

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

8.2.1.2 Downloading and Applying the Updates #

  

When the updates repository is determined, YaST will check whether an update is available. If so, all the updates will be downloaded and applied to the installation system.

Finally, YaST will be restarted to load the new version and the welcome screen will be shown. If no updates were available, the installation will continue 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 one by specifying a URL through the self_update boot parameter. However, the following points should be considered:

Note: Only One Repository

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

Skip this step if you are not installing on IBM Z hardware.

Figure 8.4: DASD Disk Management #

  

After selecting Configure DASD Disks, an overview lists all available DASDs. To get a clearer picture of the available devices, use the text box located above the list to specify a range of channels to display. To filter the list according to such a range, select Filter.

Specify the DASDs to use for the installation by selecting the corresponding entries in the list. Use Select All to select all DASDs currently displayed. Activate and make the selected DASDs available for the installation by selecting Perform Action › Activate. To format the DASDs, select Perform Action › Format. Alternatively, use the YaST partitioner later as described in Section 10.1, “Using the Expert Partitioner”.

To use zFCP disks for the SUSE Linux Enterprise Server installation, select Configure zFCP Disks in the selection dialog. This opens a dialog with a list of the zFCP disks available on the system. In this dialog, select Add to open another dialog in which to enter zFCP parameters.

To make a zFCP disk available for the SUSE Linux Enterprise Server installation, choose an available Channel Number from the drop-down box. Get WWPNs (World Wide Port Number) and Get LUNs (Logical Unit Number) return lists with available WWPNs and FCP-LUNs, respectively, to choose from. Automatic LUN scanning only works with NPIV enabled.

When completed, exit the zFCP dialog with Next and the general hard disk configuration dialog with Finish to continue with the rest of the configuration.

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

If your organization provides a local registration server, you may alternatively 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 Server. If your organization provides a local registration server, you may alternatively 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 8.6: SUSE Customer Center Registration #

  

Tip: Installing Product Patches at Installation Time

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

If the system was successfully registered during installation, YaST will disable repositories from local installation media such as CD/DVD or flash disks when the installation has been completed. This prevents problems if the installation source is no longer available 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