Chapter 5. Installing Red Hat Enterprise Linux on 64-bit IBM Z
You can install Red Hat Enterprise Linux on the 64-bit IBM Z architecture.
5.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. When using FCP devices, Red Hat recommends using them in multipath configuration for better reliability.
DASDs are 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.
-
When initializing swap space on a Fixed Block Architecture (FBA) DASD using the SWAPGEN utility, the
FBAPART
option must be used.
Additional resources
- For additional information about 64-bit IBM Z, see https://www.ibm.com/it-infrastructure/z.
- For additional information about using secure boot with Linux on IBM Z, see Secure boot for Linux on IBM Z.
5.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:
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
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)
- Completing the installation using the RHEL installation program
5.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.
5.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.
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 by using only local media such as a disk, 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 delimitedsysfs
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
NoteWhen specifying multiple
rd.znet
boot options, only the last one is passed on to the kernel command line of the installed system. This does not affect the networking of the system since all network devices configured during installation are properly activated and configured at boot.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 beenca00
for a device with the bus ID0.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.For 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. Since 9, a target world wide port name (WWPN) and an FCP LUN have to be provided only if thezFCP
device is not configured in NPIV mode or whenauto LUN
scanning is disabled by thezfcp.allow_lun_scan=0
kernel module parameter. It provides access to all SCSI devices found in the storage area network attached to the FCP device with the specified bus ID. This parameter needs to be specified at least twice to activate multiple paths to the same disks.rd.zfcp=0.0.4000,0x5005076300C213e9,0x5022000000000000 rd.zfcp=0.0.4000
- 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, theinst.cmdline
option is also useful.
An example customized generic.prm
file containing all mandatory parameters look similar to the following example:
Example 5.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 5.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
5.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.
5.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.
5.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 asredhat.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
5.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
, orctc
. The default isqeth
.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) orPORTNO="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
or1
.Use
LAYER2="0"
to operate an OSA or HiperSockets device in layer 3 mode (NETTYPE="qeth"
). UseLAYER2="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
or1
.Specify
VSWITCH="1"
when connecting to a z/VM VSWITCH or GuestLAN, orVSWITCH="0"
(or nothing at all) when using directly attached real OSA or directly attached real HiperSockets.MACADDR="MAC_address"
If you specify
LAYER2="1"
andVSWITCH="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"
andVSWITCH="1"
, you must not specify theMACADDR
, because z/VM assigns a unique MAC address to virtual network devices in layer 2 mode.CTCPROT="value"
Where value can be
0
,1
, or3
.Specifies the CTC protocol for
NETTYPE="ctc"
. The default is0
.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 of255.255.255.0
, or20
instead of255.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 theDNS=
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
, andfailfast
. 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 asprobeonly
,nopav
, ornofcx
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)"
FCP_n="device_bus_ID [WWPN FCP_LUN]"
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
orFCP_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
).
-
n is typically an integer value (for example
A target world wide port name (WWPN) and an FCP_LUN have to be provided if the zFCP
device is not configured in NPIV mode, when auto LUN scanning is disabled by the zfcp.allow_lun_scan=0
kernel module parameter or when installing RHEL-9.0 or older releases. Otherwise only the device_bus_ID
value is mandatory.
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" FCP_2="0.0.4000"
ImportantEach of the values used in the FCP parameters (for example
FCP_1
orFCP_2
) are site-specific and are normally supplied by the FCP storage administrator.
5.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.
5.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 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 theinstall.img
directly. Otherwise, follows the same syntax asinst.repo=
. Ifinst.stage2
is specified, it typically takes precedence over other methods of findinginstall.img
. However, if Anaconda findsinstall.img
on local media, theinst.stage2
URL will be ignored.If
inst.stage2
is not specified andinstall.img
cannot be found locally, Anaconda looks to the location given byinst.repo=
ormethod=
.If only
inst.stage2=
is given withoutinst.repo=
ormethod=
, 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.
5.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
-
See section Customizing Boot Parameters, for example of the
Customized generic.prm
file.
5.6. Installing in an LPAR
5.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.
- 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.
- 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.
- 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.
5.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.
On the command prompt, run the following command:
$ssh install@_my-z-system-domain-name_
or
$ssh install@_my-z-system-IP-address_
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.- Enter 1 to start VNC.
-
Enter a password, if you have not set the
inst.vncpassword=
boot option, but want to secure the server connection. 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.
5.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
- Double-click Load from Removable Media or Server.
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/.
- Click Continue.
- In the dialog that follows, keep the default selection of generic.ins and click Continue.
5.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
- Double-click Load.
- In the dialog box that follows, select Normal as the Load type.
- As Load address, fill in the device number of the DASD.
- 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.
- Click the OK button.
5.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
- Double-click Load.
- In the dialog box that follows, select SCSI as the Load type.
- As Load address, fill in the device number of the FCP channel connected with the SCSI disk.
- As World wide port name, fill in the WWPN of the storage system containing the disk as a 16-digit hexadecimal number.
- As Logical unit number, fill in the LUN of the disk as a 16-digit hexadecimal number.
- 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.
- Leave the Boot record logical block address as 0 and the Operating system specific load parameters empty.
- Click the OK button.
5.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.
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
5.7.1. Using the z/VM Reader
Perform the following steps to boot from the z/VM reader:
Procedure
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.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
andinitrd.img
).Log in and execute the following commands. Use the
(repl
option if you are overwriting existingkernel.img
,initrd.img
,generic.prm
, orredhat.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
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 thatkernel.img
andinitrd.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.
Customize boot parameters in
generic.prm
as necessary. For details, see Customizing boot parameters.Another way to configure storage and network devices is by using a CMS configuration file. In such a case, add the
CMSDASD=
andCMSCONFFILE=
parameters togeneric.prm
. See IBM Z/VM configuration file for more details.Finally, execute the REXX script redhat.exec to boot the installation program:
redhat
5.7.2. Using a Prepared DASD
Perform the following steps to use a Prepared DASD:
Procedure
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
5.7.3. Using a Prepared FCP attached SCSI Disk
Perform the following steps to boot from a prepared FCP-attached SCSI disk:
Procedure
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:
query loaddev
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
5.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
.
5.8. Installing under KVM
This section describes how to install Red Hat Enterprise Linux 9 in the KVM host.
Prerequisites
- Set up the Red Hat Enterprise Linux in LPAR mode as a KVM host. For more details, see the Installing in an LPAR section.
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
Additional resources
- KVM on 64-bit IBM Z
-
The
virt-install
man page - Creating virtual machines by using the command-line interface
5.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.
5.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
5.9.2. Dynamically setting DASDs online
This section contains information about setting a DASD online.
Procedure
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
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:
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_diagCheck to see if the device is already online:
#
cat online 0If it is not online, enter the following command to bring it online:
#
echo 1 > online#
cat online 1
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_diagAs 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/
.
5.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 example, 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/
.
5.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.
5.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
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.
5.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:
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
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
5.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.
The WWPN and FCP LUN values are only necessary if the zFCP
device is not configured in NPIV mode, when auto LUN scanning is disabled by the zfcp.allow_lun_scan=0
kernel module parameter or when installing RHEL-9.0 or older releases. Otherwise they can be omitted, for example, rd.zfcp=0.0.4000
. 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
-
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, addrd.zfcp=0.0.fc00,0x5105074308c212e9
,0x401040a300000000
andrd.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
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.
5.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.
The WWPN and FCP LUN values are only necessary if the zFCP
device is not configured in NPIV mode, when auto LUN
scanning is disabled by the zfcp.allow_lun_scan=0
kernel module parameter or when installing RHEL-9.0 or older releases. Otherwise they can be omitted and only the device bus ID is mandatory.
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 0.0.4000 0.0.5000
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:
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
To apply the additions from
/etc/zfcp.conf
to the running system, issue:# zfcpconf.sh
5.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 about the qeth device driver naming scheme, see Customizing boot parameters
5.9.10. Dynamically adding a qeth device
This section contains information about how to add a qeth
device dynamically.
Procedure
Determine whether the
qeth
device driver modules are loaded. The following example shows loadedqeth
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 qethIf the output of the
lsmod
command shows that theqeth
modules are not loaded, run themodprobe
command to load them:#
modprobe qethUse 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_idReplace 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 is0.0.f501
, and the data_device_bus_id is0.0.f502
:#
cio_ignore -r 0.0.f500,0.0.f501,0.0.f502Use 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 qethSelect 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)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:
Create a
qeth
group device:#
echo read_device_bus_id,write_device_bus_id,data_device_bus_id > /sys/bus/ccwgroup/drivers/qeth/groupFor example:
#
echo 0.0.f500,0.0.f501,0.0.f502 > /sys/bus/ccwgroup/drivers/qeth/groupNext, verify that the
qeth
group device was created properly by looking for the read channel:#
ls /sys/bus/ccwgroup/drivers/qeth/0.0.f500You 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
-
Bring the device online by writing
1
to the onlinesysfs
attribute:#
echo 1 > /sys/bus/ccwgroup/drivers/qeth/0.0.f500/onlineThen verify the state of the device:
#
cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/online 1A return value of
1
indicates that the device is online, while a return value0
indicates that the device is offline.Find the interface name that was assigned to the device:
#
cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/if_name encf500Now 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
5.9.11. Persistently adding a qeth device
To make a new qeth
device persistent, create a configuration file for the new interface. The network interface configuration files are placed in the /etc/NetworkManager/system-connections/
directory.
The network configuration files use the naming convention device.nmconnection, where device is the value found in the interface-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, copy it to the new name and edit it:
# cd /etc/NetworkManager/system-connections/ # cp enc9a0.nmconnection enc600.nmconnection
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, create a new file. Use this example:
[connection] type=ethernet interface-name=enc600 [ipv4] address1=10.12.20.136/24,10.12.20.1 dns=10.12.20.53; method=manual [ethernet] mac-address=00:53:00:8f:fa:66
Edit the new enc600.nmconnection file as follows:
Ensure the new connection file is owned by
root:root
:# chown root:root /etc/NetworkManager/system-connections/enc600.nmconnection
- Add more details in this file or modify these parameters based on your connection requirements.
- Save the file.
Reload the connection profile:
# nmcli connection reload
To view complete details of the connection newly added, enter:
# nmcli connection show enc600
Changes to the enc600.nmconnection file become effective after either rebooting the system, dynamic addition of new network device channels by changing the system’s I/O configuration (for example, attaching under z/VM), or reloading network connections. Alternatively, you can trigger the activation of enc600.nmconnection for network channels, which were previously not active yet, by executing the following commands:
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 is0.0.0601
, and the data_device_bus_id is0.0.0602
:# cio_ignore -r 0.0.0600,0.0.0601,0.0.0602
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
Check the status of the network device:
# lsqeth
If the default route information has changed, you must also update the ipaddress1 parameters in both the
[ipv4]
and[ipv6]
sections of the/etc/NetworkManager/system-connections/<profile_name>.nmconnection
file accordingly:[ipv4] address1=10.12.20.136/24,10.12.20.1 [ipv6] address1=2001:db8:1::1,2001:db8:1::fffe
Now start the new interface:
# nmcli connection up enc600
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 10.12.20.136/24 brd 10.12.20.1 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
Check the routing for the new interface:
# ip route default via 10.12.20.136 dev enc600 proto dhcp src
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 10.12.20.136 PING 10.12.20.136 (10.12.20.136) 56(84) bytes of data. 64 bytes from 10.12.20.136: icmp_seq=0 ttl=63 time=8.07 ms
-
If the default route information has changed, you must also update
/etc/sysconfig/network
accordingly.
Additional resources
-
The
nm-settings-keyfile
man page
5.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
5.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.
5.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.
5.10.2. Adding a custom public key for UEFI Secure Boot
You can add an existing custom public key for UEFI Secure Boot.
Prerequisites
- You have disabled UEFI Secure Boot on the system.
- You are logged in to the system and have completed the tasks in the Initial Setup window.
Procedure
- Generate a public key and store it on a local drive. For example, my_signing_key_pub.der.
Enroll the Red Hat custom public key in the system’s Machine Owner Key (MOK) list:
# mokutil --import my_signing_key_pub.der
- Enter a password when prompted.
- Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
- Select Enroll MOK.
- Select Continue.
Select Yes and enter the password.
The key is imported into the system’s firmware.
- Select Reboot.
- Enable Secure Boot on the system.
Additional resources
5.10.3. Removing a custom public key
The procedure describes how to remove a custom public key.
Procedure
Remove the Red Hat custom public key from the system’s Machine Owner Key (MOK) list:
#
mokutil --reset- Enter a password when prompted.
- Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
-
Select
Reset MOK
. -
Select
Continue
. -
Select
Yes
and enter the password that you had specified in step 2. The key is removed from the system’s firmware. -
Select
Reboot
.