Chapter 10. Preparing for installation on IBM Z
10.1. Overview of the IBM Z installation process
You can install Red Hat Enterprise Linux on IBM Z interactively or in unattended mode. Installation on 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:
Booting the installation
- Connect to the mainframe
- Perform an initial program load (IPL), or boot from the media containing the installation program
Starting the installation
- Connect to the system using SSH, and start the installation program using Virtual Network Computing (VNC)
Completing the installation
Use the Anaconda installation program to:
- Configure the network
- Specify language support
- Specify installation source
- Specify software packages to be installed
- Complete the installation
10.2. 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.
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.
ip=option for basic network configuration, and other options listed in 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
sysfsparameter and value pairs. This parameter can be specified multiple times to activate multiple network devices.
- Storage devices
At least one storage device must always be configured for text mode installations.
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.zfcp=option takes a SCSI over FCP (zFCP) adapter device bus identifier, a world wide port name (WWPN), and a FCP LUN, then activates the device. This parameter can be specified multiple times to activate multiple zFCP devices. Example:
- 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.cmdlineoption is also useful.
An example customized
generic.prm file containing all mandatory parameters look similar to the following example:
Example 10.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 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 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 10.2. Sample generic.ins file
images/kernel.img 0x00000000 images/initrd.img 0x02000000 images/genericdvd.prm 0x00010480 images/initrd.addrsize 0x00010408
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.
10.3. Booting the installation
10.3.1. Booting the installation
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 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
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 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:
- SCSI device that is attached through an FCP channel
- FCP-attached SCSI DVD
If you use DASD and FCP-attached SCSI devices (except SCSI DVDs) as boot media, you must have a configured
zipl boot loader.
10.4. Planning for installation on IBM Z
Red Hat Enterprise Linux 8 runs on z13 or later IBM mainframe systems.
The installation process assumes that you are familiar with the IBM Z and can set up logical partitions (LPARs) and z/VM guest virtual machines.
For installation of Red Hat Enterprise Linux on IBM Z, Red Hat supports Direct Access Storage Device (DASD) and Fiber Channel Protocol (FCP) storage devices.
DASDs are hard disks that allow a maximum of three partitions per device. For example,
dasda can have partitions
- Whether the operating system is to be run on an LPAR 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 8 for 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
You will need to calculate and allocate sufficient disk space on DASDs or SCSI disks.
- A minimum of 10 GB is needed for a server installation, 20 GB 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.
You will have to ensure enough RAM is available.
- 1 GB is recommended for the Linux instance. With some tuning, an instance might run with as little as 512 MB RAM.
- If installing from NFS, 1 GB is sufficient. However, if installing from an HTTP or FTP source, 1.5 GB is needed.
- Running at 512 MB in text mode can be done only when installing from NFS.
When initializing swap space on a Fixed Block Architecture (FBA) DASD using the SWAPGEN utility, the
FBAPART option must be used.
- For additional information on IBM Z, see http://www.ibm.com/systems/z.
10.5. 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 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 device prepared with the zipl boot loader
An FCP-attached SCSI DVD drive
- Log on to the z/VM guest virtual machine chosen for the Linux installation.
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:
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 IBM Z terminology. Your guest should have at least 1 GB of main memory.
cp query virtual storage
Query available network devices by type:
- OSA - CHPID type OSD, real or virtual (VSWITCH or GuestLAN), both in QDIO mode
- HiperSockets - CHPID type IQD, real or virtual (GuestLAN type Hipers)
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
RWfor read-write mode can be used as installation targets:
cp query virtual dasd
Query available FCP channels:
cp query virtual fcp
10.6. Using the z/VM Reader
Perform the following steps to boot from the z/VM reader:
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
Execute the command:
hostis the host name or IP address of the FTP server that hosts the boot images (
Log in and execute the following commands. Use the
(reploption if you are overwriting existing
get generic.prm (repl
get redhat.exec (repl
locsite fix 80
get kernel.img (repl
get initrd.img (repl
Optionally, check whether the files were transferred correctly by using the CMS command
filelistto show the received files and their format. It is important that
initrd.imghave 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.
Customize boot parameters in
generic.prmas necessary. See Section 10.2, “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
generic.prm. See Section 10.12, “IBM Z/VM configuration file” for more details.
Finally, execute the REXX script redhat.exec to boot the installation program:
10.7. Using a Prepared DASD
Perform the following steps to use a Prepared DASD:
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
10.8. Using a Prepared FCP attached SCSI Disk
Perform the following steps to boot from a prepared FCP-attached SCSI disk:
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
Optionally, confirm your settings with the command:
Boot the FCP device connected with the storage system containing the disk with the following command:
cp ipl FCP_device
cp ipl fc00
10.9. Using an FCP-attached SCSI DVD Drive
Perform the following steps to use a Prepared FCP attached SCSI DVD Drive:
- This requires a SCSI DVD drive attached to an FCP-to-SCSI bridge which is in turn connected to an FCP adapter in your IBM Z. The FCP adapter must be configured and available under z/VM.
- Insert your Red Hat Enterprise Linux for IBM Z DVD into the DVD drive.
Configure the SCSI boot loader of z/VM to access the DVD drive in the FCP Storage Area Network and specify
1for the boot entry on the Red Hat Enterprise Linux for IBM Z DVD. Use a command of the following form:
cp set loaddev portname WWPN lun FCP_LUN bootprog 1
Replace WWPN with the WWPN of the FCP-to-SCSI bridge and FCP_LUN with the LUN of the DVD drive. The 16-digit hexadecimal numbers must be split into two pairs of eight characters each. For example:
cp set loaddev portname 20010060 eb1c0103 lun 00010000 00000000 bootprog 1
Optionally, confirm your settings with the command:
cp query loaddev
IPL on the FCP device connected with the FCP-to-SCSI bridge.
cp ipl FCP_device
cp ipl fc00
10.10. Using parameter and configuration files on IBM Z
The 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
10.11. Required configuration file parameters on 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.
Mounts the root file system, which is a RAM disk, read-only.
Modifies the memory size reserved for the RAM disk to ensure that the Red Hat Enterprise Linux installation program fits within it. For example:
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.
To avoid installation problems arising from
cio_ignore support not being implemented throughout the entire stack, adapt the
cio_ignore= parameter value to your system or remove the parameter entirely from your parameter file used for booting (IPL) the installation program.
10.12. 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:
You must also add the
CMSCONFFILE parameters to the parameter file. These parameters point the installation program to the configuration file:
Where cmsdasd_address is the device number of a CMS-formatted disk that contains the configuration file. This is usually the CMS user’s
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:
The CMS file
REDHAT CONFis 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.
10.13. Installation network parameters on 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.
Where type must be one of the following:
ctc. The default is
- OSA-Express features
- OSA-Express features
- Virtual connections on z/VM, including VSWTICH and Guest LAN
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):
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.
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.
Where value can be
LAYER2="0"to operate an OSA or HiperSockets device in layer 3 mode (
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
Where value can be
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.
If you specify
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
VSWITCH="1", you must not specify the
MACADDR, because z/VM assigns a unique MAC address to virtual network devices in layer 2 mode.
Where value can be
Specifies the CTC protocol for
NETTYPE="ctc". The default is
- Where string is the host name of the newly-installed Linux instance.
- Where IP is the IP address of the new Linux instance.
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
- Where gw is the gateway IP address for this network device.
- Where mtu is the Maximum Transmission Unit (MTU) for this network device.
Where "server1:server2:additional_server_terms:serverN" is a list of DNS servers, separated by colons. For example:
Where "domain1:domain2:additional_dns_terms:domainN" is a list of the search domains, separated by colons. For example:
You only need to specify
SEARCHDNS=if you specify the
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
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/nameto enable transparent addition of disks later. Other global options such as
nofcxare 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
/bootpartition after installation.
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"
n is typically an integer value (for example
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.fc00for 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
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
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_2) are site-specific and are normally supplied by the FCP storage administrator.
- n is typically an integer value (for example
The installation program prompts you for any required parameters not specified in the parameter or configuration file except for FCP_n.
10.14. Parameters for kickstart installations on IBM Z
The following parameters can be defined in a parameter file but do not work in a CMS configuration file.
- References a Kickstart file, which usually resides on the network for Linux installations on IBM Z. Replace URL with the full path including the file name of the Kickstart file. This parameter activates automatic installation with Kickstart.
- When this option is specified, output on line-mode terminals (such as 3270 under z/VM or operating system messages for LPAR) becomes readable, as the installation program disables escape terminal sequences that are only applicable to UNIX-like consoles. 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.
10.15. Miscellaneous parameters on IBM Z
The following parameters can be defined in a parameter file but do not work in a CMS configuration file.
Turns on testing of an ISO-based installation source; for example, when booted from an FCP-attached DVD or using
inst.repo=with an ISO on local hard disk or mounted with NFS.
- Disables support for multipath devices.
- Specify a proxy to use with installation over HTTP, HTTPS or FTP.
- Boot into a rescue system running from a RAM disk that can be used to fix and restore an installed system.
Specifies a path to a tree containing
install.img, not to the
install.imgdirectly. Otherwise, follows the same syntax as
inst.stage2is specified, it typically takes precedence over other methods of finding
install.img. However, if Anaconda finds
install.imgon local media, the
inst.stage2URL will be ignored.
inst.stage2is not specified and
install.imgcannot be found locally, Anaconda looks to the location given by
inst.stage2=is given without
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/
- Sends log messages to a remote syslog server.
The boot parameters described here are the most useful for installations and trouble shooting on IBM Z, but only a subset of those that influence the installation program.
10.16. Sample parameter file and CMS configuration file on IBM Z
To change the parameter file, begin by extending the shipped
ro ramdisk_size=40000 cio_ignore=all,!condev CMSDASD="191" CMSCONFFILE="redhat.conf" inst.vnc inst.repo=http://example.com/path/to/dvd-contents
redhat.conf file configuring a QETH network device (pointed to by
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"