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:

  1. Booting the installation

    • Connect to the mainframe
    • Perform an initial program load (IPL), or boot from the media containing the installation program

  2. Starting the installation

    • Connect to the system using SSH, and start the installation program using Virtual Network Computing (VNC)

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

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

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

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.

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

10.4.1. Pre-installation

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.

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

Disk space

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.

RAM

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

When initializing swap space on a Fixed Block Architecture (FBA) DASD using the SWAPGEN utility, the FBAPART option must be used.

Additional resources

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

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

    cp query virtual fcp

10.6. 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 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 CMSDASD= and CMSCONFFILE= parameters to generic.prm. See Section 10.12, “IBM Z/VM configuration file” for more details.

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

    redhat

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

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

10.9. Using an FCP-attached SCSI DVD Drive

Perform the following steps to use a Prepared FCP attached SCSI DVD Drive:

Prerequistes

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

Procedure

  1. Insert your Red Hat Enterprise Linux for IBM Z DVD into the DVD drive.

  2. Configure the SCSI boot loader of z/VM to access the DVD drive in the FCP Storage Area Network and specify 1 for 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

  3. Optionally, confirm your settings with the command: 

    cp query loaddev

  4. IPL on the FCP device connected with the FCP-to-SCSI bridge. 

    cp ipl FCP_device

    For example: 

    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 vncpassword=test or vnc.

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.

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

Important

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

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.

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.

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.

inst.ks=URL
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.
inst.cmdline
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.

rd.live.check
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.
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 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 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"