Menu Close

Chapter 4. Installing Red Hat Enterprise Linux on 64-bit IBM Z

This section describes how to install Red Hat Enterprise Linux on the 64-bit IBM Z architecture.

4.1. Planning for installation on 64-bit IBM Z

Red Hat Enterprise Linux 9 runs on IBM z14 or IBM LinuxONE II systems, or later.

The installation process assumes that you are familiar with the 64-bit IBM Z and can set up logical partitions (LPARs) and z/VM guest virtual machines.

For installation of Red Hat Enterprise Linux on 64-bit IBM Z, Red Hat supports Direct Access Storage Device (DASD), SCSI disk devices attached over Fiber Channel Protocol (FCP), and virtio-blk and virtio-scsi devices.

Important

DASDs are hard disks that allow a maximum of three partitions per device. For example, dasda can have partitions dasda1, dasda2, and dasda3.

Pre-installation decisions

  • Whether the operating system is to be run on an LPAR, KVM, or as a z/VM guest operating system.
  • If swap space is needed, and how much. Although it is recommended to assign enough memory to a z/VM guest virtual machine and let z/VM do the necessary swapping, there are cases where the amount of required RAM is hard to predict. Such instances should be examined on a case-by-case basis.
  • Network configuration. Red Hat Enterprise Linux 9 for 64-bit IBM Z supports the following network devices:

    • Real and virtual Open Systems Adapter (OSA)
    • Real and virtual HiperSockets
    • LAN channel station (LCS) for real OSA
    • virtio-net devices

Disk space

You will need to calculate and allocate sufficient disk space on DASDs or SCSI disks.

  • A minimum of 10 GiB is needed for a server installation, 20 GiB if you want to install all packages.
  • Disk space is also required for any application data. After the installation, you can add or delete more DASD or SCSI disk partitions.
  • The disk space used by the newly installed Red Hat Enterprise Linux system (the Linux instance) must be separate from the disk space used by other operating systems you have installed on your system.

RAM

Ensure that your system has sufficient RAM available:

  • Minimum 1.5 GiB when installing from NFS.
  • Minimum 3 GiB when installing from an HTTP or FTP installation source.
  • When installing in text mode, 1GiB is sufficient only if you are using an NFS installation source.
  • Red Hat recommends 2 GiB for the installed Linux instance. However, 1GiB is sufficient on a properly tuned system.
Note

Additional resources

4.2. Overview of installation process on 64-bit IBM Z servers

You can install Red Hat Enterprise Linux on 64-bit IBM Z interactively or in unattended mode. Installation on 64-bit IBM Z differs from other architectures as it is typically performed over a network, and not from local media. The installation consists of three phases:

  1. Booting the installation

    • Connect to the mainframe
    • Customize the boot parameters
    • Perform an initial program load (IPL), or boot from the media containing the installation program
  2. Connecting to the installation system

    • From a local machine, connect to the remote 64-bit IBM Z system using SSH, and start the installation program using Virtual Network Computing (VNC)
  3. Completing the installation using the RHEL installation program

4.3. Boot media for installing RHEL on 64-bit IBM Z servers

After establishing a connection with the mainframe, you need to perform an initial program load (IPL), or boot, from the medium containing the installation program. This document describes the most common methods of installing Red Hat Enterprise Linux on 64-bit IBM Z. In general, any method may be used to boot the Linux installation system, which consists of a kernel (kernel.img) and initial RAM disk (initrd.img) with parameters in the generic.prm file supplemented by user defined parameters. Additionally, a generic.ins file is loaded which determines file names and memory addresses for the initrd, kernel and generic.prm.

The Linux installation system is also called the installation program in this book.

The control point from where you can start the IPL process depends on the environment where your Linux is to run. If your Linux is to run as a z/VM guest operating system, the control point is the control program (CP) of the hosting z/VM. If your Linux is to run in LPAR mode, the control point is the mainframe’s Support Element (SE) or an attached 64-bit IBM Z Hardware Management Console (HMC).

You can use the following boot media only if Linux is to run as a guest operating system under z/VM:

  • z/VM reader

You can use the following boot media only if Linux is to run in LPAR mode:

  • SE or HMC through a remote FTP server
  • SE or HMC DVD

You can use the following boot media for both z/VM and LPAR:

  • DASD
  • SCSI disk device that is attached through an FCP channel

If you use DASD or an FCP-attached SCSI disk device as boot media, you must have a configured zipl boot loader.

4.4. Customizing boot parameters

Before the installation can begin, you must configure some mandatory boot parameters. When installing through z/VM, these parameters must be configured before you boot into the generic.prm file. When installing on an LPAR, the rd.cmdline parameter is set to ask by default, meaning that you will be given a prompt on which you can enter these boot parameters. In both cases, the required parameters are the same.

Note

All network configuration must now be specified by either by using a parameter file, or at the prompt.

Installation source
An installation source must always be configured.

Use the inst.repo option to specify the package source for the installation.

Network devices

Network configuration must be provided if network access will be required during the installation. If you plan to perform an unattended (Kickstart-based) installation using only local media such as a hard drive, network configuration can be omitted.

Use the ip= option for basic network configuration, and other options as required.

Also use the rd.znet= kernel option, which takes a network protocol type, a comma delimited list of sub-channels, and, optionally, comma delimited sysfs parameter and value pairs. This parameter can be specified multiple times to activate multiple network devices.

For example:

rd.znet=qeth,0.0.0600,0.0.0601,0.0.0602,layer2=1,portname=foo

The qeth device driver assigns the same interface name for Ethernet and Hipersockets devices: enc<device number>. The bus ID is composed of the channel subsystem ID, subchannel set ID, and device number, separated by dots; the device number is the last part of the bus ID, without leading zeroes and dots. For example, the interface name will be enca00 for a device with the bus ID 0.0.0a00.

Storage devices

At least one storage device must always be configured for text mode installations.

The rd.dasd= option takes a Direct Access Storage Device (DASD) adapter device bus identifier. For multiple DASDs, specify the parameter multiple times, or use a comma separated list of bus IDs. To specify a range of DASDs, specify the first and the last bus ID. Example:

rd.dasd=0.0.0200 rd.dasd=0.0.0202(ro),0.0.0203(ro:failfast),0.0.0205-0.0.0207

The rd.zfcp= option takes a SCSI over FCP (zFCP) adapter device bus identifier, a target world wide port name (WWPN), and an FCP LUN, then activates one path to a SCSI disk. This parameter needs to be specified at least twice to activate multiple paths to the same disk. This parameter can be specified multiple times to activate multiple disks, each with multiple paths.

rd.zfcp=0.0.4000,0x5005076300C213e9,0x5022000000000000
Kickstart options
If you are using a Kickstart file to perform an automatic installation, you must always specify the location of the Kickstart file using the inst.ks= option. For an unattended, fully automatic Kickstart installation, the inst.cmdline option is also useful.

An example customized generic.prm file containing all mandatory parameters look similar to the following example:

Example 4.1. Customized generic.prm file

ro ramdisk_size=40000 cio_ignore=all,!condev
inst.repo=http://example.com/path/to/repository
rd.znet=qeth,0.0.0600,0.0.0601,0.0.0602,layer2=1,portno=0,portname=foo
ip=192.168.17.115::192.168.17.254:24:foobar.systemz.example.com:enc600:none
nameserver=192.168.17.1
rd.dasd=0.0.0200 rd.dasd=0.0.0202
rd.zfcp=0.0.4000,0x5005076300c213e9,0x5022000000000000
rd.zfcp=0.0.5000,0x5005076300dab3e9,0x5022000000000000
inst.ks=http://example.com/path/to/kickstart

Some installation methods also require a file with a mapping of the location of installation data in the file system of the HMC DVD or FTP server and the memory locations where the data is to be copied.

The file is typically named generic.ins, and contains file names for the initial RAM disk, kernel image, and parameter file (generic.prm) and a memory location for each file. An example generic.ins will look similar to the following example:

Example 4.2. Sample generic.ins file

images/kernel.img 0x00000000
images/initrd.img 0x02000000
images/genericdvd.prm 0x00010480
images/initrd.addrsize 0x00010408

A valid generic.ins file is provided by Red Hat along with all other files required to boot the installer. Modify this file only if you want to, for example, load a different kernel version than default.

Additional resources

4.5. Parameters and configuration files on 64-bit IBM Z

This section contains information about the parameters and configuration files on 64-bit IBM Z.

4.5.1. Required configuration file parameters on 64-bit IBM Z

Several parameters are required and must be included in the parameter file. These parameters are also provided in the file generic.prm in directory images/ of the installation DVD.

  • ro

    Mounts the root file system, which is a RAM disk, read-only.

  • ramdisk_size=size

    Modifies the memory size reserved for the RAM disk to ensure that the Red Hat Enterprise Linux installation program fits within it. For example: ramdisk_size=40000.

The generic.prm file also contains the additional parameter cio_ignore=all,!condev. This setting speeds up boot and device detection on systems with many devices. The installation program transparently handles the activation of ignored devices.

4.5.2. 64-bit IBM Z/VM configuration file

Under z/VM, you can use a configuration file on a CMS-formatted disk. The purpose of the CMS configuration file is to save space in the parameter file by moving the parameters that configure the initial network setup, the DASD, and the FCP specification out of the parameter file.

Each line of the CMS configuration file contains a single variable and its associated value, in the following shell-style syntax: variable=value.

You must also add the CMSDASD and CMSCONFFILE parameters to the parameter file. These parameters point the installation program to the configuration file:

CMSDASD=cmsdasd_address

Where cmsdasd_address is the device number of a CMS-formatted disk that contains the configuration file. This is usually the CMS user’s A disk.

For example: CMSDASD=191

CMSCONFFILE=configuration_file

Where configuration_file is the name of the configuration file. This value must be specified in lower case. It is specified in a Linux file name format: CMS_file_name.CMS_file_type.

The CMS file REDHAT CONF is specified as redhat.conf. The CMS file name and the file type can each be from one to eight characters that follow the CMS conventions.

For example: CMSCONFFILE=redhat.conf

4.5.3. Installation network, DASD and FCP parameters on 64-bit IBM Z

These parameters can be used to automatically set up the preliminary network, and can be defined in the CMS configuration file. These parameters are the only parameters that can also be used in a CMS configuration file. All other parameters in other sections must be specified in the parameter file.

NETTYPE="type"

Where type must be one of the following: qeth, lcs, or ctc. The default is qeth.

Choose lcs for:

  • OSA-Express features

Choose qeth for:

  • OSA-Express features
  • HiperSockets
  • Virtual connections on z/VM, including VSWTICH and Guest LAN
SUBCHANNELS="device_bus_IDs"

Where device_bus_IDs is a comma-separated list of two or three device bus IDs. The IDs must be specified in lowercase.

Provides required device bus IDs for the various network interfaces:

qeth: SUBCHANNELS="read_device_bus_id,write_device_bus_id,data_device_bus_id"
lcs or ctc: SUBCHANNELS="read_device_bus_id,write_device_bus_id"

For example (a sample qeth SUBCHANNEL statement):

SUBCHANNELS="0.0.f5f0,0.0.f5f1,0.0.f5f2"
PORTNAME="osa_portname" PORTNAME="lcs_portnumber"

This variable supports OSA devices operating in qdio mode or in non-qdio mode.

When using qdio mode (NETTYPE="qeth"), osa_portname is the portname specified on the OSA device when operating in qeth mode.

When using non-qdio mode (NETTYPE="lcs"), lcs_portnumber is used to pass the relative port number as a decimal integer in the range of 0 through 15.

PORTNO="portnumber"
You can add either PORTNO="0" (to use port 0) or PORTNO="1" (to use port 1 of OSA features with two ports per CHPID) to the CMS configuration file to avoid being prompted for the mode.
LAYER2="value"

Where value can be 0 or 1.

Use LAYER2="0" to operate an OSA or HiperSockets device in layer 3 mode (NETTYPE="qeth"). Use LAYER2="1" for layer 2 mode. For virtual network devices under z/VM this setting must match the definition of the GuestLAN or VSWITCH to which the device is coupled.

To use network services that operate on layer 2 (the Data Link Layer or its MAC sublayer) such as DHCP, layer 2 mode is a good choice.

The qeth device driver default for OSA devices is now layer 2 mode. To continue using the previous default of layer 3 mode, set LAYER2="0" explicitly.

VSWITCH="value"

Where value can be 0 or 1.

Specify VSWITCH="1" when connecting to a z/VM VSWITCH or GuestLAN, or VSWITCH="0" (or nothing at all) when using directly attached real OSA or directly attached real HiperSockets.

MACADDR="MAC_address"

If you specify LAYER2="1" and VSWITCH="0", you can optionally use this parameter to specify a MAC address. Linux requires six colon-separated octets as pairs lower case hex digits - for example, MACADDR=62:a3:18:e7:bc:5f. Note that this is different from the notation used by z/VM.

If you specify LAYER2="1" and VSWITCH="1", you must not specify the MACADDR, because z/VM assigns a unique MAC address to virtual network devices in layer 2 mode.

CTCPROT="value"

Where value can be 0, 1, or 3.

Specifies the CTC protocol for NETTYPE="ctc". The default is 0.

HOSTNAME="string"
Where string is the host name of the newly-installed Linux instance.
IPADDR="IP"
Where IP is the IP address of the new Linux instance.
NETMASK="netmask"

Where netmask is the netmask.

The netmask supports the syntax of a prefix integer (from 1 to 32) as specified in IPv4 classless interdomain routing (CIDR). For example, you can specify 24 instead of 255.255.255.0, or 20 instead of 255.255.240.0.

GATEWAY="gw"
Where gw is the gateway IP address for this network device.
MTU="mtu"
Where mtu is the Maximum Transmission Unit (MTU) for this network device.
DNS="server1:server2:additional_server_terms:serverN"

Where "server1:server2:additional_server_terms:serverN" is a list of DNS servers, separated by colons. For example:

DNS="10.1.2.3:10.3.2.1"
SEARCHDNS="domain1:domain2:additional_dns_terms:domainN"

Where "domain1:domain2:additional_dns_terms:domainN" is a list of the search domains, separated by colons. For example:

SEARCHDNS="subdomain.domain:domain"

You only need to specify SEARCHDNS= if you specify the DNS= parameter.

DASD=

Defines the DASD or range of DASDs to configure for the installation.

The installation program supports a comma-separated list of device bus IDs, or ranges of device bus IDs with the optional attributes ro, diag, erplog, and failfast. Optionally, you can abbreviate device bus IDs to device numbers with leading zeros stripped. Any optional attributes should be separated by colons and enclosed in parentheses. Optional attributes follow a device bus ID or a range of device bus IDs.

The only supported global option is autodetect. This does not support the specification of non-existent DASDs to reserve kernel device names for later addition of DASDs. Use persistent DASD device names such as /dev/disk/by-path/name to enable transparent addition of disks later. Other global options such as probeonly, nopav, or nofcx are not supported by the installation program.

Only specify those DASDs that need to be installed on your system. All unformatted DASDs specified here must be formatted after a confirmation later on in the installation program.

Add any data DASDs that are not needed for the root file system or the /boot partition after installation.

For example:

DASD="eb1c,0.0.a000-0.0.a003,eb10-eb14(diag),0.0.ab1c(ro:diag)"

For FCP-only environments, remove the DASD= option from the CMS configuration file to indicate no DASD is present.

FCP_n="device_bus_ID WWPN FCP_LUN"

Where:

  • n is typically an integer value (for example FCP_1 or FCP_2) but could be any string with alphabetic or numeric characters or underscores.
  • device_bus_ID specifies the device bus ID of the FCP device representing the host bus adapter (HBA) (for example 0.0.fc00 for device fc00).
  • WWPN is the world wide port name used for routing (often in conjunction with multipathing) and is as a 16-digit hex value (for example 0x50050763050b073d).
  • FCP_LUN refers to the storage logical unit identifier and is specified as a 16-digit hexadecimal value padded with zeroes to the right (for example 0x4020400100000000).

    These variables can be used on systems with FCP devices to activate FCP LUNs such as SCSI disks. Additional FCP LUNs can be activated during the installation interactively or by means of a Kickstart file. An example value looks similar to the following:

    FCP_1="0.0.fc00 0x50050763050b073d 0x4020400100000000"
    Important

    Each of the values used in the FCP parameters (for example FCP_1 or FCP_2) are site-specific and are normally supplied by the FCP storage administrator.

The installation program prompts you for any required parameters not specified in the parameter or configuration file except for FCP_n.

4.5.4. Parameters for kickstart installations on 64-bit IBM Z

The following parameters can be defined in a parameter file but do not work in a CMS configuration file.

inst.ks=URL
References a Kickstart file, which usually resides on the network for Linux installations on 64-bit IBM Z. Replace URL with the full path including the file name of the Kickstart file. This parameter activates automatic installation with Kickstart.
inst.cmdline
This requires installation with a Kickstart file that answers all questions, because the installation program does not support interactive user input in cmdline mode. Ensure that your Kickstart file contains all required parameters before you use the inst.cmdline option. If a required command is missing, the installation will fail.

4.5.5. Miscellaneous parameters on 64-bit IBM Z

The following parameters can be defined in a parameter file but do not work in a CMS configuration file.

rd.live.check
Turns on testing of an ISO-based installation source; for example, when using inst.repo= with an ISO on local hard disk or mounted with NFS.
inst.nompath
Disables support for multipath devices.
inst.proxy=[protocol://][username[:password]@]host[:port]
Specify a proxy to use with installation over HTTP, HTTPS or FTP.
inst.rescue
Boot into a rescue system running from a RAM disk that can be used to fix and restore an installed system.
inst.stage2=URL

Specifies a path to a tree containing install.img, not to the install.img directly. Otherwise, follows the same syntax as inst.repo=. If inst.stage2 is specified, it typically takes precedence over other methods of finding install.img. However, if Anaconda finds install.img on local media, the inst.stage2 URL will be ignored.

If inst.stage2 is not specified and install.img cannot be found locally, Anaconda looks to the location given by inst.repo= or method=.

If only inst.stage2= is given without inst.repo= or method=, Anaconda uses whatever repos the installed system would have enabled by default for installation.

Use the option multiple times to specify multiple HTTP, HTTPS or FTP sources. The HTTP, HTTPS or FTP paths are then tried sequentially until one succeeds:

inst.stage2=http://hostname/path_to_install_tree/
inst.stage2=http://hostname/path_to_install_tree/
inst.stage2=http://hostname/path_to_install_tree/
inst.syslog=IP/hostname[:port]
Sends log messages to a remote syslog server.

The boot parameters described here are the most useful for installations and trouble shooting on 64-bit IBM Z, but only a subset of those that influence the installation program.

4.5.6. Sample parameter file and CMS configuration file on 64-bit IBM Z

To change the parameter file, begin by extending the shipped generic.prm file.

Example of generic.prm file:

ro ramdisk_size=40000 cio_ignore=all,!condev
CMSDASD="191" CMSCONFFILE="redhat.conf"
inst.vnc
inst.repo=http://example.com/path/to/dvd-contents

Example of redhat.conf file configuring a QETH network device (pointed to by CMSCONFFILE in generic.prm):

NETTYPE="qeth"
SUBCHANNELS="0.0.0600,0.0.0601,0.0.0602"
PORTNAME="FOOBAR"
PORTNO="0"
LAYER2="1"
MACADDR="02:00:be:3a:01:f3"
HOSTNAME="foobar.systemz.example.com"
IPADDR="192.168.17.115"
NETMASK="255.255.255.0"
GATEWAY="192.168.17.254"
DNS="192.168.17.1"
SEARCHDNS="systemz.example.com:example.com"
DASD="200-203"

Additional resources

4.6. Installing in an LPAR

4.6.1. Booting the installation in an LPAR

When installing in a logical partition (LPAR), you can boot from:

  • The FTP server
  • The DASD or an FCP-attached SCSI disk prepared with the zipl boot loader

Procedure

Perform these steps to boot the installation.

  1. Log in on the IBM System Z Hardware Management Console (HMC) or the Support Element (SE) as a user with sufficient privileges to install a new operating system to an LPAR. The SYSPROG user is recommended.
  2. On the Systemstab, select the mainframe you want to work with, then on the Partitions tab select the LPAR to which you wish to install.
  3. At the bottom of the screen, under Daily, find the Operating System Messages. Double-click Operating System Messages to show the text console on which Linux boot messages will appear.

Continue with the procedure for your installation source.

4.6.2. Connecting to the installation system

After the Initial Program Load (IPL) of the Anaconda installation program is complete, connect to the 64-bit IBM Z system from a local machine, as an install user, using an ssh connection.

You need to connect to the installation system to continue the installation process. Use a VNC mode to run a GUI-based installation or use the established connection to run a text mode installation.

Prerequisite

  • The initial program boot is complete on the 64-bit IBM Z system, and the command prompt displays:

    Starting installer, one moment...
            Please ssh install@my-z-system (system ip address) to begin the install.
  • If you want to restrict VNC access to the installation system, then ensure inst.vncpassword=PASSWORD boot parameter is configured.

Procedure

From a local machine, run the steps below to set up a remote connection with the 64-bit IBM Z system.

  1. On the command prompt, run the following command:

    $ssh install@_my-z-system-domain-name_

    or

    $ssh install@_my-z-system-IP-address_
  2. Depending on whether or not have you configured the inst.vnc parameter, the ssh session displays the following output:

    When inst.vnc parameter is configured:

    Starting installer, one moment...
    Please manually connect your vnc client to my-z-system:1 (_system-ip-address:1_) to begin the install.

    When inst.vnc parameter is not configured:

    Starting installer, one moment...
    Graphical installation is not available. Starting text mode.
    =============
    Text mode provides a limited set of installation options.
    It does not offer custom partitioning for full control
    over the disk layout. Would you like to use VNC mode instead?
    1) Start VNC
    2) Use text mode
    Please make your choice from above ['q' to quit | 'c' to continue | 'r' to refresh]:

    If you have configured the inst.vnc parameter, proceed to step 5.

  3. Enter 1 to start VNC.
  4. Enter a password, if you have not set the inst.vncpassword= boot option, but want to secure the server connection.
  5. From a new command prompt, connect to the VNC server.

    $vncviewer _my-z-system-ip-address:display_number_

    If you have secured the connection, use the password that you have entered in the previous step or the one that you had set for inst.vncpassword= boot option.

    The RHEL installer is launched in the VNC client.

4.6.3. Installing in an LPAR using an FTP Server

Use this procedure when installing Red Hat Enterprise Linux into an LPAR using an FTP server.

Procedure

  1. Double-click Load from Removable Media or Server.
  2. In the dialog box that follows, select FTP Server, and enter the following information:

    • Host Computer - Host name or IP address of the FTP server you want to install from, for example ftp.redhat.com
    • User ID - Your user name on the FTP server. Or, specify anonymous.
    • Password - Your password. Use your email address if you are logging in as anonymous.
    • File location (optional) - Directory on the FTP server holding the Red Hat Enterprise Linux for System z, for example /rhel/s390x/.
  3. Click Continue.
  4. In the dialog that follows, keep the default selection of generic.ins and click Continue.

4.6.4. Installing in an LPAR using a prepared DASD

Use this procedure when installing Red Hat Enterprise Linux into an LPAR using an already prepared DASD.

Procedure

  1. Double-click Load.
  2. In the dialog box that follows, select Normal as the Load type.
  3. As Load address, fill in the device number of the DASD.
  4. As Load parameter, fill in the number corresponding the zipl boot menu entry that you prepared for booting the Red Hat Enterprise Linux installation program.
  5. Click the OK button.

4.6.5. Installing in an LPAR using a prepared FCP attached SCSI disk

Use this procedure when installing Red Hat Enterprise Linux into and LPAR using an already prepared FCP attached SCSI disk.

Procedure

  1. Double-click Load.
  2. In the dialog box that follows, select SCSI as the Load type.
  3. As Load address, fill in the device number of the FCP channel connected with the SCSI disk.
  4. As World wide port name, fill in the WWPN of the storage system containing the disk as a 16-digit hexadecimal number.
  5. As Logical unit number, fill in the LUN of the disk as a 16-digit hexadecimal number.
  6. As Boot program selector, fill in the number corresponding the zipl boot menu entry that you prepared for booting the Red Hat Enterprise Linux installation program.
  7. Leave the Boot record logical block address as 0 and the Operating system specific load parameters empty.
  8. Click the OK button.

4.7. Installing under z/VM

Use the x3270 or c3270 terminal emulator, to log in to z/VM from other Linux systems, or use the IBM 3270 terminal emulator on the 64-bit IBM Z Hardware Management Console (HMC). If you are running Microsoft Windows operating system, there are several options available, and can be found through an internet search. A free native Windows port of c3270 called wc3270 also exists.

When installing under z/VM, you can boot from:

  • The z/VM virtual reader
  • A DASD or an FCP-attached SCSI disk prepared with the zipl boot loader

Log on to the z/VM guest virtual machine chosen for the Linux installation.

Note

If your 3270 connection is interrupted and you cannot log in again because the previous session is still active, you can replace the old session with a new one by entering the following command on the z/VM logon screen:

logon user here

Replace user with the name of the z/VM guest virtual machine. Depending on whether an external security manager, for example RACF, is used, the logon command might vary.

If you are not already running CMS (single-user operating system shipped with z/VM) in your guest, boot it now by entering the command:

cp ipl cms

Be sure not to use CMS disks such as your A disk (often device number 0191) as installation targets. To find out which disks are in use by CMS, use the following query:

query disk

You can use the following CP (z/VM Control Program, which is the z/VM hypervisor) query commands to find out about the device configuration of your z/VM guest virtual machine:

  • Query the available main memory, which is called storage in 64-bit IBM Z terminology. Your guest should have at least 1 GiB of main memory.

    cp query virtual storage
  • Query available network devices by type:

    osa
    OSA - CHPID type OSD, real or virtual (VSWITCH or GuestLAN), both in QDIO mode
    hsi
    HiperSockets - CHPID type IQD, real or virtual (GuestLAN type Hipers)
    lcs

    LCS - CHPID type OSE

    For example, to query all of the network device types mentioned above, run:

    cp query virtual osa
  • Query available DASDs. Only those that are flagged RW for read-write mode can be used as installation targets:

    cp query virtual dasd
  • Query available FCP devices (vHBAs):

    cp query virtual fcp

4.7.1. Using the z/VM Reader

Perform the following steps to boot from the z/VM reader:

Procedure

  1. If necessary, add the device containing the z/VM TCP/IP tools to your CMS disk list. For example:

    cp link tcpmaint 592 592
    acc 592 fm

    Replace fm with any FILEMODE letter.

  2. Execute the command:

    ftp host

    Where host is the host name or IP address of the FTP server that hosts the boot images (kernel.img and initrd.img).

  3. Log in and execute the following commands. Use the (repl option if you are overwriting existing kernel.img, initrd.img, generic.prm, or redhat.exec files:

    cd /location/of/install-tree/images/
    ascii
    get generic.prm (repl
    get redhat.exec (repl
    locsite fix 80
    binary
    get kernel.img (repl
    get initrd.img (repl
    quit
  4. Optionally, check whether the files were transferred correctly by using the CMS command filelist to show the received files and their format. It is important that kernel.img and initrd.img have a fixed record length format denoted by F in the Format column and a record length of 80 in the Lrecl column. For example:

    VMUSER FILELIST A0 V 169 Trunc=169 Size=6 Line=1 Col=1 Alt=0
    Cmd Filename	Filetype	Fm	Format	Lrecl	Records	Blocks	Date	Time
    REDHAT	EXEC		B1	V	22	1 	1	4/15/10	9:30:40
    GENERIC	PRM		B1	V	44	1	1	4/15/10	9:30:32
    INITRD	IMG		B1	F	80	118545	2316	4/15/10	9:30:25
    KERNEL	IMG		B1	F	80	74541	912	4/15/10	9:30:17

    Press PF3 to quit filelist and return to the CMS prompt.

  5. Customize boot parameters in generic.prm as necessary. See Customizing boot parameters for details.

    Another way to configure storage and network devices is by using a CMS configuration file. In such a case, add the CMSDASD= and CMSCONFFILE= parameters to generic.prm. See IBM Z/VM configuration file for more details.

  6. Finally, execute the REXX script redhat.exec to boot the installation program:

    redhat

4.7.2. Using a Prepared DASD

Perform the following steps to use a Prepared DASD:

Procedure

  1. Boot from the prepared DASD and select the zipl boot menu entry referring to the Red Hat Enterprise Linux installation program. Use a command of the following form:

    cp ipl DASD_device_number loadparm boot_entry_number

    Replace DASD_device_number with the device number of the boot device, and boot_entry_number with the zipl configuration menu for this device. For example:

    cp ipl eb1c loadparm 0

4.7.3. Using a Prepared FCP attached SCSI Disk

Perform the following steps to boot from a prepared FCP-attached SCSI disk:

Procedure

  1. Configure the SCSI boot loader of z/VM to access the prepared SCSI disk in the FCP Storage Area Network. Select the prepared zipl boot menu entry referring to the Red Hat Enterprise Linux installation program. Use a command of the following form:

    cp set loaddev portname WWPN lun LUN bootprog boot_entry_number

    Replace WWPN with the World Wide Port Name of the storage system and LUN with the Logical Unit Number of the disk. The 16-digit hexadecimal numbers must be split into two pairs of eight digits each. For example:

    cp set loaddev portname 50050763 050b073d lun 40204011 00000000 bootprog 0
  2. Optionally, confirm your settings with the command:

    query loaddev
  3. Boot the FCP device connected with the storage system containing the disk with the following command:

    cp ipl FCP_device

    For example:

    cp ipl fc00

4.7.4. Using parameter and configuration files on 64-bit IBM Z

The 64-bit IBM Z architecture can use a customized parameter file to pass boot parameters to the kernel and the installation program.

You need to change the parameter file if you want to:

  • Install unattended with Kickstart.
  • Choose non-default installation settings that are not accessible through the installation program’s interactive user interface, such as rescue mode.

The parameter file can be used to set up networking non-interactively before the installation program (Anaconda) starts.

The kernel parameter file is limited to 895 characters plus an end-of-line character. The parameter file can be variable or fixed record format. Fixed record format increases the file size by padding each line up to the record length. Should you encounter problems with the installation program not recognizing all specified parameters in LPAR environments, you can try to put all parameters in one single line or start and end each line with a space character.

The parameter file contains kernel parameters, such as ro, and parameters for the installation process, such as vncpassword=test or vnc.

4.8. Installing under KVM

This section describes how to install Red Hat Enterprise Linux 9 in the KVM host.

Prerequisites

Procedure

  • Create virtual machine with the instance of Red Hat Enterprise Linux as a KVM guest operating system, use the following virt-install command on the KVM host:

    $ virt-install --name=<guest_name> --disk size=<disksize_in_GB> --memory=<memory_size_in_MB> --cdrom <filepath_to_iso> --graphics vnc

4.9. Configuring a Linux instance on 64-bit IBM Z

This section describes most of the common tasks for installing Red Hat Enterprise Linux on 64-bit IBM Z.

4.9.1. Adding DASDs

Direct Access Storage Devices (DASDs) are a type of storage commonly used with 64-bit IBM Z. For more information, see Working with DASDs in the IBM Knowledge Center. The following example is how to set a DASD online, format it, and make the change persistent.

Verify that the device is attached or linked to the Linux system if running under z/VM.

CP ATTACH EB1C TO *

To link a mini disk to which you have access, run the following commands:

CP LINK RHEL7X 4B2E 4B2E MR
DASD 4B2E LINKED R/W

4.9.2. Dynamically setting DASDs online

This section contains information about setting a DASD online.

Procedure

  1. Use the cio_ignore utility to remove the DASD from the list of ignored devices and make it visible to Linux:

    # cio_ignore -r device_number

    Replace device_number with the device number of the DASD. For example:

    # cio_ignore -r 4b2e
  2. Set the device online. Use a command of the following form:

    # chccwdev -e device_number

    Replace device_number with the device number of the DASD. For example:

    # chccwdev -e 4b2e

    As an alternative, you can set the device online using sysfs attributes:

    1. Use the cd command to change to the /sys/ directory that represents that volume:

      # cd /sys/bus/ccw/drivers/dasd-eckd/0.0.4b2e/
      # ls -l
      total 0
      -r--r--r--  1 root root 4096 Aug 25 17:04 availability
      -rw-r--r--  1 root root 4096 Aug 25 17:04 cmb_enable
      -r--r--r--  1 root root 4096 Aug 25 17:04 cutype
      -rw-r--r--  1 root root 4096 Aug 25 17:04 detach_state
      -r--r--r--  1 root root 4096 Aug 25 17:04 devtype
      -r--r--r--  1 root root 4096 Aug 25 17:04 discipline
      -rw-r--r--  1 root root 4096 Aug 25 17:04 online
      -rw-r--r--  1 root root 4096 Aug 25 17:04 readonly
      -rw-r--r--  1 root root 4096 Aug 25 17:04 use_diag
    2. Check to see if the device is already online:

      # cat online
      0
    3. If it is not online, enter the following command to bring it online:

      # echo 1 > online
      # cat online
      1
  3. Verify which block devnode it is being accessed as:

    # ls -l
    total 0
    -r--r--r--  1 root root 4096 Aug 25 17:04 availability
    lrwxrwxrwx  1 root root    0 Aug 25 17:07 block -> ../../../../block/dasdb
    -rw-r--r--  1 root root 4096 Aug 25 17:04 cmb_enable
    -r--r--r--  1 root root 4096 Aug 25 17:04 cutype
    -rw-r--r--  1 root root 4096 Aug 25 17:04 detach_state
    -r--r--r--  1 root root 4096 Aug 25 17:04 devtype
    -r--r--r--  1 root root 4096 Aug 25 17:04 discipline
    -rw-r--r--  1 root root    0 Aug 25 17:04 online
    -rw-r--r--  1 root root 4096 Aug 25 17:04 readonly
    -rw-r--r--  1 root root 4096 Aug 25 17:04 use_diag

    As shown in this example, device 4B2E is being accessed as /dev/dasdb.

These instructions set a DASD online for the current session, but this is not persistent across reboots.

For instructions on how to set a DASD online persistently, see Persistently setting DASDs online. When you work with DASDs, use the persistent device symbolic links under /dev/disk/by-path/.

4.9.3. Preparing a new DASD with low-level formatting

Once the disk is online, change back to the /root directory and low-level format the device. This is only required once for a DASD during its entire lifetime:

# cd /root
# dasdfmt -b 4096 -d cdl -p /dev/disk/by-path/ccw-0.0.4b2e
Drive Geometry: 10017 Cylinders * 15 Heads =  150255 Tracks

I am going to format the device /dev/disk/by-path/ccw-0.0.4b2e in the following way:
Device number of device : 0x4b2e
Labelling device        : yes
Disk label              : VOL1
Disk identifier         : 0X4B2E
Extent start (trk no)   : 0
Extent end (trk no)     : 150254
Compatible Disk Layout  : yes
Blocksize               : 4096

--->> ATTENTION! <<---
All data of that device will be lost.
Type "yes" to continue, no will leave the disk untouched: yes
cyl    97 of  3338 |#----------------------------------------------|   2%

When the progress bar reaches the end and the format is complete, dasdfmt prints the following output:

Rereading the partition table...
Exiting...

Now, use fdasd to partition the DASD. You can create up to three partitions on a DASD. In our example here, we create one partition spanning the whole disk:

# fdasd -a /dev/disk/by-path/ccw-0.0.4b2e
reading volume label ..: VOL1
reading vtoc ..........: ok

auto-creating one partition for the whole disk...
writing volume label...
writing VTOC...
rereading partition table...

After a (low-level formatted) DASD is online, it can be used like any other disk under Linux. For instance, you can create file systems, LVM physical volumes, or swap space on its partitions, for example /dev/disk/by-path/ccw-0.0.4b2e-part1. Never use the full DASD device (dev/dasdb) for anything but the commands dasdfmt and fdasd. If you want to use the entire DASD, create one partition spanning the entire drive as in the fdasd example above.

To add additional disks later without breaking existing disk entries in, for example, /etc/fstab, use the persistent device symbolic links under /dev/disk/by-path/.

4.9.4. Persistently setting DASDs online

The above instructions described how to activate DASDs dynamically in a running system. However, such changes are not persistent and do not survive a reboot. Making changes to the DASD configuration persistent in your Linux system depends on whether the DASDs belong to the root file system. Those DASDs required for the root file system need to be activated very early during the boot process by the initramfs to be able to mount the root file system.

The cio_ignore commands are handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually.

4.9.5. DASDs that are part of the root file system

The file you have to modify to add DASDs that are part of the root file system has changed in Red Hat Enterprise Linux 9. Instead of editing the /etc/zipl.conf file, the new file to be edited, and its location, may be found by running the following commands:

# machine_id=$(cat /etc/machine-id)
# kernel_version=$(uname -r)
# ls /boot/loader/entries/$machine_id-$kernel_version.conf

There is one boot option to activate DASDs early in the boot process: rd.dasd=. This option takes a Direct Access Storage Device (DASD) adapter device bus identifier. For multiple DASDs, specify the parameter multiple times, or use a comma separated list of bus IDs. To specify a range of DASDs, specify the first and the last bus ID. Below is an example of the /boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-4.18.0-80.el8.s390x.conf file for a system that uses physical volumes on partitions of two DASDs for an LVM volume group vg_devel1 that contains a logical volume lv_root for the root file system.

title Red Hat Enterprise Linux (4.18.0-80.el8.s390x) 8.0 (Ootpa)
version 4.18.0-80.el8.s390x
linux /boot/vmlinuz-4.18.0-80.el8.s390x
initrd /boot/initramfs-4.18.0-80.el8.s390x.img
options root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.dasd=0.0.0200 rd.dasd=0.0.0207 rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0
id rhel-20181027190514-4.18.0-80.el8.s390x
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

To add another physical volume on a partition of a third DASD with device bus ID 0.0.202b. To do this, add rd.dasd=0.0.202b to the parameters line of your boot kernel in /boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-4.18.0-32.el8.s390x.conf:

title Red Hat Enterprise Linux (4.18.0-80.el8.s390x) 8.0 (Ootpa)
version 4.18.0-80.el8.s390x
linux /boot/vmlinuz-4.18.0-80.el8.s390x
initrd /boot/initramfs-4.18.0-80.el8.s390x.img
options root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.dasd=0.0.0200 rd.dasd=0.0.0207 rd.dasd=0.0.202b rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0
id rhel-20181027190514-4.18.0-80.el8.s390x
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
Warning

Make sure the length of the kernel command line in the configuration file does not exceed 896 bytes. Otherwise, the boot loader cannot be saved, and the installation fails.

Run zipl to apply the changes of the configuration file for the next IPL:

# zipl -V
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-4.18.0-80.el8.s390x.conf'
Target device information
  Device..........................: 5e:00
  Partition.......................: 5e:01
  Device name.....................: dasda
  Device driver name..............: dasd
  DASD device number..............: 0201
  Type............................: disk partition
  Disk layout.....................: ECKD/compatible disk layout
  Geometry - heads................: 15
  Geometry - sectors..............: 12
  Geometry - cylinders............: 13356
  Geometry - start................: 24
  File system block size..........: 4096
  Physical block size.............: 4096
  Device size in physical blocks..: 262152
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '4.18.0-80.el8.s390x' (default)
  initial ramdisk...: /boot/initramfs-4.18.0-80.el8.s390x.img
  kernel image......: /boot/vmlinuz-4.18.0-80.el8.s390x
  kernel parmline...: 'root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.dasd=0.0.0200 rd.dasd=0.0.0207 rd.dasd=0.0.202b rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0'
  component address:
    kernel image....: 0x00010000-0x0049afff
    parmline........: 0x0049b000-0x0049bfff
    initial ramdisk.: 0x004a0000-0x01a26fff
    internal loader.: 0x0000a000-0x0000cfff
Preparing boot menu
  Interactive prompt......: enabled
  Menu timeout............: 5 seconds
  Default configuration...: '4.18.0-80.el8.s390x'
Preparing boot device: dasda (0201).
Syncing disks...
Done.

4.9.6. DASDs that are not part of the root file system

Direct Access Storage Devices (DASDs) that are not part of the root file system, that is, data disks, are persistently configured in the /etc/dasd.conf file. This file contains one DASD per line, where each line begins with the DASD’s bus ID.

When adding a DASD to the /etc/dasd.conf file, use key-value pairs to specify the options for each entry. Separate the key and its value with an equal (=) sign. When adding multiple options, use a space or a tab to separate each option.

Example /etc/dasd.conf file

0.0.0207
0.0.0200 use_diag=1 readonly=1

Changes to the /etc/dasd.conf file take effect after a system reboot or after a new DASD is dynamically added by changing the system’s I/O configuration (that is, the DASD is attached under z/VM).

Alternatively, to activate a DASD that you have added to the /etc/dasd.conf file, complete the following steps:

  1. Remove the DASD from the list of ignored devices and make it visible using the cio_ignore utility:

    # cio_ignore -r device_number

    where device_number is the DASD device number.

    For example, if the device number is 021a, run:

    # cio_ignore -r 021a
  2. Activate the DASD by writing to the device’s uevent attribute:

    # echo add > /sys/bus/ccw/devices/dasd-bus-ID/uevent

    where dasd-bus-ID is the DASD’s bus ID.

    For example, if the bus ID is 0.0.021a, run:

    # echo add > /sys/bus/ccw/devices/0.0.021a/uevent

4.9.7. FCP LUNs that are part of the root file system

The only file you have to modify for adding FCP LUNs that are part of the root file system has changed in Red Hat Enterprise Linux 9. Instead of editing the /etc/zipl.conf file, the new file to be edited, and its location, may be found by running the following commands:

# machine_id=$(cat /etc/machine-id)
# kernel_version=$(uname -r)
# ls /boot/loader/entries/$machine_id-$kernel_version.conf

Red Hat Enterprise Linux provides a parameter to activate FCP LUNs early in the boot process: rd.zfcp=. The value is a comma-separated list containing the FCP device bus ID, the target WWPN as 16 digit hexadecimal number prefixed with 0x, and the FCP LUN prefixed with 0x and padded with zeroes to the right to have 16 hexadecimal digits.

Below is an example of the /boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-5.14.0-55.el9.s390x.conf file for a system that uses a physical volume on a partition of an FCP-attached SCSI disk, with two paths, for an LVM volume group vg_devel1 that contains a logical volume lv_root for the root file system.

title Red Hat Enterprise Linux (5.14.0-55.el9.s390x) 9.0 (Plow)
version 5.14.0-55.el9.s390x
linux /boot/vmlinuz-5.14.0-55.el9.s390x
initrd /boot/initramfs-5.14.0-55.el9.s390x.img
options root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a000000000 rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0
id rhel-20181027190514-5.14.0-55.el9.s390x
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
  1. To add another physical volume on a partition of a second FCP-attached SCSI disk with FCP LUN 0x401040a300000000 using the same two paths as the already existing physical volume, add rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a300000000 and rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a300000000 to the parameters line of your boot kernel in /boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-5.14.0-55.el9.s390x.conf. For example:
title Red Hat Enterprise Linux (5.14.0-55.el9.s390x) 9.0 (Plow)
version 5.14.0-55.el9.s390x
linux /boot/vmlinuz-5.14.0-55.el9.s390x
initrd /boot/initramfs-5.14.0-55.el9.s390x.img
options root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a000000000 rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a300000000 rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a300000000 rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0
id rhel-20181027190514-5.14.0-55.el9.s390x
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
Warning

Make sure the length of the kernel command line in the configuration file does not exceed 896 bytes. Otherwise, the boot loader cannot be saved, and the installation fails.

  • Run dracut -f to update the initial RAM disk of your target kernel.
  • Run zipl to apply the changes of the configuration file for the next IPL:
# zipl -V
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/4ab74e52867b4f998e73e06cf23fd761-5.14.0-55.el9.s390x.conf'
Run /lib/s390-tools/zipl_helper.device-mapper /boot
Target device information
Device..........................: fd:00
Partition.......................: fd:01
Device name.....................: dm-0
Device driver name..............: device-mapper
Type............................: disk partition
Disk layout.....................: SCSI disk layout
Geometry - start................: 2048
File system block size..........: 4096
Physical block size.............: 512
Device size in physical blocks..: 10074112
Building bootmap in '/boot/'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '5.14.0-55.el9.s390x' (default)
kernel image......: /boot/vmlinuz-5.14.0-55.el9.s390x
kernel parmline...: 'root=/dev/mapper/vg_devel1-lv_root crashkernel=auto rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a000000000 rd.zfcp=0.0.fc00,0x5105074308c212e9,0x401040a300000000 rd.zfcp=0.0.fcd0,0x5105074308c2aee9,0x401040a300000000 rd.lvm.lv=vg_devel1/lv_root rd.lvm.lv=vg_devel1/lv_swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0'
initial ramdisk...: /boot/initramfs-5.14.0-55.el9.s390x.img component address:
kernel image....: 0x00010000-0x007a21ff
parmline........: 0x00001000-0x000011ff
initial ramdisk.: 0x02000000-0x028f63ff
internal loader.: 0x0000a000-0x0000a3ff
Preparing boot device: dm-0.
Detected SCSI PCBIOS disk layout.
Writing SCSI master boot record.
Syncing disks...
Done.

4.9.8. FCP LUNs that are not part of the root file system

FCP LUNs that are not part of the root file system, such as data disks, are persistently configured in the file /etc/zfcp.conf. It contains one FCP LUN per line. Each line contains the device bus ID of the FCP adapter, the target WWPN as 16 digit hexadecimal number prefixed with 0x, and the FCP LUN prefixed with 0x and padded with zeroes to the right to have 16 hexadecimal digits, separated by a space or tab.

Entries in /etc/zfcp.conf are activated and configured by udev when an FCP adapter is added to the system. At boot time, all FCP adapters visible to the system are added and trigger udev.

Example content of /etc/zfcp.conf:

0.0.fc00 0x5105074308c212e9 0x401040a000000000
0.0.fc00 0x5105074308c212e9 0x401040a100000000
0.0.fc00 0x5105074308c212e9 0x401040a300000000
0.0.fcd0 0x5105074308c2aee9 0x401040a000000000
0.0.fcd0 0x5105074308c2aee9 0x401040a100000000
0.0.fcd0 0x5105074308c2aee9 0x401040a300000000

Modifications of /etc/zfcp.conf only become effective after a reboot of the system or after the dynamic addition of a new FCP channel by changing the system’s I/O configuration (for example, a channel is attached under z/VM). Alternatively, you can trigger the activation of a new entry in /etc/zfcp.conf for an FCP adapter which was previously not active, by executing the following commands:

  1. Use the zfcp_cio_free utility to remove the FCP adapters from the list of ignored devices and make them visible to Linux:

    # zfcp_cio_free
  2. To apply the additions from /etc/zfcp.conf to the running system, issue:

    # zfcpconf.sh

4.9.9. Adding a qeth device

The qeth network device driver supports 64-bit IBM Z OSA-Express features in QDIO mode, HiperSockets, z/VM guest LAN, and z/VM VSWITCH.

For more information on the qeth device driver naming scheme, see Customizing boot parameters.

4.9.10. Dynamically adding a qeth device

This section contains information on how to add a qeth device dynamically.

Procedure

  1. Determine whether the qeth device driver modules are loaded. The following example shows loaded qeth modules:

    # lsmod | grep qeth
    qeth_l3                69632  0
    qeth_l2                49152  1
    qeth                  131072  2 qeth_l3,qeth_l2
    qdio                   65536  3 qeth,qeth_l3,qeth_l2
    ccwgroup               20480  1 qeth

    If the output of the lsmod command shows that the qeth modules are not loaded, run the modprobe command to load them:

    # modprobe qeth
  2. Use the cio_ignore utility to remove the network channels from the list of ignored devices and make them visible to Linux:

    # cio_ignore -r read_device_bus_id,write_device_bus_id,data_device_bus_id

    Replace read_device_bus_id,write_device_bus_id,data_device_bus_id with the three device bus IDs representing a network device. For example, if the read_device_bus_id is 0.0.f500, the write_device_bus_id is 0.0.f501, and the data_device_bus_id is 0.0.f502:

    # cio_ignore -r 0.0.f500,0.0.f501,0.0.f502
  3. Use the znetconf utility to sense and list candidate configurations for network devices:

    # znetconf -u
    Scanning for network devices...
    Device IDs                 Type    Card Type      CHPID Drv.
    ------------------------------------------------------------
    0.0.f500,0.0.f501,0.0.f502 1731/01 OSA (QDIO)        00 qeth
    0.0.f503,0.0.f504,0.0.f505 1731/01 OSA (QDIO)        01 qeth
    0.0.0400,0.0.0401,0.0.0402 1731/05 HiperSockets      02 qeth
  4. Select the configuration you want to work with and use znetconf to apply the configuration and to bring the configured group device online as network device.

    # znetconf -a f500
    Scanning for network devices...
    Successfully configured device 0.0.f500 (encf500)
  5. Optionally, you can also pass arguments that are configured on the group device before it is set online:

    # znetconf -a f500 -o portname=myname
    Scanning for network devices...
    Successfully configured device 0.0.f500 (encf500)

    Now you can continue to configure the encf500 network interface.

Alternatively, you can use sysfs attributes to set the device online as follows:

  1. Create a qeth group device:

    # echo read_device_bus_id,write_device_bus_id,data_device_bus_id > /sys/bus/ccwgroup/drivers/qeth/group

    For example:

    # echo 0.0.f500,0.0.f501,0.0.f502 > /sys/bus/ccwgroup/drivers/qeth/group
  2. Next, verify that the qeth group device was created properly by looking for the read channel:

    # ls /sys/bus/ccwgroup/drivers/qeth/0.0.f500

    You can optionally set additional parameters and features, depending on the way you are setting up your system and the features you require, such as:

    • portno
    • layer2
    • portname
  3. Bring the device online by writing 1 to the online sysfs attribute:

    # echo 1 > /sys/bus/ccwgroup/drivers/qeth/0.0.f500/online
  4. Then verify the state of the device:

    # cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/online
    											1

    A return value of 1 indicates that the device is online, while a return value 0 indicates that the device is offline.

  5. Find the interface name that was assigned to the device:

    # cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/if_name
    encf500

    Now you can continue to configure the encf500 network interface.

    The following command from the s390utils package shows the most important settings of your qeth device:

    # lsqeth encf500
    Device name                     : encf500
    -------------------------------------------------
    card_type               : OSD_1000
    cdev0                   : 0.0.f500
    cdev1                   : 0.0.f501
    cdev2                   : 0.0.f502
    chpid                   : 76
    online                  : 1
    portname                : OSAPORT
    portno                  : 0
    state                   : UP (LAN ONLINE)
    priority_queueing       : always queue 0
    buffer_count            : 16
    layer2                  : 1
    isolation               : none

4.9.11. Persistently adding a qeth device

To make your new qeth device persistent, you need to create the configuration file for your new interface. The network interface configuration files are placed in the /etc/sysconfig/network-scripts/ directory.

The network configuration files use the naming convention ifcfg-device, where device is the value found in the if_name file in the qeth group device that was created earlier, for example enc9a0. The cio_ignore commands are handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually.

If a configuration file for another device of the same type already exists, the simplest way to add the config file is to copy it to the new name and then edit it:

# cd /etc/sysconfig/network-scripts
# cp ifcfg-enc9a0 ifcfg-enc600

To learn IDs of your network devices, use the lsqeth utility:

# lsqeth -p
devices                    CHPID interface        cardtype       port chksum prio-q'ing rtr4 rtr6 lay'2 cnt
-------------------------- ----- ---------------- -------------- ---- ------ ---------- ---- ---- ----- -----
0.0.09a0/0.0.09a1/0.0.09a2 x00   enc9a0    Virt.NIC QDIO  0    sw     always_q_2 n/a  n/a  1     64
0.0.0600/0.0.0601/0.0.0602 x00   enc600    Virt.NIC QDIO  0    sw     always_q_2 n/a  n/a  1     64

If you do not have a similar device defined, you must create a new file. Use this example of /etc/sysconfig/network-scripts/ifcfg-0.0.09a0 as a template:

# IBM QETH
DEVICE=enc9a0
BOOTPROTO=static
IPADDR=10.12.20.136
NETMASK=255.255.255.0
ONBOOT=yes
NETTYPE=qeth
SUBCHANNELS=0.0.09a0,0.0.09a1,0.0.09a2
PORTNAME=OSAPORT
OPTIONS='layer2=1 portno=0'
MACADDR=02:00:00:23:65:1a
TYPE=Ethernet

Edit the new ifcfg-0.0.0600 file as follows:

  1. Modify the DEVICE statement to reflect the contents of the if_name file from your ccw group.
  2. Modify the IPADDR statement to reflect the IP address of your new interface.
  3. Modify the NETMASK statement as needed.
  4. If the new interface is to be activated at boot time, then make sure ONBOOT is set to yes.
  5. Make sure the SUBCHANNELS statement matches the hardware addresses for your qeth device.
  6. Modify the PORTNAME statement or leave it out if it is not necessary in your environment.
  7. You can add any valid sysfs attribute and its value to the OPTIONS parameter. The Red Hat Enterprise Linux installation program currently uses this to configure the layer mode (layer2) and the relative port number (portno) of qeth devices.

    The qeth device driver default for OSA devices is now layer 2 mode. To continue using old ifcfg definitions that rely on the previous default of layer 3 mode, add layer2=0 to the OPTIONS parameter.

/etc/sysconfig/network-scripts/ifcfg-0.0.0600

# IBM QETH
DEVICE=enc600
BOOTPROTO=static
IPADDR=192.168.70.87
NETMASK=255.255.255.0
ONBOOT=yes
NETTYPE=qeth
SUBCHANNELS=0.0.0600,0.0.0601,0.0.0602
PORTNAME=OSAPORT
OPTIONS='layer2=1 portno=0'
MACADDR=02:00:00:b3:84:ef
TYPE=Ethernet

Changes to an ifcfg file only become effective after rebooting the system or after the dynamic addition of new network device channels by changing the system’s I/O configuration (for example, attaching under z/VM). Alternatively, you can trigger the activation of a ifcfg file for network channels which were previously not active yet, by executing the following commands:

  1. Use the cio_ignore utility to remove the network channels from the list of ignored devices and make them visible to Linux:

    # cio_ignore -r read_device_bus_id,write_device_bus_id,data_device_bus_id

    Replace read_device_bus_id,write_device_bus_id,data_device_bus_id with the three device bus IDs representing a network device. For example, if the read_device_bus_id is 0.0.0600, the write_device_bus_id is 0.0.0601, and the data_device_bus_id is 0.0.0602:

    #  cio_ignore -r 0.0.0600,0.0.0601,0.0.0602
  2. To trigger the uevent that activates the change, issue:

    # echo add > /sys/bus/ccw/devices/read-channel/uevent

    For example:

    # echo add > /sys/bus/ccw/devices/0.0.0600/uevent
  3. Check the status of the network device:

    # lsqeth
  4. Now start the new interface:

    # ifup enc600
  5. Check the status of the interface:

    # ip addr show enc600
    3: enc600:  <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 3c:97:0e:51:38:17 brd ff:ff:ff:ff:ff:ff
    inet 10.85.1.245/24 brd 10.34.3.255 scope global dynamic enc600
    valid_lft 81487sec preferred_lft 81487sec
    inet6 1574:12:5:1185:3e97:eff:fe51:3817/64 scope global noprefixroute dynamic
    valid_lft 2591994sec preferred_lft 604794sec
    inet6 fe45::a455:eff:d078:3847/64 scope link
    valid_lft forever preferred_lft forever
  6. Check the routing for the new interface:

    # ip route
    default via 10.85.1.245 dev enc600  proto static  metric 1024
    12.34.4.95/24 dev enp0s25  proto kernel  scope link  src 12.34.4.201
    12.38.4.128 via 12.38.19.254 dev enp0s25  proto dhcp  metric 1
    192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1
  7. Verify your changes by using the ping utility to ping the gateway or another host on the subnet of the new device:

    # ping -c 1 192.168.70.8
    PING 192.168.70.8 (192.168.70.8) 56(84) bytes of data.
    64 bytes from 192.168.70.8: icmp_seq=0 ttl=63 time=8.07 ms
  8. If the default route information has changed, you must also update /etc/sysconfig/network accordingly.

4.9.12. Configuring an 64-bit IBM Z network device for network root file system

To add a network device that is required to access the root file system, you only have to change the boot options. The boot options can be in a parameter file, however, the /etc/zipl.conf file no longer contains specifications of the boot records. The file that needs to be modified can be located using the following commands:

# machine_id=$(cat /etc/machine-id)
# kernel_version=$(uname -r)
# ls /boot/loader/entries/$machine_id-$kernel_version.conf

Dracut, the mkinitrd successor that provides the functionality in the initramfs that in turn replaces initrd, provides a boot parameter to activate network devices on 64-bit IBM Z early in the boot process: rd.znet=.

As input, this parameter takes a comma-separated list of the NETTYPE (qeth, lcs, ctc), two (lcs, ctc) or three (qeth) device bus IDs, and optional additional parameters consisting of key-value pairs corresponding to network device sysfs attributes. This parameter configures and activates the 64-bit IBM Z network hardware. The configuration of IP addresses and other network specifics works the same as for other platforms. See the dracut documentation for more details.

The cio_ignore commands for the network channels are handled transparently on boot.

Example boot options for a root file system accessed over the network through NFS:

root=10.16.105.196:/nfs/nfs_root cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=OSAPORT ip=10.16.105.197:10.16.105.196:10.16.111.254:255.255.248.0:nfs‑server.subdomain.domain:enc9a0:none rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us

4.10. Booting a system with UEFI Secure Boot

To enhance the security of your operating system, use the UEFI Secure Boot feature for signature verification when booting a Red Hat Enterprise Linux release on systems having UEFI Secure Boot enabled.

4.10.1. UEFI Secure Boot and RHEL releases

UEFI Secure Boot requires that the operating system kernel is signed with a recognized private key. UEFI Secure Boot then verifies the signature using the corresponding public key.

A custom key can be added to the system using the Machine Owner Key (MOK) facility.

4.10.2. Adding a custom public key for UEFI Secure Boot

This section contains information about how to add an existing custom public key for UEFI Secure Boot.

Prerequisites

  • UEFI Secure Boot is disabled on the system.
  • You are logged in to the system, and the tasks in the Initial Setup window are complete.

Procedure

  1. Generate a public key and store it on a local drive. For example, my_signing_key_pub.der.
  2. Enroll the Red Hat custom public key in the system’s Machine Owner Key (MOK) list:

    # mokutil --import my_signing_key_pub.der
  3. Enter a password when prompted.
  4. Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
  5. Select Enroll MOK.
  6. Select Continue.
  7. Select Yes and enter the password.

    The key is imported into the system’s firmware.

  8. Select Reboot.
  9. Enable Secure Boot on the system.

4.10.3. Removing a custom public key

The procedure describes how to remove a custom public key.

Procedure

  1. Remove the Red Hat custom public key from the system’s Machine Owner Key (MOK) list:

    # mokutil --reset
  2. Enter a password when prompted.
  3. Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
  4. Select Reset MOK.
  5. Select Continue.
  6. Select Yes and enter the password that you had specified in step 2. The key is removed from the system’s firmware.
  7. Select Reboot.