Linux For S390 Installation

LINUX for S/390 - kernel patch IBM
LINUX® for S/390®

Installation, Configuration and Use
LINUX for S/390 - kernel patch IBM
LINUX® for S/390®

Installation, Configuration and Use
Sixth Edition (May 2000)
This edition applies to the third release of the LINUX for S/390 kernel 2.2.15 patch (made in May 2000) and to all
subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 1999. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this book . . . . . . . . . . . vii Chapter 4. Installation - native single
How this book is organized . . . . . . . . . vii image and LPAR - OS/390 . . . . . . 21
Who should read this book . . . . . . . . . vii Preparing for installation . . . . . . . . . . 22
Assumptions . . . . . . . . . . . . . viii Choosing the installation method . . . . . . 22
Obtaining information about your network
Summary of changes . . . . . . . . . ix environment . . . . . . . . . . . . . 22
Edition 6 changes . . . . . . . . . . . . ix Obtaining information about the IPL method . . 22
Edition 5 changes . . . . . . . . . . . . ix Gaining access to OS/390. . . . . . . . . 23
Edition 4 changes. . . . . . . . . . . . . x Creating the tape - overview . . . . . . . . 23
Edition 3 changes. . . . . . . . . . . . . x Locating the LINUX for S/390 files . . . . . . 23
Edition 2 changes . . . . . . . . . . . . xi Getting the image of the kernel . . . . . . . 23
Getting the image of the root file system for
initial IPL . . . . . . . . . . . . . . 24
Part 1. Overview and planning . . . . 1 Building the tape using OS/390 . . . . . . . 24
Building a parameter line file on OS/390 . . . 24
Chapter 1. LINUX for S/390 information Building an IPL-able tape. . . . . . . . . 25
roadmap . . . . . . . . . . . . . . 3 Preparing your root file system for initial IPL . . . 26
IPL-ing from tape . . . . . . . . . . . . 27
Chapter 2. Overview to LINUX for S/390 5 Logging into your system and testing it . . . . 27
S/390 introduction . . . . . . . . . . . . 5 Formatting the DASDs . . . . . . . . . . 28
S/390 machine types . . . . . . . . . . 5 Preparing to transfer your root file system . . . . 29
VM . . . . . . . . . . . . . . . . 5 Populating the new root file system on DASD . . . 29
Console . . . . . . . . . . . . . . . 5 Creating a swap file or device . . . . . . . . 29
Hard disks . . . . . . . . . . . . . . 5 Using a complete volume as swap space . . . 29
Expanded storage. . . . . . . . . . . . 6 Using a file as swap space . . . . . . . . 30
Network . . . . . . . . . . . . . . . 6 Activating the swap space . . . . . . . . 30
S/390 devices currently not supported. . . . . 6 Customizing the configuration files of the new file
S/390 terminology . . . . . . . . . . . . 7 system . . . . . . . . . . . . . . . . 30
OS concepts . . . . . . . . . . . . . 7 Getting a new kernel appropriate to your needs . . 31
Hardware support components . . . . . . . 7 Preparing for IPL from DASD . . . . . . . . 31
S/390 devices . . . . . . . . . . . . . 7 IPL-ing from DASD . . . . . . . . . . . 32
Tools and utilities. . . . . . . . . . . . 8 Hints, Tips, and Troubleshooting: . . . . . . . 32
LINUX terminology . . . . . . . . . . . . 8 What are the corresponding device names to my
OS concepts . . . . . . . . . . . . . 8 DASD devnos? . . . . . . . . . . . . 32
Devices . . . . . . . . . . . . . . . 9 Some devices are not detected by LINUX for
File system . . . . . . . . . . . . . . 9 S/390 . . . . . . . . . . . . . . . 33
Network . . . . . . . . . . . . . . . 9 The hardware console ″hangs″ . . . . . . . 33
Tools and utilities . . . . . . . . . . . 10 No messages on system console during IPL . . 33
Configuration files . . . . . . . . . . . 10
Chapter 5. Installation - native single
Chapter 3. Planning your installation 13 image and LPAR - VM/ESA . . . . . . 35
Choosing the LINUX for S/390 run-time Preparing for installation . . . . . . . . . . 36
environment . . . . . . . . . . . . . . 13 Choosing the installation method . . . . . . 36
Running LINUX for S/390 in a shared environment 13 Obtaining information about your network
Overview of the installation steps . . . . . . . 14 environment . . . . . . . . . . . . . 36
Running LINUX for S/390 . . . . . . . . 14 Obtaining information about the IPL method . . 37
Establishing the requirements of LINUX for Gaining access to VM/ESA . . . . . . . . 37
S/390 . . . . . . . . . . . . . . . 15 Creating the tape - overview . . . . . . . . 37
Prerequisites for installation . . . . . . . . 15 Locating the LINUX for S/390 files . . . . . . 37
Further information . . . . . . . . . . . 17 Getting the image of the kernel . . . . . . . 37
Getting the image of the root file system for
initial IPL . . . . . . . . . . . . . . 38
Part 2. Installation . . . . . . . . . 19 Building the tape using VM/ESA . . . . . . . 38
Building a parameter line using VM/ESA . . . 38
Building an IPL-able tape. . . . . . . . . 39
© Copyright IBM Corp. 1999 iii

Preparing your root file system for initial IPL . . . 41 No messages on system console during IPL . . 61
IPL-ing from tape . . . . . . . . . . . . 41
Logging into your system and testing it . . . . 42 Chapter 7. Installation using VM - IPL
Formatting the DASDs . . . . . . . . . . 42 from the VM reader . . . . . . . . . 63
Preparing to transfer your root file system . . . . 43
Creating the VM guest user ID . . . . . . . . 64
Populating the new root file system on DASD . . . 43
Minidisks . . . . . . . . . . . . . . 64
Creating a swap file or device . . . . . . . . 43
Network connection . . . . . . . . . . 65
Using a complete volume as swap space . . . 44
User directory . . . . . . . . . . . . 65
Using a file as swap space . . . . . . . . 44
Checking the CMSUSER profile . . . . . . . 65
Activating the swap space . . . . . . . . 44
Assigning an IP address to the VM guest user ID. . 66
Customizing the configuration files of the new file
Preparing the VM guest user profile . . . . . . 66
system . . . . . . . . . . . . . . . . 45
Preparing minidisk B as a LINUX root file system 67
Getting a new kernel appropriate to your needs . . 45
Transferring the LINUX boot files to minidisk A . . 67
Preparing for IPL from DASD . . . . . . . . 45
Creating additional files . . . . . . . . . 68
IPL-ing from DASD . . . . . . . . . . . 46
Files stored on minidisk A . . . . . . . . 68
Hints, Tips, and Troubleshooting: . . . . . . . 47
Booting with LIN EXEC . . . . . . . . . . 70
What are the corresponding device names to my
Preparing the file system on your reserved minidisk 70
DASD devnos? . . . . . . . . . . . . 47
Creating a swap space . . . . . . . . . . . 71
Some devices are not detected by LINUX for
Activation of the swap space . . . . . . . 72
S/390 . . . . . . . . . . . . . . . 47
Editing the ’/mnt/etc/fstab’ file . . . . . . . 72
The hardware console ″hangs″ . . . . . . . 47
Finishing off . . . . . . . . . . . . . . 72
No messages on system console during IPL . . 47
Re-booting with LIPL EXEC . . . . . . . . . 72
Emulating ’Ctrl’ character combinations . . . . . 73
Chapter 6. Installation - native single Starting and stopping the system . . . . . . . 73
image and LPAR - VSE/ESA. . . . . . 49 Remembering your password . . . . . . . . 73
Preparing for installation . . . . . . . . . . 50
Choosing the installation method . . . . . . 50 Chapter 8. Installation using VM - IPL
Obtaining information about your network from tape . . . . . . . . . . . . . 75
environment . . . . . . . . . . . . . 50
Creating the VM guest user ID . . . . . . . . 76
Obtaining information about the IPL method . . 50
DASDs . . . . . . . . . . . . . . . 76
Gaining access to VSE/ESA . . . . . . . . 51
Network connection . . . . . . . . . . 76
Building the tape using VSE/ESA . . . . . . . 51
User directory . . . . . . . . . . . . 77
Creating the image and initrd files on VSE/ESA
Checking the CMSUSER profile . . . . . . . 77
(VSAMCR) . . . . . . . . . . . . . 51
Assigning an IP address to the VM guest user ID. . 77
Creating a parameter line file on VSE/ESA
Preparing the VM guest user profile . . . . . . 77
(CREAVSAM) . . . . . . . . . . . . 52
Copying the IPL files to the VM host . . . . . . 78
Locating the LINUX for S/390 files . . . . . 53
Building a parameter line. . . . . . . . . . 79
Using FTP to get the kernel and initial RAMdisk
Preparing the tape for IPL . . . . . . . . . 79
files (FTPJOB) . . . . . . . . . . . . 54
Copying the IPL files to the tape . . . . . . . 80
Building an IPL-able tape (DITTOTAV) . . . . 54
Using ditto to copy the files . . . . . . . . 80
Preparing your root file system for initial IPL . . . 55
Using filedef to copy the files . . . . . . . 82
IPL-ing from tape . . . . . . . . . . . . 55
Ensuring you do not format the wrong devices . . 82
Logging into your system and testing it . . . . 56
Checking the DASD devices . . . . . . . . 82
Formatting the DASDs . . . . . . . . . . 56
Detaching unused DASD devices . . . . . . 82
Preparing to transfer your root file system . . . . 57
IPL-ing from tape . . . . . . . . . . . . 82
Populating the new root file system on DASD . . . 57
Entering network information . . . . . . . . 83
Creating a swap file or device . . . . . . . . 57
Starting LINUX . . . . . . . . . . . . . 83
Using a complete volume as swap space . . . 58
Formatting the devices . . . . . . . . . . 84
Creating a file system . . . . . . . . . . . 85
Activating the swap space . . . . . . . . 58
Creating a swap device . . . . . . . . . . 85
Transferring the complete LINUX file system to
system . . . . . . . . . . . . . . . . 59
LINUX for S/390 . . . . . . . . . . . . 85
Getting a new kernel appropriate to your needs . . 59
Restoring file system from the archive . . . . . 86
IPL-ing from DASD . . . . . . . . . . . 60
IPL-ing from DASD . . . . . . . . . . . 87
Hints, Tips, and Troubleshooting: . . . . . . . 61
What are the corresponding device names to my
DASD devnos? . . . . . . . . . . . . 61 Chapter 9. Installing - Multiprise 3000 89
Some devices are not detected by LINUX for I/O settings . . . . . . . . . . . . . . 89
S/390 . . . . . . . . . . . . . . . 61
The hardware console ″hangs″ . . . . . . . 61
iv LINUX for S/390: Installation, Configuration and Use

Part 3. Configuration procedures 91 Support for synchronous read-write . . . . . . 125
Support for DASD devices . . . . . . . . . 125
Support for ECKD disks. . . . . . . . . . 125
Chapter 10. Upgrading from LINUX Support for FBA disks . . . . . . . . . . 126
2.2.13 to LINUX 2.2.15 . . . . . . . . 93 Support for DIAG access to CMS reserved
minidisk . . . . . . . . . . . . . . . 126
Chapter 11. Tuning your LINUX for XPRAM device support . . . . . . . . . . 126
S/390 installation . . . . . . . . . . 95 LCS device support . . . . . . . . . . . 127
IEEE emulation . . . . . . . . . . . . . 95 CTC device support . . . . . . . . . . . 127
Networking . . . . . . . . . . . . . . 95 IUCV device support . . . . . . . . . . . 127
DASD . . . . . . . . . . . . . . . . 96 Support for 3215 line mode terminal . . . . . 128
Memory optimization . . . . . . . . . . . 96 Support for console output on 3215 line mode
Compiler optimization. . . . . . . . . . . 96 terminal . . . . . . . . . . . . . . . 128
Apache tuning . . . . . . . . . . . . . 97 Support for hardware console . . . . . . . . 128
Connectivity between LINUX for S/390 and other Console output on hardware console . . . . . 129
S/390 operating systems . . . . . . . . . . 97
Part 5. Reference information . . . 131
Part 4. Kernel building . . . . . . . 99
Chapter 16. Using LINUX for S/390
Chapter 12. Building the kernel. . . . 101 device drivers . . . . . . . . . . . 133
Preliminary steps . . . . . . . . . . . . 101 Common device support . . . . . . . . . 133
Configuring the parameters . . . . . . . . 102
Checking the configuration . . . . . . . . . 103 Chapter 17. LINUX for S/390 device
Checking the dependencies . . . . . . . . . 103 drivers . . . . . . . . . . . . . . 135
Compiling the kernel . . . . . . . . . . . 103 DASD . . . . . . . . . . . . . . . . 135
Compiling for IPL from tape . . . . . . . 104 Features . . . . . . . . . . . . . . 135
Installing the modules . . . . . . . . . . 104 Limitations . . . . . . . . . . . . . 135
Finishing off. . . . . . . . . . . . . . 104 Kernel parameter syntax. . . . . . . . . 136
Example . . . . . . . . . . . . . . 137
Chapter 13. Using ’config’ or Using DASD . . . . . . . . . . . . 137
’oldconfig’. . . . . . . . . . . . . 107 VM minidisk . . . . . . . . . . . . . 138
Sample output listing. . . . . . . . . . . 107 Features . . . . . . . . . . . . . . 138
Cross-reference to configuration options . . . . 109 Kernel parameter syntax. . . . . . . . . 138
Example . . . . . . . . . . . . . . 139
Chapter 14. Using ’menuconfig’ . . . 111 Optional items . . . . . . . . . . . . 139
XPRAM . . . . . . . . . . . . . . . 139
File handling . . . . . . . . . . . . . 111
Features . . . . . . . . . . . . . . 139
Main menu . . . . . . . . . . . . . . 112
Limitations . . . . . . . . . . . . . 139
Code maturity level option . . . . . . . . . 113
Kernel parameter syntax. . . . . . . . . 139
Processor type and features. . . . . . . . . 113
Module parameter syntax . . . . . . . . 140
Loadable module support . . . . . . . . . 114
CTC/ESCON . . . . . . . . . . . . . 141
General setup . . . . . . . . . . . . . 114
Features . . . . . . . . . . . . . . 141
S/390 block device drivers . . . . . . . . . 115
Limitations . . . . . . . . . . . . . 141
S/390 network device support. . . . . . . . 116
S/390 terminal and console options . . . . . . 116
Example . . . . . . . . . . . . . . 142
Networking options . . . . . . . . . . . 117
Activation of the CTC connection . . . . . 142
QoS and/or fair queueing . . . . . . . . . 118
Recovery procedure after a crash . . . . . . 143
Filesystems . . . . . . . . . . . . . . 118
IUCV . . . . . . . . . . . . . . . . 144
Network file systems . . . . . . . . . . . 119
Limitations . . . . . . . . . . . . . 144
Partition types . . . . . . . . . . . . . 119
Optional items . . . . . . . . . . . . 144
Kernel hacking . . . . . . . . . . . . . 120
3215 line mode terminal . . . . . . . . . . 145
Load an alternate configuration file . . . . . . 120
Features . . . . . . . . . . . . . . 145
Save configuration to an alternate file . . . . . 121
Limitations . . . . . . . . . . . . . 145
Exit ’menuconfig’ . . . . . . . . . . . . 121
Using the 3215 . . . . . . . . . . . . 146
Chapter 15. Kernel parameter options 123 Hardware console . . . . . . . . . . . . 147
IEEE FPU emulation . . . . . . . . . . . 123 Features . . . . . . . . . . . . . . 147
Built-in IPL record support . . . . . . . . . 124 Limitations . . . . . . . . . . . . . 148
IPL method generated into head.S . . . . . . 124 Usage . . . . . . . . . . . . . . . 148
Support for VM minidisk . . . . . . . . . 124
Contents v
Chapter 18. FAQs. . . . . . . . . . 151 Usage . . . . . . . . . . . . . . . 159
Do I have a G3 or above processor? . . . . . . 151 Parameters . . . . . . . . . . . . . 160
How do I edit a file using the hardware or 3215 Additional keywords . . . . . . . . . . 160
consoles? . . . . . . . . . . . . . . . 151 dasdfmt . . . . . . . . . . . . . . . 161
How do I set up TCP/IP under VM using IUCV? 152
Setting up TCP/IP on the VM host with IUCV 152 Chapter 21. File system .tar file
Modify parm line . . . . . . . . . . . 153 contents . . . . . . . . . . . . . 163
Modify your user directory . . . . . . . . 153 initfs_small.tgz . . . . . . . . . . . . . 163
How do I boot from a VM reader? . . . . . . 153 initfs_big.tgz . . . . . . . . . . . . . 164
How do I enter CP commands in a running LINUX
environment? . . . . . . . . . . . . . 154
Is the network interface card working on my Part 6. Appendixes . . . . . . . . 167
MP3000? . . . . . . . . . . . . . . . 154
Appendix. Notices . . . . . . . . . 169
Chapter 19. LINUX for S/390 GNU General Public Licence, Version 2, June 1991 170
references. . . . . . . . . . . . . 155 Preamble . . . . . . . . . . . . . . 170
LINUX documents . . . . . . . . . . . 155 GNU General Public Licence: Terms and
S/390 documents . . . . . . . . . . . . 155 conditions for copying, distribution and
modification . . . . . . . . . . . . . 171
Trademarks . . . . . . . . . . . . . . 175
Chapter 20. execs, shell scripts, and
tools . . . . . . . . . . . . . . . 157 Glossary . . . . . . . . . . . . . 177
netsetup . . . . . . . . . . . . . . . 157
silo . . . . . . . . . . . . . . . . . 159
vi LINUX for S/390: Installation, Configuration and Use

About this book
This book provides information about installing, configuring, and using the LINUX
operating system on the IBM S/390 architecture.
Version 2.2.15 of the LINUX kernel is ported in this release of LINUX for S/390. If
you are using another version of the kernel, some of your kernel’s parameters may
be different to the parameters described in this book.
You will probably need additional documentation to effectively use your LINUX
for S/390 system. The type of document you need depends on your knowledge of
LINUX and whether you are new to S/390 or an established expert. See
“Chapter 19. LINUX for S/390 references” on page 155 for some suggested titles.
This book is an overview of the installation and customization of LINUX for

S/390, anyone requiring more detailed information should read the LINUX for
S/390-specific documentation in the kernel patch source tree.
How this book is organized

The following parts of this document describe LINUX for S/390. Note that only
the differences between the ’standard’ LINUX implementations and LINUX for
S/390 are described:
v Part 1. Overview and planning – introduces concepts and terminology. Identifies
important prerequisites for the installation process.
v Part 2. Installation – describes three types of native/LPAR installation, two types
of VM installation, and provides information about installing on a Multiprise
3000.
v Part 3. Configuration procedures – shows how to upgrade from an older kernel
version. Introduces tuning concepts.
v Part 4. Kernel building – describes how to build the LINUX for S/390 kernel and
how to use ’config’, ’oldconfig’ or ’menuconfig’. Provides a short description of
each of the LINUX for S/390 configuration options.
v Part 5. Reference information – introduces the LINUX for S/390 device drivers,
highlights their features and limitations, and explains how to use them. Answers
some FAQs, provides some suggested reading for both LINUX and the S/390
architecture. Lists executables, scripts and tools, and tar-archive contents.
v Part 6. Appendixes – lists copyright notices and trademarks, and includes a
glossary of terms.
Who should read this book

This book is intended for:
v Users who want to utilize the LINUX operating system on their ESA/390
architecture
v Distributors who want to build a LINUX for S/390 distribution
v Developers who want to participate in the enhancement of the LINUX for S/390
kernel.
© Copyright IBM Corp. 1999 vii

Ideally, these readers should be familiar with LINUX installation on ’standard’
platforms, and have an understanding of the ESA/390 architecture. However, other
readers who are interested in the installation of LINUX onto the ESA/390
architecture can use this book to gain an overview of the procedures involved.
Assumptions
The following general assumptions are made about your background knowledge:
v You have an understanding of LINUX and S/390 terminology.
v You have an understanding of basic computer architecture, operating systems,
and programs.
viii LINUX for S/390: Installation, Configuration and Use

Summary of changes
This revision contains changes to support the LINUX for S/390 kernel patch to the
LINUX kernel version 2.2.15.
Edition 6 changes
New and Changed Information
v The file names used when downloading the kernel (for tape or VM reader),
RAM disk initial file system, and complete file system (for DASD or minidisk)
have been changed. The files are renamed once they have been transferred from
the web site.
Filenames at web site Renamed files after transfer

image.tape.bin image.txt
image.vm.bin vmlinux.txt
initrd.bin initrd.txt
initfs_small.tgz or initfs_big.tgz initfs.txt
This revision also includes maintenance and editorial changes.
Edition 5 changes
New Information
v Added new section describing LINUX and S/390 concepts and architecture to
help introduce LINUX for S/390 to new readers.
v Added new sections describing building an IPL-able tape for native installation
using OS/390 or VSE/ESA.
v Added new section describing installation differences for a Multiprise 3000.
v Added new section introducing Tuning concepts.
v Added new section describing a device driver for expanded storage (XPRAM).
v Added new section listing the contents of initfs_small.tgz and
initfs_big.tgz.
v Added new FAQ describing TCP/IP setup under VM using IUCV.
v Information has been added to describe new capabilities of the DASD device
driver to support additional device types - FBA and MDSK. Enhanced partition
support is described and the default for the DASD device driver is probeonly
which writes the results to a log file instead of registering the DASDs.
v Information has been added to describe restrictions on main memory and swap
space size to a maximum of 2 GB.
v Information has been added to describe CTC limitations and workarounds.
v Information has been added to describe APARs required when using IEEE FPU
under VM. APARs are VM62337 and VM62410. VM61762 is required if the
version of VM is V2R3.0. Also, APAR PQ34318 is required when using TCP/IP
under VM.
© Copyright IBM Corp. 1999 ix

Changed Information
v The document has been restructured to provide individual chapters for each of
the five methods of installation that are described.
v The kernel used is now 2.2.15.
v The kernel image (DRV06_smp_tape.img) has been updated (to
DRV11_smp_tape.img). The file name on the web site has also changed.
v The kernel image (DRV06_smp_vm.img) has been updated (to
DRV11_smp_vm.img).The file name on the web site has also changed.
v The description of how to set up a cross build environment has been removed.
v The description of the putdisk REXX exec has been removed.
v The descriptions of the 3215 terminal and Hardware console have been
expanded.
v The vmlink command is not normally available outside IBM and the description
of connecting to a disk for TCP/IP in VM has been amended.
Edition 4 changes
New Information
v A new description has been written for the installation process in VM using the
reader. This method uses the initfs_small.tgz or initfs_big.tgz file system
archive. This replaces the original description which used the initmd.bin file
system archive.
Changed Information
RAM disk initial file system, and complete file system have been changed. The
files are renamed once they have been transferred from the web site.

DRV06_smp_tape.img image.txt
DRV06_smp_vm.img vmlinux.txt
initrd.tgz initrd.txt
Edition 3 changes
New Information
v A statement has been added to indicate that the compressed RAM disk initial
file system file initrd.bin.gz is uncompressed automatically during IPL.
v A suggested method for upgrading from kernel 2.2.13 to kernel 2.2.14 has been
added.
v A description of how to set up a cross build environment has been added.
v An FAQ describing how to determine whether you have a G3 or later processor
has been added.
x LINUX for S/390: Installation, Configuration and Use

Changed Information
RAM disk initial file system, and complete file system (for DASD or minidisk)
have been changed. The files are renamed once they have been transferred from
the web site.

image.tape.bin image.txt
image.vm.bin vmlinux.txt
initrd.bin.gz initrd.txt
initmd.bin initmd.txt
v The blocksize used to format minidisk B when installing using VM has been
changed to 512 bytes. A note has been added to indicate that the blocksize used
for initmd.txt must match the minidisk B blocksize.
v The locsite fix command used when transferring initmd.txt has been
changed to 512 bytes.
v A note has been added indicating where the content of the lin.exec, lipl.exec,
and putdisk.exec files can be found in this document.
v A better description has been written of the recovery method used after
forgetting your root password.
v The time-delay period that allows the OSA-2 card to reset after an IPL has been
increased to 2 minutes (ipldelay=2m)
v The description of silo has been expanded.
Edition 2 changes
New Information
v A new CTC kernel parameter is provided to deactivate automatic channel
selection. This parameter (ctc=noauto) prevents conflicts occurring with other
I/O devices.
v The recovery procedure used after a CTC device connection crashes in a native
installation is described
v Alternative utilities have been described for transferring data to a tape device.
For example, filedef
v A caution has been added to raise awareness of potential problems occurring
when running LINUX for S/390 on a shared environment
v The hardware console does not recognize a reboot.
Changed Information
v The size of the large file system has increased because of the additional packages
that have been ported. You now need approximately 800 MB of free hard disk
space to unpack (tar) the initfs_big.tgz file. This means you now need
approximately 1000 cylinders on an IBM 3390
v The default password has been standardized for all occasions it is required. It is
now pass4root
v The DASD major number has been changed from 80 to 94
Summary of changes xi
v The DASD names have been changed from dd<letter><number> to
dasd<letter><number>. For example, dda1 is now dasda1
v The DASD default blocksize is now 4096 (4 KB)
v The gcc version used by this release is now 2.95.2
v The VM minidisk major number has been changed from 64 to 95
v The VM boot parameter file syntax and format have been simplified. The
keyword EBCDIC is no longer required. Only the virtual device is necessary in the
mdisk=parameter command (the makeparm.exec is no longer required
Note that ″old″ minidisk drivers can still use markeparm.exec, however any
minidisks formatted with this current LINUX for S/390 patch do not require the
executable
v The oper tape utility is not normally available outside IBM and its description
has been removed.
xii LINUX for S/390: Installation, Configuration and Use

Part 1. Overview and planning
Chapter 1. LINUX for S/390 information roadmap 3 Network . . . . . . . . . . . . . . . 9
Tools and utilities . . . . . . . . . . . 10
Chapter 2. Overview to LINUX for S/390 . . . . 5 Configuration files . . . . . . . . . . . 10
S/390 introduction . . . . . . . . . . . . 5
S/390 machine types . . . . . . . . . . 5 Chapter 3. Planning your installation . . . . . 13
VM . . . . . . . . . . . . . . . . 5 Choosing the LINUX for S/390 run-time
Console . . . . . . . . . . . . . . . 5 environment . . . . . . . . . . . . . . 13
Hard disks . . . . . . . . . . . . . . 5 Running LINUX for S/390 in a shared environment 13
Expanded storage. . . . . . . . . . . . 6 Overview of the installation steps . . . . . . . 14
Network . . . . . . . . . . . . . . . 6 Running LINUX for S/390 . . . . . . . . 14
S/390 devices currently not supported. . . . . 6 Establishing the requirements of LINUX for
S/390 terminology . . . . . . . . . . . . 7 S/390 . . . . . . . . . . . . . . . 15
OS concepts . . . . . . . . . . . . . 7 Prerequisites for installation . . . . . . . . 15
Hardware support components . . . . . . . 7 Administrator requests . . . . . . . . 16
S/390 devices . . . . . . . . . . . . . 7 Network specification . . . . . . . . . 16
Tools and utilities. . . . . . . . . . . . 8 IPL tape requirements . . . . . . . . . 16
LINUX terminology . . . . . . . . . . . . 8 File system preparation . . . . . . . . 16
OS concepts . . . . . . . . . . . . . 8 Hardware information . . . . . . . . . 17
Devices . . . . . . . . . . . . . . . 9 Further information . . . . . . . . . . . 17
File system . . . . . . . . . . . . . . 9
© Copyright IBM Corp. 1999 1

2 LINUX for S/390: Installation, Configuration and Use
Chapter 1. LINUX for S/390 information roadmap
Figure 1. Information roadmap

Chapter 2. Overview to LINUX for S/390
This section provides an introduction to LINUX for S/390 concepts, architecture,
and terminology. Refer to the “Glossary” on page 177 for short descriptions of the
abbreviations and terms used throughout this document.
S/390 introduction
S/390 machines do not support all of the devices known in the personal computer
and workstation world. Devices such as floppy diskette drives, sound cards, mice,
keyboards, or graphics cards are not available to S/390 applications. This means
that there are fewer drivers required to take care of running LINUX for S/390
when compared to (PC) LINUX. Also, SCSI and IDE hard drives are not visible to
LINUX for S/390 so the S/390 disks cannot be reached via /dev/hda or /dev/sda.
S/390 machine types

LINUX for S/390 requires the new immediate and relative instructions introduced
with the S/390 CMOS-processors (G3 and newer processors).
VM
When operating in VM, the machine mode must be set to ESA.
Although VM allows you to define up to 64 virtual S/390 processors per guest

machine, LINUX for S/390 currently provides support for a maximum of 32
processors only.
Console
LINUX for S/390 has two console drivers:
v A 3215 console driver which can be used on a 3270 terminal or in a 3270
emulation session.
v The hardware console driver (HWC) is used for the Stand Alone Support
Element (SA/SE) or the Hardware Management Console (HMC).
Both devices are line-mode consoles - so they should only be used to configure all
basic setup operations before logging-on to LINUX via Telnet. Note that there is a
special feature that allows you to enter some basic control-key combinations on the
consoles. Please have a look at “Using the 3215” on page 146 and “Hardware
console” on page 147 for further details. The console devices can be reached via
/dev/console.
Hard disks
S/390 hard disks are visible as Direct Accessible Storage Devices (DASDs) for all
S/390 operating systems. LINUX for S/390 has two hard disk drivers:
v The DASD driver is able to access ECKD-style DASDs (3380, 3390, 9345) directly
with its own management (using channel programs) and can be used for
dedicated disks or VM minidisks. The devices controlled by the DASD driver
can be reached via /dev/dasd (for the non-partitioned device) and /dev/dasd1,
etc. (for the partitions).

v The minidisk driver can be used under VM only and accesses CMS reserved
minidisks (using DIAG 250). The devices controlled by the minidisk driver can
be reached via /dev/mnda, /dev/mndb, etc.
With the current shipment, the DASD driver incorporates the former VM minidisk
driver and is able to access CMS reserved minidisks with its own management via
DIAG 250 commands. Note that you cannot IPL LINUX for S/390 from CMS
reserved minidisks. Refer to “DASD” on page 135 for more information.
Expanded storage
The S/390 architecture supports more RAM than can be accessed as main memory.
The S/390 main memory is limited to 2 GB. However, additional memory can be
declared as expanded storage. The S/390 architecture allows applications to access
up to 16 TB of expanded storage (although the current hardware can only be
equipped with up to 64 GB memory). Memory in the expanded storage range can
be copied in 4 KB blocks to, or from, the main memory.
An interesting feature of expanded storage is that is persistent with respect to IPLs

(booting) but volatile with respect to IMLs (power off/on).
The current release of the kernel patches provide a new driver called XPRAM. This
is a block device driver that supports LINUX for S/390 allowing it to access the
expanded storage. Thus XPRAM can be used as a basis for fast swap devices
and/or fast file systems.
Network
LINUX for S/390 supports network connections via OSA-2 and OSA Express cards
using the LAN Channel Station protocol (LCS).
The network interfaces appear as tr0, tr1, etc. or eth0, eth1, etc. respectively. Note
that there are some configuration parameters for the LCS driver. Refer to the
LINUX for S/390: LCS Device Driver document.
LINUX for S/390 also provides network interfaces via Channels - either Parallel
Channels, ESCON Channels or virtual channels. Under VM, inter-guest
communication with IUCV is supported as well. The network interfaces appear as
ctc0, ctc1, etc. or escon0, escon1, etc. respectively.
Some LINUX options are not supported in this release of LINUX for S/390. IP
Multicasting is not supported, and the NFS server has never been tested.
S/390 devices currently not supported

The following S/390 devices are not yet supported by LINUX for S/390:
v Tape driver (though IPL from tape is supported).
v OSA Express Gigabit Ethernet.
v Direct attached CISCO routers running the CLAW-protocol.
v Old-type DASDs (prior to ECKD).
Please check the web site

http://oss.software.ibm.com/....linux390/restrictions regularly for the current
and new restrictions of LINUX for S/390.

S/390 terminology
OS concepts
The three Operating Systems which are based on the S/390 architecture are:
v OS/390 - this has proprietary batch and on-line interfaces (JCL, TSO/E, ISPF)
and also a UNIX System Services which mostly run on large mainframes.
v VSE/ESA - this is a system that consists of a basic operating system
(VSE/Advanced Functions) and any IBM supplied and user-written programs
required to meet the data processing needs of a user. VSE and the hardware it
controls form a complete computing system.
v VM/ESA - this is a system which manages the resources of a single computer so
that multiple S/390 systems appear to exist. Each virtual machine is the
functional equivalent of a real machine.
The following terms can be found in the glossary section: VM CP/CMS, VM guest,
VM reader/punch/printer, VM minidisk.
Hardware support components

On a S/390 you can find the following Hardware Support Components:
v SE (service element)
v HMC (hardware management console)
On a S/390 system the Operating System can be run in:
v native mode
v LPAR mode
v VM mode
The I/O is organized in form of a channel subsystem
v CHPID
v IOCDS
which are described in the Principles of Operation (SA22-7201-06).
The storage is divided into main storage/expanded storage
S/390 devices
The S/390 devices are addressed by their device numbers in the form of CUU
(Control Unit and Unit Address) which could be:
v a disk - DASD of following types:
– 3380
– 3390
v a connection channel like:
– OSA
– CTC (which can be virtual or real)
– or ESCON
– or a virtual connection IUCV
v a terminal device like:
– 3270
– 3215
Chapter 2. Overview to LINUX for S/390 7

v a tape unit:
– 3480
– 3490E
v or tape subsystem like:
– 3590E
Tools and utilities

v The most common tool which exists on OS/390, VSE/ESA, and VM/ESA is
DITTO.
v On OS/390, the user has access to a set of batch tools which manage the
proprietary OS/390 sequential and partitioned datasets like IEBCOPY,
IEBGENER and such. Datasets can be accessed and manipulated using an ISPF
dialog interface.
v On OS/390, The UNIX File system is the Hierarchical File System (HFS) which
can be managed and manipulated with UNIX commands.
v On VSE/ESA, the most likely used tools are LIBRarian to access and operate on
members stored in VSAM or SAM files.
v On VM/ESA, CMS commands are used to perform operations on files.
LINUX terminology
OS concepts
The following are LINUX and S/390 equivalents:
v kernel is known as the nucleus on OS/390 or the supervisor on VSE/ESA and
VM. The kernel module is the nucleus or supervisor module.
v boot is known as IPL (Initial Program Load) on S/390 OSs.
v boot parameter line has the same function as the IPL Load parameters on S/390.
v boot sector is known as the IPL boot record on S/390.
v user mode/kernel mode is equivalent to the problem state/supervisor state.
v system call is called a SVC (supervisor call instruction).
v swap space (file/device) on LINUX is represented by a page or swap dataset.
v user ID, group ID are the same in both operating systems.
v root is known as the super-user.
On the (batch and on-line) conventional parts of OS/390, on VSE/ESA, and on

VM/ESA, only user IDs are known. Special users can be defined with
administrator, or operator authorities, or maintenance access rights. The access
rights are normally controlled by a security product, for example RACF.
Linkage format (ELF) exists only on LINUX. On S/390, the source members or files
are complied into objects and link-edited into a OS/390 module or a VSE/ESA
phase.
Source files (.c), header files (.h), and object files (.o) are stored in datasets or VSE
libraries.
The counterparts of static libraries (.a), and shared libraries (.so) on LINUX are
system datasets in the system linklist or LPA of OS/390, or shared libraries stored
in the System or Partition GETVIS Area of VSE/ESA.

Devices
The following terms relate to devices:
v device driver is controlled by (for example) the I/O supervisor on VSE/ESA.
v device node (major/minor number) is represented by a control unit and unit
address.
v hard disk (IDE/SCSI ...) is known in S/390 as DASD (direct access storage
device).
v partition has a different meaning in VSE - it is the address space which is owned
by one program.
v floppy disk - not available in S/390.
v CD-ROM - not available in S/390.
v keyboard/mouse/video card is equivalent to the hardware console.
v mouse and video cards do not exist on S/390 systems. Hardware console and
3270 datastream terminals are proprietary devices on S/390.
v network adapter is equivalent to the OSA card
v point-to-point connection is equivalent to the CTC/ESCON/IUCV connection.
v ram disk is similar to the virtual disk or dataspace concept used in S/390.
File system
The following are file system terms that are the same for LINUX and S/390 except
where indicated:
v file system is known as the dataset.
v files/directories are known as dataset/member.
v root file system is the partition organized and sequential dataset.
v mount/unmount is known as attach/detach.
v mount points - not available in S/390.
v loopback mount (loopback device).
v ext2, NFS, iso9660, ...
v database products (VSAM, DB2, IMS, DL/I, ...)
Network
The following are networking terms that are the same for LINUX and S/390 except
where indicated:
v Network (TCP/IP) is used in both LINUX and S/390. S/390 additionally uses
the SNA protocol and VTAM.
v network interface.
v host address (IP).
v network address.
v network mask.
v broadcast address.
v router/gateway.
v DNS - name server.
v DNS - search domain.
The SNA/VTAM related terminologies are PUs (Physical Unit), LUs (Logical Unit),
sessions, and applications.

Tools and utilities
The following are tools and utilities:
v shells (bash, csh, tcsh, ...) is equivalent to CMS on VM, the TSO prompt mode on
OS/390, or the BG prompt on VSE/ESA.
v shell scripts/scripting languages (perl, tcl, python, ...) is equivalent to REXX
(which is the common interpreter) on VM/ESA, OS/390, and VSE/ESA.
v editors (ed, vi, emacs, joe, ...) is equivalent to XEDIT on VM, ISPF EDIT on
OS/390, and ICCF editor on VSE/ESA.
v file access (cp, mv, rm, chmod, cat, more, ...) can be performed using utilities
like: DITTO, IEBCOPY, IEBGENER on OS/390 or LIBR, IDCAMS on VSE/ESA.
v directory access (ls, cd, pwd, mkdir, rmdir, ...) not applicable to S/390. In
VSE/ESA, similar commands are included in the LIBRarian function.
v archiving/compressing (dd, tar, gzip, gunzip, ...) are implemented in the form of
utilities or commands like backup, restore on VSE/ESA and VM/ESA, or
DFSMS/MVS-Utilities on OS/390. S/390 also includes compression functions
implemented in hardware and software.
v compiler/linker/binutils (make, gcc, g++, ld, as, nm, objdump, ...) - same
concept, but the activation are made through batch-jobs, or procedures.
v system utilities (mount, umount, mknod, mkswap, swapon, mke2fs, fsck, ...).
v network utilities (ifconfig, route, netstat, ping, traceroute, ...).
Configuration files
start-up control/system configuration:
v /etc/inittab
v /etc/rc.d/*
v /etc/fstab
v /etc/syslog.conf
v /etc/modules.conf
authentication/security:
v /etc/passwd
v /etc/group
v /etc/shadow
v /etc/securetty
v /etc/hosts.allow
v /etc/hosts.deny
network:
v /etc/nsswitch.conf
v /etc/resolv.conf
v /etc/host.conf
v /etc/hosts
v /etc/services
v /etc/networks
v /etc/protocols

external services:
v /etc/inetd.conf
v /etc/sendmail.cf
v /etc/httpd/*
v /etc/exports
per-user shell customization is equivalent to PROFILE EXEC:

v x/.profile
v x/.bashrc
system-wide shell config defaults:

v /etc/profile
v /etc/bashrc
The system configuration are stored and controlled differently on S/390:

v On OS/390 – all parameters are stored in SYS1.PARMLIB, all system modules
are stored in SYS.LINKLIB, SYS1.LPALIB, etc.
v On VSE/ESA – The system is controlled during start-up by the IPLnnn PROC
and $JCLnnn PROC which, together with other network parameters located in
VTAM books, are stored in IJSSYSRS.SYSLIB and PRD2.config.
v On VM/ESA – there are some parallels to CMS:
– CF1 and AUTOLOG1 191 is equivalent to /etc/
– SYSPROF EXEC is equivalent to /etc/profile
– PROFILE EXEC for user XXX is equivalent to /home/XXX/.profile
CMS search orders have no direct equivalents in LINUX. To search a number of
directories, a user must set up a PATH variable to tell what directories to search
for commands or files. The file /etc/profile sets up a default path for all users
which includes /bin/, /usr/local/bin/ and /home/XXX/. To add a new
directory, say /abc/xyz/ to the PATH, add this to the .profile file on your
/home/<userid>/ directory:
PATH=$PATH:/abc/xyz

Chapter 3. Planning your installation
This chapter describes what you should consider before commencing installation.
Choosing the LINUX for S/390 run-time environment

You can run LINUX for S/390:
v Natively on an IBM S/390
v In an LPAR of an S/390
v As a guest of VM/ESA.
Running LINUX for S/390 in a shared environment

If you intend to run LINUX for S/390 in a shared environment together with other
S/390 operating systems, you must correctly set up your environment to ensure
the isolation of your operating systems.
While OS/390 or VSE/ESA have configuration scripts telling the OS which devices
to regard or disregard, LINUX does not. All it has is the kernel parameter list or
the parameters passed to a driver with insmod. Unless configured otherwise,
LINUX for S/390 will try to autosense all the devices accessible. While this is
usually the desired behavior when running native or as guest under VM/ESA, it
might not be desirable when running in a LPAR environment with shared CHPIDs.
This behavior may lead to sharing problems. This is not specific to LINUX, but is
also the case with misconfigured OS/390, VM/ESA, and VSE/ESA systems.
However, it might become more quickly visible with LINUX’s autosensing mode.
If you have an LPAR environment with shared CHPIDs there are two possible
approaches that will prevent sharing problems:
v Ensure that the IOCDS grants access only to the devices that do not need to be
physically shared between LINUX and another S/390 operating system. This is
the preferred solution.
v Ensure that the LINUX device drivers are configured to only use well known
devices, for example, specific OSA ports for network connectivity, or the DASDs
your LINUX file systems reside on. An example of a suitable kernel parameter
line is:
root=/dev/dasda ro dasd=200 ctc=noauto
This allows access only to the ECKD DASD with device number 200 - no other
devices are specified. Note that in LINUX, the parameter line file must be one
line only if you are IPL-ing from tape or disk.
The CTC driver is told to disregard all channel devices - no devices are specified
and auto-detection is turned off.
Please follow either of the two configuration methods to ensure that LINUX for
S/390 cannot disturb a production environment residing in another LPAR.

An alternative, but less certain, method exists to ensure the isolation of your
LPARs:
v In LINUX for S/390, determine which CHPIDs, control units, and devices must
be shared among the LPARs. Ensure that these are the only devices that are
defined as being shared in your IOCDS.
v In your other operating systems, determine which devices must be shared
among your nodes, and define only these devices as being shared.
Overview of the installation steps

The points you should consider when installing LINUX for S/390 are:
v “Running LINUX for S/390”
v “Establishing the requirements of LINUX for S/390” on page 15
v “Prerequisites for installation” on page 15
The following assumptions are made:
v An understanding of S/390 hardware and software terminology
v An awareness of basic computer architecture, operating systems, and programs
Running LINUX for S/390

There are several tasks that you have to perform to install LINUX for S/390 on
your system. Many of these tasks are dependent on your environment:
1. Locate the LINUX for S/390 files and transfer them to a local system:
2. Prepare the IPL medium and boot the initial kernel:
v Prepare a tape and perform the IPL from tape, or
v Perform the IPL from your virtual reader (when running under VM/ESA).
3. Mount the initial file system:
v Use a minimal initial root file system from a RAM disk, or
v Utilize VM/CMS’s reserved minidisk as a file system from CMS (when
running under VM/ESA). Note that you will have to initialize this file
system from CMS.
4. Initialize your disk volumes:
v Use the native DASD driver (you will have to low-level format the volume
before proceeding. This can be done using LINUX for S/390), or
v Use the VM-minidisk driver (you will have to prepare the disk under control
of CMS before proceeding)
v Then make a file system (mke2fs) on the disks.
5. Fill your file system with data:
v Copy the file system from NFS, or
v Unpack a tar-archive on the file system.
6. Customize your LINUX system:
v You can find more information about kernel customization in “Part 4. Kernel
building” on page 99 of this document. Additional documents are available
as listed in “Chapter 19. LINUX for S/390 references” on page 155
v The LDP provides a large amount of very useful information about the
LINUX kernel. This is available via anonymous FTP from the FTP site
sunsite.unc.edu in the /pub/Linux/docs subdirectory. Documents are also
available in HTML format from http://www.linuxdoc.org/docs.html

7. Build your own kernel:
v After you have successfully performed an installation, it is recommended
that you build a new kernel tailored to your individual needs for future use.
This ensures that the kernel drivers are set up to match your configuration
and also that LINUX for S/390 will operate as efficiently as possible.
8. Prepare the medium for future IPL:
v Use the DASD driver (you will be able to perform the IPL directly from the
DASD), or
v Prepare a tape to be used for the IPL, or
v Prepare your VM virtual reader to contain the kernel for any future IPL.
Establishing the requirements of LINUX for S/390

For a standard installation you need:
v Hardware Requirements:
– An S/390 configuration containing at least 64 MB memory. You must have
ownership of either a physical (native) machine, or be a virtual owner (using
LPAR or as a VM guest). The processor must be from the CMOS generation
chips and be at least G3. (It must support relative branches and immediate
instructions)
– One ECKD-DASD-volume of at least 300 Cylinders (3380 or 3390). Running as
a VM guest, it can be a VM-minidisk
– An OSA-2 card, virtual CTC or physical ESCON channels for network access.
All network connections require the right setup on LINUX for S/390 and the
remote partner
– Temporary access to a tape unit - this is not essential if you want to install
using the VM reader.
v Software Requirements:
– A standard S/390 operating system capable of writing data to tape, for
example using DITTO or filedef, for preparing the initial medium. The
operating system can be OS/390, VM/ESA, or VSE/ESA
Note that if you intend to IPL using the VM virtual reader, then your
operating system does not have to be able to write data to tape
– A network connection (TCP/IP) to that OS, to transfer the LINUX for S/390
distribution’s files to the system.
v Installation media:
– A kernel that you can IPL from either tape (image.tape.bin) or the VM
virtual reader (image.vm.bin), respectively. If you decided to IPL from tape,
you need an empty tape cartridge to format ready for the IPL
– An archive or image of the root file system. We recommend running the root
file system from a DASD, then you need the small file system
initfs_small.tgz or the big file system initfs_big.tgz.
– If you want to build a customized kernel for your system, you need the
kernel’s sources. The compiler/binutils and development tools are included in
the image of the file system.
Prerequisites for installation

There are certain actions to be performed and information to collect before
commencing installation.
Chapter 3. Planning your installation 15

Administrator requests
The following items should be requested from your administrator:
v Two DASDs:
– file system: 1000 cylinders (using an IBM 3390)
– swap space: 200 cylinders (using an IBM 3390) — note 2 GB maximum
v IP address
v Two network connections (for example, two virtual CTC addresses, or two
OSA-2 addresses)
v VM guest user ID: with (suggested) 64 MB memory
Network specification
Make sure that you know the network parameters of your LINUX for S/390
system. These are:
v host name
v IP-address
v net mask
v network-address
v broadcast address
v gateway address
v IP-address of the DNS server
v DNS search domain.
IPL tape requirements

You need to locate the following files (in the download area of the LINUX for
S/390 website):
v kernel file (for example image.tape.bin)
v parameter file (you may have to create this, if so, call it parm.line)
v initial RAM disk file (for example initrd.bin)
Copy the kernel and initial RAM disk files to your local workstation (UNIX or
Windows NT) using, for example FTP. Or just simply download the files directly
by using your web browser.
Note that the initial RAMdisk file (initrd.bin that you renamed initrd.txt) is a
compressed file that the kernel will uncompress during IPL.
Similarly, copy the parameter file to your local workstation (or create a new file).
Note that in LINUX, the parameter line file must be one line only if you are
IPL-ing from tape or disk. The contents of the parameter file should be:
dasd=from-to root=/dev/ram0 ro ipldelay=xyz
where from-to is the range of your DASD devices (for example, 150–151).
You will transfer these three files to your IPL tape during the installation process.
You also need a utility, for example DITTO or filedef, to build the IPL tape.
File system preparation

Locate the archive of the complete LINUX file system that you want to use.
Pre-existing file system images exist in the download area of the LINUX for S/390
website. There are two archives (small and large depending on the number of
utilities and applications bundled with the file system). These archives are named

initfs_small.tgz and initfs_big.tgz. Both archives are compressed tar files and
the large one might require 800 MB of disk space when extracted.
Copy the archive to your local workstation (UNIX or Windows NT) using, for
example FTP. Or just simply download it using your web browser.
Hardware information
You need a list of your computer’s hardware configuration and networking
information. Most of this information can be found in the system documentation
supplied with your system. You will need to know about your:
v Disk drives, memory, and network card
v IP-address, net mask, gateway IP-address, name-server IP-address(es), domain
name, and host name.
Further information
There are several different sources of information available:
v “Chapter 4. Installation - native single image and LPAR - OS/390” on page 21:
This provides information about the native installation using OS/390 to build
the IPL tape
v “Chapter 5. Installation - native single image and LPAR - VM/ESA” on page 35:
This provides information about the native installation using VM/ESA to build
the IPL tape
v “Chapter 6. Installation - native single image and LPAR - VSE/ESA” on page 49:
This provides information about the native installation using VSE/ESA to build
the IPL tape
v “Chapter 7. Installation using VM - IPL from the VM reader” on page 63: This
provides information about the installation steps required using the VM reader
to get LINUX running as a VM guest
v “Chapter 8. Installation using VM - IPL from tape” on page 75: This provides
information about the installation steps required using an IPL tape to get LINUX
running as a VM guest
v The help command in VM provides additional information about the installation
process
v Linux Network Administrator’s Guide — Olaf Kirch, Andy Oram (Editor) —
O’Reilly & Associates; also available from the LDP website at
http://www.linuxdoc.org/
v Linux System Administrator’s Guide; available from the LDP website at
v IBM Online Library S/390 Rainbow Collection: SK2T-2177-10; contains information
that will help you to customize your environment for running LINUX for S/390:
– I/O configuration data set (IOCDS): Useful when customizing the S/390
Hardware from the SE
– VM/ESA: When administering VM as a hosting OS
– Devices: Detailed information about the devices attached to your system.
These documents can be ordered from your local IBM representative, see
“Chapter 19. LINUX for S/390 references” on page 155.
Chapter 3. Planning your installation 17

Part 2. Installation
Chapter 4. Installation - native single image and Building the tape using VM/ESA . . . . . . . 38
LPAR - OS/390 . . . . . . . . . . . . . 21 Building a parameter line using VM/ESA . . . 38
Preparing for installation . . . . . . . . . . 22 Building an IPL-able tape. . . . . . . . . 39
Choosing the installation method . . . . . . 22 Using FTP on VM/ESA . . . . . . . . 39
Obtaining information about your network Transferring the files to tape . . . . . . . 39
environment . . . . . . . . . . . . . 22 Preparing your root file system for initial IPL . . . 41
Obtaining information about the IPL method . . 22 IPL-ing from tape . . . . . . . . . . . . 41
Gaining access to OS/390. . . . . . . . . 23 Logging into your system and testing it . . . . 42
Creating the tape - overview . . . . . . . . 23 Formatting the DASDs . . . . . . . . . . 42
Locating the LINUX for S/390 files . . . . . . 23 Preparing to transfer your root file system . . . . 43
Getting the image of the kernel . . . . . . . 23 Populating the new root file system on DASD . . . 43
Using the supplied kernel . . . . . . . 24 Creating a swap file or device . . . . . . . . 43
Getting the image of the root file system for Using a complete volume as swap space . . . 44
initial IPL . . . . . . . . . . . . . . 24 Using a file as swap space . . . . . . . . 44
Building the tape using OS/390 . . . . . . . 24 Activating the swap space . . . . . . . . 44
Building a parameter line file on OS/390 . . . 24 Customizing the configuration files of the new file
Building an IPL-able tape. . . . . . . . . 25 system . . . . . . . . . . . . . . . . 45
Using FTP on native OS/390 . . . . . . 25 Getting a new kernel appropriate to your needs . . 45
Transferring the files to tape using OS/390 . . 26 Preparing for IPL from DASD . . . . . . . . 45
Preparing your root file system for initial IPL . . . 26 IPL-ing from DASD . . . . . . . . . . . 46
IPL-ing from tape . . . . . . . . . . . . 27 Hints, Tips, and Troubleshooting: . . . . . . . 47
Logging into your system and testing it . . . . 27 What are the corresponding device names to my
Formatting the DASDs . . . . . . . . . . 28 DASD devnos? . . . . . . . . . . . . 47
Preparing to transfer your root file system . . . . 29 Some devices are not detected by LINUX for
Populating the new root file system on DASD . . . 29 S/390 . . . . . . . . . . . . . . . 47
Creating a swap file or device . . . . . . . . 29 The hardware console ″hangs″ . . . . . . . 47
Using a complete volume as swap space . . . 29 No messages on system console during IPL . . 47
Activating the swap space . . . . . . . . 30 Chapter 6. Installation - native single image and
Customizing the configuration files of the new file LPAR - VSE/ESA . . . . . . . . . . . . 49
system . . . . . . . . . . . . . . . . 30 Preparing for installation . . . . . . . . . . 50
Getting a new kernel appropriate to your needs . . 31 Choosing the installation method . . . . . . 50
Preparing for IPL from DASD . . . . . . . . 31 Obtaining information about your network
IPL-ing from DASD . . . . . . . . . . . 32 environment . . . . . . . . . . . . . 50
Hints, Tips, and Troubleshooting: . . . . . . . 32 Obtaining information about the IPL method . . 50
What are the corresponding device names to my Gaining access to VSE/ESA . . . . . . . . 51
DASD devnos? . . . . . . . . . . . . 32 Building the tape using VSE/ESA . . . . . . . 51
Some devices are not detected by LINUX for Creating the image and initrd files on VSE/ESA
S/390 . . . . . . . . . . . . . . . 33 (VSAMCR) . . . . . . . . . . . . . 51
The hardware console ″hangs″ . . . . . . . 33 Creating a parameter line file on VSE/ESA
No messages on system console during IPL . . 33 (CREAVSAM) . . . . . . . . . . . . 52
Locating the LINUX for S/390 files . . . . . 53
Chapter 5. Installation - native single image and Getting the image of the kernel . . . . . . 53
LPAR - VM/ESA . . . . . . . . . . . . 35 Getting the image of the root file system for
Preparing for installation . . . . . . . . . . 36 initial IPL . . . . . . . . . . . . . 54
Choosing the installation method . . . . . . 36 Using FTP to get the kernel and initial RAMdisk
Obtaining information about your network files (FTPJOB) . . . . . . . . . . . . 54
environment . . . . . . . . . . . . . 36 Building an IPL-able tape (DITTOTAV) . . . . 54
Obtaining information about the IPL method . . 37 Preparing your root file system for initial IPL . . . 55
Gaining access to VM/ESA . . . . . . . . 37 IPL-ing from tape . . . . . . . . . . . . 55
Creating the tape - overview . . . . . . . . 37 Logging into your system and testing it . . . . 56
Locating the LINUX for S/390 files . . . . . . 37 Formatting the DASDs . . . . . . . . . . 56
Getting the image of the kernel . . . . . . . 37 Preparing to transfer your root file system . . . . 57
Using the supplied kernel . . . . . . . 38 Populating the new root file system on DASD . . . 57
Getting the image of the root file system for Creating a swap file or device . . . . . . . . 57
initial IPL . . . . . . . . . . . . . . 38 Using a complete volume as swap space . . . 58

Using a file as swap space . . . . . . . . 58 Starting and stopping the system . . . . . . . 73
Activating the swap space . . . . . . . . 58 Remembering your password . . . . . . . . 73
system . . . . . . . . . . . . . . . . 59 Chapter 8. Installation using VM - IPL from tape 75
Getting a new kernel appropriate to your needs . . 59 Creating the VM guest user ID . . . . . . . . 76
Preparing for IPL from DASD . . . . . . . . 59 DASDs . . . . . . . . . . . . . . . 76
IPL-ing from DASD . . . . . . . . . . . 60 Network connection . . . . . . . . . . 76
Hints, Tips, and Troubleshooting: . . . . . . . 61 User directory . . . . . . . . . . . . 77
What are the corresponding device names to my Checking the CMSUSER profile . . . . . . . 77
DASD devnos? . . . . . . . . . . . . 61 Assigning an IP address to the VM guest user ID. . 77
Some devices are not detected by LINUX for Preparing the VM guest user profile . . . . . . 77
S/390 . . . . . . . . . . . . . . . 61 Copying the IPL files to the VM host . . . . . . 78
The hardware console ″hangs″ . . . . . . . 61 Building a parameter line. . . . . . . . . . 79
No messages on system console during IPL . . 61 Preparing the tape for IPL . . . . . . . . . 79
Copying the IPL files to the tape . . . . . . . 80
Chapter 7. Installation using VM - IPL from the Using ditto to copy the files . . . . . . . . 80
VM reader . . . . . . . . . . . . . . 63 Using filedef to copy the files . . . . . . . 82
Creating the VM guest user ID . . . . . . . . 64 Ensuring you do not format the wrong devices . . 82
Minidisks . . . . . . . . . . . . . . 64 Checking the DASD devices . . . . . . . . 82
Network connection . . . . . . . . . . 65 Detaching unused DASD devices . . . . . . 82
User directory . . . . . . . . . . . . 65 IPL-ing from tape . . . . . . . . . . . . 82
Checking the CMSUSER profile . . . . . . . 65 Entering network information . . . . . . . . 83
Assigning an IP address to the VM guest user ID. . 66 Starting LINUX . . . . . . . . . . . . . 83
Preparing the VM guest user profile . . . . . . 66 Formatting the devices . . . . . . . . . . 84
Preparing minidisk B as a LINUX root file system 67 Creating a file system . . . . . . . . . . . 85
Transferring the LINUX boot files to minidisk A . . 67 Creating a swap device . . . . . . . . . . 85
Creating additional files . . . . . . . . . 68 Transferring the complete LINUX file system to
Files stored on minidisk A . . . . . . . . 68 LINUX for S/390 . . . . . . . . . . . . 85
Booting with LIN EXEC . . . . . . . . . . 70 Restoring file system from the archive . . . . . 86
Preparing the file system on your reserved minidisk 70 Preparing for IPL from DASD . . . . . . . . 86
Creating a swap space . . . . . . . . . . . 71 IPL-ing from DASD . . . . . . . . . . . 87
Activation of the swap space . . . . . . . 72
Editing the ’/mnt/etc/fstab’ file . . . . . . . 72 Chapter 9. Installing - Multiprise 3000 . . . . . 89
Finishing off . . . . . . . . . . . . . . 72 I/O settings . . . . . . . . . . . . . . 89
Re-booting with LIPL EXEC . . . . . . . . . 72
Emulating ’Ctrl’ character combinations . . . . . 73

Chapter 4. Installation - native single image and LPAR -
OS/390
This chapter describes how to install LINUX for S/390 on the native hardware or
LPAR. Installing LINUX for S/390 can be performed using other methods as
described in:
v “Chapter 5. Installation - native single image and LPAR - VM/ESA” on page 35
v “Chapter 6. Installation - native single image and LPAR - VSE/ESA” on page 49
v “Chapter 7. Installation using VM - IPL from the VM reader” on page 63 –
Installing LINUX for S/390 on VM, allowing the use of the VM/ESA features
v “Chapter 8. Installation using VM - IPL from tape” on page 75 – Installing
LINUX for S/390 on VM, allowing the use of the VM/ESA features
You can install LINUX for S/390 natively using any of the operating systems
OS/390, VSE/ESA, or VM/ESA as illustrated in Figure 2.
Figure 2. Installing on native S/390 or in an LPAR using OS/390, VM/ESA, or VSE/ESA
The tasks you need to perform when installing LINUX for S/390 natively are:
1. Choose the installation method, obtain information about your network
environment and the IPL method, and gain access to an S/390 operating
system suitable for building the IPL tape
2. Create the tape:
v Locate the LINUX for S/390 files and transfer them to a local system
On the operating system you have chosen to install LINUX for S/390 with
you will need to:
v Build a parameter line file
v Transfer the parameter line file and the LINUX for S/390 files to tape
3. Prepare your root file system for initial IPL
4. IPL from tape
5. Low-level format your hard disks and build file systems on them
6. Populate the new root file system
7. Customize the configuration files of the new file system
8. Get a new kernel appropriate to your needs
9. Prepare the new IPL medium

10. Re-IPL with root file system on DASD.
The IPL process is illustrated in Figure 3.
Figure 3. IPL process

v You are familiar with the OS/390 operating system
v You are aware of the hardware configuration and networking environment in
place on your system.
Preparing for installation

Make decisions about, get information on, and gain access to your system.
Choosing the installation method

You can install LINUX for S/390 on the native hardware or LPAR by mounting the
root file system from an initial RAM disk.
You should choose this method if you are not able to setup an NFS server or if you
only want to take a short look, or ″peek″, at LINUX for S/390. Mounting the root
file system from an NFS sever is simple in theory, but difficult to perform in
practice without introducing errors - because of this, it is not discussed in this
document.
Although network access is not required for the initial RAM disk installation
method, we recommend you attach your LINUX for S/390 to a network for
populating the file systems.
Obtaining information about your network environment

system, as there are:
v Network adaptor device number
v Host name
v IP-address
v Net mask
v Network-address
v Broadcast-address
v Default gateway address
Obtaining information about the IPL method

Make sure you have - at least temporary - access to a tape unit from your LINUX
for S/390 System. Make sure you know the devno of that tape unit.

Gaining access to OS/390
Get a user ID on OS/390 with a sort and merge utility installed, such as
IEBGENER. Make sure you have access to a tape unit that is compatible with the
tape unit you will use to IPL from at a later stage.
Creating the tape - overview

You need to create the tape to IPL from. To create the tape you need to:
1. Download the following files from the Internet
v The kernel image that is appropriate in your environment
v The image of the root file system that is appropriate in your environment
2. Build a parameter line file that is appropriate in your environment
3. Build an IPL-able tape that contains:
v The kernel image
v The parameter line file
v The image of the root file system
Figure 4. Creating the IPL tape
Locating the LINUX for S/390 files

You need to locate the following files, and download them to a local workstation
(UNIX or Windows NT):
v Kernel image file (for example, DRV11_smp_tape.img)
v Initial root file system (for example initrd)
Note that the initial RAMdisk file (initrd) is a compressed file that the kernel
will uncompress during IPL.
(Of course, you can also download directly to your S/390 system.)
Getting the image of the kernel

For building the tape, you should use the LINUX for S/390 kernel that is supplied
on the various LINUX for S/390 websites for a native installation. This kernel
might not be ideal for your environment, and later on you should build your own
kernel that is better suited to your specific needs. How to build your own kernel is
described in “Chapter 12. Building the kernel” on page 101.
Chapter 4. Installation - native single image and LPAR - OS/390 23

Using the supplied kernel
To use a supplied kernel, go to one of the LINUX for S/390 websites and find the
following file:
v DRV11_smp_tape.img
This kernel is configured for using an initial RAM disk as initial root file system.
It is a bootable image that loads an initial file system in RAMdisk (a virtual disk
in memory) referred to as initrd.
It is possible to compile your own kernel for IPL from tape, how to do this is
described in “Compiling for IPL from tape” on page 104.
Getting the image of the root file system for initial IPL
To create the initial root file system to be used for the initial IPL from RAM you
need this file:
v initrd
This is an image of the file system that you should rename to initrd.txt and
put on an initial RAMdisk. It is a compressed file that the kernel will
uncompress during IPL and is a maximum of 8 MB in size when it is
uncompressed.
Building the tape using OS/390

To finish building the tape you need to build a parameter line file that suits your
environment, and build the IPL-able tape.
Building a parameter line file on OS/390

To create a parameter line file on OS/390, allocate a 1 track sequential dataset,
record format F, LRECL 1024. Then edit the file using ISPF edit.
Here is an example of data set information for a parameter line file:

Data Set Name . . . : LINUX390.PARM.LINE
General Data Current Allocation
Volume serial . . . : SP3010 Allocated tracks . : 1
Device type . . . . : 3390 Allocated extents . : 1
Organization . . . : PS
Record format . . . : F
Record length . . . : 1024
Block size . . . . : 1024 Current Utilization
1st extent tracks . : 1 Used tracks . . . . : 1
Secondary tracks . : 1 Used extents . . . : 1
The contents of the parameter line file are:

Where:
v dasd=from-to|devno[,...]
from, to and devno are hexadecimal device numbers of the DASD devices that
you want to be used by LINUX for S/390. You may omit the dasd=...
statement, but in this case LINUX for S/390 will assume that you want to
dedicate all of your DASDs to LINUX. This might be dangerous if you have
disks, in particular the A-disk, which need to be accessed by another S/390
operating system when you are running under VM

v root=/dev/ram0 ro
This tells LINUX where to IPL from. This is a temporary RAMdisk (ram0) used
only to get a mini-LINUX system running so that you can perform the rest of
the IPL tasks. Use the root statement as given here when mounting the root file
system from initrd.
v If you have problems with your OSA-2 card after the IPL, you might want to
insert a delay to allow the card to settle down. The recommended delay time is
two minutes. The following entry should be used in the parm.line file:
ipldelay=xyz
where xyz is the delay period. For example, 30s means a delay of thirty seconds
between the IPL and the initialization of the OSA-2 card, 2m means a delay of
two minutes. The value xyz must be a number followed by either s or m.
Here is an example of the content of a parameter line file:

dasd=E0C0-E0C2 root=/dev/ram0 ro ipldelay=2m
Note that when IPL-ing from tape using an ASCII encoded parameter file which
you have generated on a UNIX or PC operating system, make sure that your parm
line contains no special characters (for example, tabs or new lines). In particular
your parameter file cannot span over more than one line and must not be larger
than 1023 Byte.
Building an IPL-able tape

Transfer the required files from the local workstation to the S/390 operating
system. Use a record size of 1024.
Using FTP on native OS/390

You can pre-allocate datasets on OS/390 and FTP to them. For example, allocate
LINUX390.IMAGE.TXT as:
v Organization PS
v Record Format F
v Record Length 1024
v Cylinder 3
Allocate LINUX390.INITRD.TXT as:
v Organization PS
v Record Format F
v Record Length 1024
v Cylinder 6
The parameter file was created as described in “Building a parameter line file on
OS/390” on page 24.
Then you can use FTP to get the files as follows:

ftp ftpserver
USER ftp
PASS yourname@youraddress
BIN
GET image.txt linux390.image.txt
GET initrd.txt linux390.initrd.txt
QUIT

Transferring the files to tape using OS/390
Transfer the required files to a tape using, for example, IEBGENER. Copy the files
in the following order:
1. kernel image
2. kernel parameter line
3. initial RAM disk.
Here is a sample job:

//LINUXIPL JOB (),
// CLASS=A,
// MSGCLASS=D,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID,
// TIME=1440
//TOTAPE PROC LBL=NOSUCH,FILE=NOSUCH.FILE
//IEBGNR EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=&FILE,DISP=OLD,
// DCB=(LRECL=1024,RECFM=F,BLKSIZE=1024)
//SYSUT2 DD LABEL=(&LBL,NL),DISP=OLD,
// UNIT=YOUR_UNIT_ID,
// VOL=(PRIVATE,RETAIN,SER=LINUX1)
//TOTAPE PEND
//*
//FILE1 EXEC TOTAPE,LBL=1,FILE=LINUX390.IMAGE.TXT
//FILE2 EXEC TOTAPE,LBL=2,FILE=LINUX390.PARM.LINE
//FILE3 EXEC TOTAPE,LBL=3,FILE=LINUX390.INITRD.TXT
//*
Preparing your root file system for initial IPL

If you have access to a LINUX system you are able to customize the configuration
files of the root file system before using it:
1. Make a backup copy of the downloaded file
2. Uncompress the downloaded file, for example initrd (note that there is no file
extension shown for this file). A compressed file is required because of memory
limitations, and because certain download methods can automatically
uncompress a .gz file during transfer, the extension is removed. The
uncompression stage has an additional step to get the names correct:
mv initrd initrd.gz
gunzip initrd.gz
3. Set up a loopback device on the downloaded file by issuing
losetup /dev/loop<#> initrd
4. Mount the loopback device by issuing
mount -t ext2 /dev/loop<#> <mountpoint>
5. Change your working directory to the mountpoint and edit the following files
according to your requirements
v etc/fstab
Check that it contains at least the following two lines
/dev/ram0 / ext2 defaults 0 1
none /proc proc defaults 0 0
v The initrd comes with a network setup script that asks for you network
configuration every time you boot (refer to “netsetup” on page 157). If you

don’t want to re-enter the network configuration every time then you have to
delete the link /etc/rc.d/rc3.d/S00netsetup and setup the following files:
etc/sysconfig/network and etc/resolv.conf
Adapt them according to your network environment
etc/sysconfig/network-scripts/ifcfg-<netdevice>
Adapt it according to your network environment.
6. Unmount the loopback device by issuing
umount /dev/loop<#>
7. Detach the loopback device by issuing
losetup -d /dev/loop<#>
8. Compress the file, (initrd) and rename it:
gzip initrd
mv initrd.gz initrd
IPL-ing from tape

To IPL from tape:
1. If it is not already connected, attach your IPL tape unit to your S/390 hardware
system.
2. Mount the tape cartridge to the tape unit that you intend to IPL from.
3. Get access to the service element, select the image you want to IPL and
perform a load from the device number of your IPL tape unit.
Your hardware console may ″hang″ if it receives too many messages. Use the
Delete button to enable further output.
Check the operating system messages of your system, which should appear on
your system console. Check that LINUX for S/390 boots properly. You will be
prompted for your network information as described in “Obtaining information
about your network environment” on page 22. If the LINUX system boots
properly, you will be prompted for your password.
4. When prompted for a password, log into your system using the
default_root_password pass4root.
5. Issue the ifconfig and route -n commands to verify that your system has set
up the network properly.
If the network is incorrectly set up, manually issue the ifconfig commands:
ifconfig <net-device> <your IP> netmask <netmask> broadcast <broadcastIP> up
route add default gw <gateway>
Check the network settings again. If they are still incorrect, your network
device has probably not been detected by LINUX for S/390.
Check for common problems in section “Hints, Tips, and Troubleshooting:” on

page 32.
Logging into your system and testing it

To test your system:
1. Start a standard Telnet session to your system (do not use tn3270).
2. Log-in to your system using root user ID and the default_root_password
pass4root.

3. Have a look into /proc and check for the information in different files:
cat /proc/dasd/devices
cat /proc/cpuinfo
cat /proc/meminfo
4. Check for the capacity of your file systems:
df
If you only wanted to have a ″peek″ at LINUX for S/390, you are finished now. If
you proceed, you will make permanent changes to your system.
Formatting the DASDs

If you want to use an ECKD type DASD as hard disk, you first have to low-level
format it using the dasdfmt utility (see “dasdfmt” on page 161). This can take quite
a long time depending on the size of the hard disk – always wait for the prompt to
reappear before entering further commands:
1. On all devices /dev/dasd? you want to access by LINUX for S/390 (″?″ is a
wildcard character), issue:
dasdfmt -b 4096 -f /dev/dasd<letter>
The <dasd letter> can be found in the file /proc/dasd/devices.
This will erase any information on that device including the label area, VTOC,
and so on. The device name corresponding to your DASD device number is
specified in your parameter line (see “Hints, Tips, and Troubleshooting:” on
page 32).
2. If the device node for the DASD device is missing (in /dev), create it by
issuing:
mknod <devicenodename> b 94 <minor_number>
Where (94) is the dasd device number and the minor number is found in the
file /proc/dasd/devices.
3. Create a file system on the disks using the mke2fs utility. Note that you should
only do this for volumes that are not to be used as full volume swapfiles. On
all devices you have low-level formatted and want LINUX for S/390 to use,
issue:
mke2fs -b 4096 /dev/dasd<letter>1
Ensure you do not build the file system on the whole device
/dev/dasd<letter> but on the logical device /dev/dasd<letter>1. This ensures
that you do not overwrite the label area and IPL records. The IPL records are
added at a later stage by the silo utility.

Preparing to transfer your root file system
You mounted your initial root file system from initrd (renamed as initrd.txt).
This was a small file system only used to allow you to IPL from tape. You will
now need to get a more complete file system for the DASD. Sample root files
systems, such as initfs_small.tgz or initfs_big.tgz are available on the LINUX
for S/390 websites. Get one of the following files:
v initfs_small.tgz or initfs_big.tgz
These are compressed tar-archives of a root file system which can be used to
populate your ’new’ root file system, see “Populating the new root file system
on DASD”. The ″size″ of the file relates to the number of utilities and
applications included in the archive. The small file is around 40 MB, and the
large around 120 MB. Refer to “Chapter 21. File system .tar file contents” on
page 163.
You can transfer these files by either using FTP or by copying them into an
NFS-mounted directory.
Populating the new root file system on DASD

Choose one of the prepared DASDs to contain your new root file system. To create
the root file system:
1. Define the mount point:
mkdir /mnt/dasda
2. Mount the DASD to /mnt/dasda:
mount /dev/dasd<letter>1 /mnt/dasda
3. Copy (for example, the small file system archive) to your LINUX for S/390
system using FTP, RCP or (again) CP commands from an NFS mounted
directory. Unpack it in /mnt/dasda using the following command after you
changed the working directory to /mnt/dasda:
tar xfzBp initfs_small.tgz
Note you need approximately 160 MB to uncompress the small file system and 510
MB for the larger file system. You can regain about 40 MB or 120 MB respectively
by removing the tar file after you have uncompressed it.
Creating a swap file or device

Create a swap space to be used for file transfer during installation. You may want
to use a complete volume for your swap space or just a dedicated swap file. Note
that there is a limit of 2 GB on the size of the swap space. If your disk volume is
larger than 2 GB, you must use a smaller disk, or create a swap file of appropriate
size on an existing file system. Note that creating a small swap space on a large
disk makes the remainder of the disk inaccessible.
Using a complete volume as swap space

Create a swap device for LINUX. For example, you can use Telnet on a
UNIX/Windows NT workstation to create the swap device and then create paging
to transfer the files:
[root@your_host /]# mkswap /dev/dasdb1
[root@your_host /]# chmod 600 /dev/dasdb1
[root@your_host /]# swapon /dev/dasdb1

Using a file as swap space
Create a swap file on a file system (make sure there is enough space for the swap
file on that file system). For example, use the following commands to generate the
swap file (you must be the root user to do this). Create the file:
dd if=/dev/zero of=<swap_file_path_and_name> bs=<blocksize> count=<number_of_blocks>
For example:
dd if=/dev/zero of=/mnt/dasda/swapfile bs=1M count=128
Turn the file into a swap file:

mkswap -c <swap_file_path_and_name>
For example:
/sbin/mkswap -c /mnt/dasda/swapfile
Set the right permission bits:

chmod 600 <swap_file_path_and_name>
For example:
chmod 600 /mnt/dasda/swapfile
Set up the swap space:

swapon <swap_file_path_and_name>
For example:
swapon /mnt/dasda/swapfile
Check the information about the newly created swap space:

cat /proc/swaps
Activating the swap space

In both cases, the swapon command is used for the initial activation of the swap
space. An entry in the etc/fstab file will activate the swap space on a subsequent
IPL. Refer to “Customizing the configuration files of the new file system” for an
example.
Customizing the configuration files of the new file system

Change your working directory to /mnt/dasda and customize the following files
according to your environment:
v etc/fstab
it should contain at least the following lines
/dev/dasd<letter>1 / ext2 defaults 0 1
<swap space> swap swap defaults 0 0
Note that the <swap space> is the name of the volume or file you created earlier.
For example /dev/dasd<letter>1 or /mnt/dasda/swapfile.
v etc/sysconfig/network and etc/resolv.conf
v etc/sysconfig/network-scripts/ifcfg-<netdevice>

The initfs_small.tgz or initfs_big.tgz file system archives include the same
network setup script used with the initrd initial root file system (that you
renamed as initrd.txt). The ″archive″ setup script will only ask for the network
configuration on the first boot and then, on subsequent boots, it will use the
information that has been stored to the disk. However, if you do not want to enter
the network configuration using the netsetup script (see “netsetup” on page 157),
then delete the link in /etc/rc.d/rc3.d/S00netsetup before you boot the first time
from the new file system.
Getting a new kernel appropriate to your needs

You would normally use the pre-compiled kernel available from the web site, but
optionally, if you require different kernel parameter values, you can build your
own kernel. You can build your new kernel either via cross-compile or natively
(see “Chapter 12. Building the kernel” on page 101).
Place this new kernel on the volume (DASD) that you intend to IPL from.
Preparing for IPL from DASD

To prepare for IPL from DASD:
1. Create a parameter file on the volume (/mnt/dasda/boot) that you intend to IPL
from. The parameter file should include the line:
dasd=from-to root=/dev/dasd<letter>1 ro noinitrd ipldelay=xyz
The dasd<letter>1 parameter used in our example is dasda. Note that this is
only an example and your parameter may be different.
Ensure that either the dasd=... parameter is the same as when booting the
initial kernel, or the device letter is adapted to the new order of DASD devices.
The noinitrd statement is required because the kernel was compiled with
initial RAM disk support enabled.
Remember that when IPL-ing from disk using an ASCII encoded parameter file
which you have generated on a UNIX or PC operating system, make sure that
your line contains no special characters (for example, tabs or new lines). In
particular your parameter file cannot span over more than one line and must
not be larger that 1023 Byte.
2. Write the boot record by using the silo command (see “silo” on page 159). You
can use the silo command in two ways:
v You can run it in a test-mode to see whether everything looks all right. To
test enter the silo command as follows:
[root@your_host /mnt/dasda/boot/]# ../sbin/silo -f <kernel> -d /dev/dasda
-p <parameter file> -b ipleckd.boot
A message will inform you about what the silo command would have done.
v You can run the command to really write the boot record. To do this add the
-t2 option to the silo command as follows:
-p <parameter file> -b ipleckd.boot -t2

Where, for example, /dev/dasda is the DASD that you want to IPL from and
ipleckd.boot contains the boot sector.
Make sure that the kernel image and the parameter file reside on the volume
(DASD) that you intend to IPL from.
3. Adapt the first fstab entry to the root device. fstab is located in
mnt/dasda/etc/fstab. For example:
/dev/dasda1 / ext2 defaults,errors=remount-ro 0 1
Note that the <swap space> is the name of the volume or file you created
earlier. For example /dev/dasdb1 or /mnt/dasda/swapfile.
IPL-ing from DASD

Issue a halt command to stop your LINUX for S/390 system. It is very important
to flush the buffer cache and to leave integral file systems on your disks. When
you see the message System halted you can re-IPL from your newly generated
DASD IPL by:
v Getting access to the service element, selecting the image you want to IPL and
performing a load from the device number of your DASD.
Your hardware console may ″hang″ if it receives too many messages. Use the
Delete button to enable further output.
your system console. Check that LINUX for S/390 boots properly. Unless you have
deleted the link to the netsetup script, you will be prompted for your network
information as described in “Obtaining information about your network
environment” on page 22. If the LINUX system boots properly, you will be
prompted for your password.
When prompted for a password, log into your system using the
Installation is complete!
Hints, Tips, and Troubleshooting:
What are the corresponding device names to my DASD

devnos?
When you issued the dasd=... boot parameter, the devices are sorted in order of
the supplied ranges. The range component of dasd=range is a from-to pair of
hexadecimal values that correspond to the device number of that DASD. The
DASD with the lowest from-to value is the first device, dasda. If a configured
device is not present, its device number is left blank.
If you do not include the parameter, the DASDs are not made available to LINUX
for S/390 and a log message is written.
If you specify dasd=autodetect, all recognized DASD devices are ordered by

subchannel number.

The device names start with /dev/dasda and continue with the last letter being
incremented for each device.
You can also inspect the /proc/dasd/devices file to find out the DASD minor
number (dasd<letter>).
Refer to “DASD” on page 135 for a full description of the DASD device driver.
Some devices are not detected by LINUX for S/390

Make sure the device types and models are known by LINUX for S/390.
The hardware console ″hangs″

In the native or LPAR environment, the hardware console can sometimes ″hang″
because it receives too many messages. The solution is to use the Delete button of
the GUI on the Service Element or Hardware Management Console to enable
further output. Refer to “Hardware console” on page 147 for more information.
No messages on system console during IPL

In the native or LPAR environment, the IPL process can appear to ″hang″ with no
messages displayed on the Service Element System Messages console. This does
not always mean that there is a problem with your tape, or the files contained on
it. At an early stage in the IPL process, the machine environment is checked and if
there are any conflicts in device usage, or a device fails to respond due to it being
hardware reserved, the IPL process can ″hang″. Other, similar, conflicts can occur
and you should remember to ensure there are no problems with your environment,
as well as checking the IPL tape and files, if the IPL process does not appear to
talk to the terminal.

VM/ESA
LPAR. It can also be used for installing on a virtual machine under VM/ESA
without exploiting features of VM/ESA. Installing LINUX for S/390 can be
performed using other methods as described in:
v “Chapter 4. Installation - native single image and LPAR - OS/390” on page 21
2. Create the tape:
you will need to:
4. IPL from tape


v You are familiar with VM/ESA


document.

v Host name
v IP-address
v Net mask
v Network-address
v Broadcast-address

Gaining access to VM/ESA

Get a user ID on VM/ESA with a sort and merge utility installed, such as
DITTO/ESA. Make sure you have access to a tape unit that is compatible with the
tape unit you will use to IPL from at a later stage.
Creating the tape - overview

You need to create the tape to IPL from. To create the tape you need to:
1. Download the following files from the Internet
v The kernel image that is appropriate in your environment
v The image of the root file system that is appropriate in your environment
2. Build a parameter line file that is appropriate in your environment
3. Build an IPL-able tape that contains:
v The kernel image
v The parameter line file
v The image of the root file system
Figure 7. Creating the IPL tape

You need to locate the following files, and download them to a local workstation
(UNIX or Windows NT):
(Of course, you can also download directly to your S/390 system.)

Chapter 5. Installation - native single image and LPAR - VM/ESA 37

Using the supplied kernel

To use a supplied kernel, go to one of the LINUX for S/390 websites and find the
following file:
need this file:
v initrd
This is an image of the file system that you should rename to initrd.txt and
put on an initial RAM disk. It is a compressed file that the kernel uncompresses
during IPL and is a maximum of 8 MB in size when it is uncompressed.
Building the tape using VM/ESA

To finish building the tape you need to build a parameter line file that suits your
environment, and build the IPL-able tape.
Building a parameter line using VM/ESA

The parameter line file parm.line can be built in VM. Alternatively, you can run
LINUX on another device (for example an Intel PC) and then transfer parm.line as
a binary file to your current environment.
You can create the parameter file in EBCDIC format on a VM system or by using
LINUX. In both cases, the contents of the file are the same.

Where:
where from, to and devno are hexadecimal device numbers of the DASD devices
that you want to be used by LINUX for S/390. You may omit the dasd=...
v root=/dev/ram0 ro
system from initrd.

ipldelay=xyz

than 1023 Byte.
Building an IPL-able tape

Transfer the required files from the local workstation to the S/390 operating
system. Use a record size of 1024.
Using FTP on VM/ESA

For example using FTP under VM/ESA you would issue the following commands:
ftp ftpserver
USER ftp
PASS yourname@youraddress
BIN
LOCSITE FIX 1024
GET DRV11_smp_tape.img image.txt
GET initrd initrd.txt
QUIT
Transferring the files to tape

Transfer the required files to a tape using, for example, the file copy function of
DITTO/ESA, do not use BACKUP/RESTORE.
To use DITTO/ESA, in a VM/ESA session:

1. Enter DITTO
2. Enter function code 7 for copying data.
3. Enter function code 4 for copying from a CMS file.
4. Enter function code 1 for copying to tape.
5. Press Enter.
This is illustrated in Figure 8 on page 40.

Figure 8. Using DITTO/ESA on VM/ESA
Use the DITTO/ESA data entry window (shown in Figure 9) to copy the three files
one at a time in the following order:
1. Kernel image
2. Parameter line file
3. Initial root file system (RAM disk) file
Figure 9. Using DITTO/ESA to copy files to tape.
If you are certain that you do not want to supply a parameter line, you must write
a tape mark to the tape instead.
Note that you do not have to uncompress the initial RAM disk file (initrd that
you renamed initrd.txt) because the kernel will detect the compressed file and
uncompress it during IPL.

mv initrd initrd.gz
gunzip initrd.gz
v etc/fstab
umount /dev/loop<#>
gzip initrd
mv initrd.gz initrd
IPL-ing from tape

To IPL from tape:
system.
3. Perform the command:
#CP IPL <devno>
Where devno is the device number of your IPL tape unit.

Check the operating system messages of your system, which - under VM -
appear on your system console. Check that LINUX for S/390 boots properly.
You will be prompted for your network information as described in “Obtaining
information about your network environment” on page 36. If the LINUX system
boots properly, you will be prompted for your password.

page 47.

pass4root.
cat /proc/cpuinfo
cat /proc/meminfo
df

page 47).
issuing:

issue:

page 163.

mkdir /mnt/dasda




For example:

For example:

For example:

For example:

cat /proc/swaps

IPL. Refer to “Customizing the configuration files of the new file system” on
page 45 for an example.

v etc/fstab




IPL-ing from DASD

DASD IPL using the following commands on the console:
#CP IPL <devno> clear
Where devno is the device number of your DASD.
Check the operating system messages of your system, which - under VM - appear
on your system console. Check that LINUX for S/390 boots properly. Unless you
have deleted the link to the netsetup script, you will be prompted for your
network information as described in “Obtaining information about your network


devnos?

subchannel number.




VSE/ESA
LPAR. Installing LINUX for S/390 can be performed using other methods as
described in:
2. Create the tape:
you will need to:
4. IPL from tape


v You are familiar with VSE/ESA


document.

v Host name
v IP-address
v Net mask
v Network-address
v Broadcast-address


Gaining access to VSE/ESA
Get a user ID on VSE/ESA. Make sure you have access to a tape unit that is
compatible with the tape unit you will use to IPL from at a later stage.
Building the tape using VSE/ESA

You need to create the tape to IPL from. For example, create the following VSAM
files in VSE USERCAT (VSESPUC) using the following jobs:
v VSAMCR - creates LINUX.IMAGE.FILE (IMAGE) and LINUX.INITRD.TXT (INITRD)
v CREAVSAM - creates LINUX.PARM.FILE (PARMLIN) and writes IPL information into
file
v FTPJOB - transmits Data from LINUX server and writes them to IMAGE and
INITRD files
v DITTOTAV - creates IPL tape
Creating the image and initrd files on VSE/ESA (VSAMCR)

You can pre-allocate datasets on VSE/ESA and FTP to them. For example, use the
following job to create the kernel, LINUX.IMAGE.FILE (IMAGE) and initial RAMdisk,
LINUX.INITRD.TXT (INITRD):
* $$ JOB JNM=LINUX,CLASS=0,DISP=D,NTFY=YES
// JOB LINUX DEFINE FILES
// EXEC IDCAMS,SIZE=AUTO
DEFINE CLUSTER ( -
NAME (LINUX.IMAGE.FILE ) -
CYLINDERS(3 3 ) -
SHAREOPTIONS (1) -
RECORDSIZE (1024 1024 ) -
VOLUMES (DOSRES SYSWK1 ) -
NOREUSE -
NONINDEXED -
FREESPACE (15 7) -
COMPRESSED -
TO (99366 )) -
DATA (NAME (LINUX.IMAGE.FILE.@D@ ) -
CONTROLINTERVALSIZE (8192 )) -
CATALOG (VSESP.USER.CATALOG )
DEFINE CLUSTER ( -
NAME (LINUX.INITRD.TXT ) -
CYLINDERS(6 6 ) -
SHAREOPTIONS (1) -
VOLUMES (DOSRES SYSWK1 ) -
NOREUSE -
NONINDEXED -
FREESPACE (15 7) -
COMPRESSED -
TO (99366 )) -
DATA (NAME (LINUX.INITRD.TXT.@D@ ) -
IF LASTCC NE 0 THEN CANCEL JOB
/*
// OPTION STDLABEL=ADD
// DLBL IMAGE,'LINUX.IMAGE.FILE',,VSAM, X
CAT=VSESPUC
// DLBL INITRD,'LINUX.INITRD.TXT',,VSAM, X
CAT=VSESPUC
/*
// EXEC IESVCLUP,SIZE=AUTO
A LINUX.IMAGE.FILE IMAGE VSESPUC
Chapter 6. Installation - native single image and LPAR - VSE/ESA 51

A LINUX.INITRD.TXT INITRD VSESPUC
/*
/&
* $$ EOJ
Creating a parameter line file on VSE/ESA (CREAVSAM)

You can create LINUX.PARM.FILE (PARMLIN) and write IPL information into the file.
For example, use the following job to create a parameter line file and write the IPL
information in the file:
* $$ JOB JNM=LINUXVSA,CLASS=0,DISP=D,NTFY=YES
// JOB SYSA DEFINE FILE
// EXEC IDCAMS,SIZE=AUTO
DEFINE CLUSTER ( -
NAME (LINUX.PARM.FILE ) -
CYLINDERS(2 2 ) -
SHAREOPTIONS (3) -
VOLUMES (DOSRES ) -
REUSE -
NONINDEXED -
FREESPACE (15 7) -
NOCOMPRESSED -
TO (99366 )) -
DATA (NAME (LINUX.PARM.FILE.@D@ ) -
IF LASTCC NE 0 THEN CANCEL JOB
/*
// OPTION STDLABEL=ADD
// DLBL PARMLIN,'LINUX.PARM.FILE',,VSAM, X
CAT=VSESPUC
/*
// EXEC IESVCLUP,SIZE=AUTO
A LINUX.PARM.FILE PARMLIN VSESPUC
/*
// UPSI 1
// EXEC DITTO
$$DITTO CVS BLKFACTOR=1,FILEOUT=PARMLIN,CISIZE=1024
ANEXIT 'dasd=192-197 root=/dev/ram0 ro'
$$/*
$$DITTO EOJ
/*
/&
* $$ EOJ

Where:
from, to and devno are hexadecimal device numbers of the DASD devices that
you want to be used by LINUX for S/390. You may omit the dasd=...

v root=/dev/ram0 ro
system from initrd.
ipldelay=xyz

dasd=192-197 root=/dev/ram0 ro
than 1023 Byte.

You need to locate the following files:

Using the supplied kernel: To use a supplied kernel, go to one of the LINUX for
S/390 websites and find the following file:

need this file:
v initrd
This is an image of the file system that you should use to create an initial RAM
disk. It is a compressed file that the kernel uncompresses during IPL and is a
maximum of 8 MB in size when it is uncompressed.
Using FTP to get the kernel and initial RAMdisk files (FTPJOB)
Copy the kernel image and the RAMdisk files to the IMAGE and INITRD files you
created earlier. For example, use the following job to FTP the files:
* $$ JOB JNM=getfiles,CLASS=0,DISP=D,NTFY=YES
// JOB getfiles ftp FILES
// DLBL IMAGE,'LINUX.IMAGE.FILE',,VSAM, X
CAT=VSESPUC
// DLBL INITRD,'LINUX.INITRD.TXT',,VSAM, X
CAT=VSESPUC
// EXEC FTP,PARM='IP=<ip_address_of_download_site>,PORT=21,ID=00'
<your_user_id>
<your_password>e
<iccf_user_id>
<iccf_password> BINARY
cd <to_the_download_site>
GET image.vm.bin FILE
GET initrd.bin TXT
QUIT
/*
/&
* $$ EOJ
Building an IPL-able tape (DITTOTAV)

Transfer the required files to a tape using, for example, the file copy function of
DITTO/ESA, do not use BACKUP/RESTORE. Copy the files in the following
order:
1. kernel image
2. kernel parameter line
3. initial RAM disk.
For example, use the following job to build the tape:
* $$ JOB JNM=DITTO,CLASS=A,DISP=D
// JOB DITTO TO CREATE IPL-ABLE LINUX TAPE
// ASSGN SYS006,640 (CUU = TAPE UNIT ID)
// DLBL IMAGE,'LINUX.IMAGE.FILE',,VSAM,CAT=VSESPUC,DISP=(OLD,KEEP)
// DLBL INITRD,'LINUX.INITRD.TXT',,VSAM,CAT=VSESPUC,DISP=(OLD,KEEP)
// DLBL PARMLIN,'LINUX.PARM.FILE',,VSAM,CAT=VSESPUC,DISP=(OLD,KEEP)
// LIBDEF *,SEARCH=PRD1.BASE
// UPSI 1
// EXEC DITTO
$$DITTO REW OUTPUT=SYS006
$$DITTO WTM OUTPUT=SYS006,NTMKS=5
$$DITTO REW OUTPUT=SYS006
$$DITTO VTP FILEIN=IMAGE,OUTPUT=SYS006
$$DITTO VTP FILEIN=PARMLIN,OUTPUT=SYS006
$$DITTO VTP FILEIN=INITRD,OUTPUT=SYS006
$$DITTO EOJ
/*
/&
* $$ EOJ

mv initrd initrd.gz
gunzip initrd.gz
v etc/fstab
umount /dev/loop<#>
gzip initrd
mv initrd.gz initrd
IPL-ing from tape

To IPL from tape:
system.
3. On the hardware console or on the LPAR, enter:
IPL devno
Where devno is the device number of your IPL tape unit.

your system console. Check that LINUX for S/390 boots properly. You will be
prompted for your network information as described in “Obtaining information
about your network environment” on page 50. If the LINUX system boots
properly, you will be prompted for your password.

page 61.

pass4root.
cat /proc/cpuinfo
cat /proc/meminfo
df

page 61).
issuing:

issue:

page 163.

mkdir /mnt/dasda




For example:

For example:

For example:

For example:

cat /proc/swaps

IPL. Refer to “Customizing the configuration files of the new file system” on
page 59 for an example.

v etc/fstab




IPL-ing from DASD

DASD IPL using the following commands:
v On the hardware console or on the LPAR, enter:
IPL devno
Where devno is the device number of your DASD.
your system console. Check that LINUX for S/390 boots properly. Unless you have
deleted the link to the netsetup script, you will be prompted for your network
information as described in “Obtaining information about your network


devnos?

subchannel number.




Chapter 7. Installation using VM - IPL from the VM reader
This chapter describes how to install LINUX for S/390 on a Virtual Machine (VM)
S/390 by performing the IPL using the VM reader as the IPL medium and CMS
minidisk for the file system storage. Installing LINUX for S/390 can be performed
using other methods as described in:
v “Chapter 8. Installation using VM - IPL from tape” on page 75
The following text consists of instructions followed by example output listings.

Within the listings, user input is identified by bold monospaced typeface.
The tasks performed when installing LINUX for S/390 on a VM system fall into
four categories:
v Initial activities: Creating a VM guest user ID: Checking the CMSUSER profile
v Setting up LINUX for S/390 on VM: Preparing the user profile: Preparing the
minidisks: Transferring the LINUX boot files
v Booting the system: Creating a LINUX file system: Creating a swap space
v Post-installation tasks: Starting and stopping the system.
Figure 12. IPL process - VM Reader

v Your S/390 system has a TCP/IP connection
v VM is installed and running on your S/390 system
v You know how to use the console connected to your S/390 system
v You are familiar with VM
v You know how to edit a CMS file and enter CP, CMS commands
v If you want to use the IEEE hardware FPU, ensure you have APARs VM62337
and VM62410 installed before bringing up LINUX under VM. Anyone IPL-ing
LINUX under VM/ESA V2R3.0 will need VM61762, too. It already exists in the
2.4.0 base.
v If you want to use TCP/IP for VM/ESA, it is recommended that you install
APAR PQ34318.

v If you are using OSA SF, make sure that you have mapped the IP address
assigned to your VM user ID to the two channels that are used by the OSA-2
card that you intend to dedicate to your LINUX VM guest.
Creating the VM guest user ID

Ask your VM system administrator to create a VM guest user ID or to change your
existing user ID to satisfy the following requirements. Your user ID needs access
to:
v Two read/write-minidisks
v Two dedicated device addresses allocated for one network connection
Note that if you use an existing VM guest user ID, you can perform operations
that remove all data from your user ID!
Minidisks
You need to allocate space for the LINUX for S/390 files (kernel, parameters, etc.)
on a CMS-formatted disk. This can be a new disk or you can use some free space
on a normal CMS disk where you already have read/write-access. This disk is
used to store the files before they are placed in the VM reader. You also need a
separate VM-minidisk for the LINUX for S/390 root file system. This lets you IPL
with your root file system on the minidisk. If you are installing a full system, you
need a part of this second minidisk for the swap space. Note that there is a limit of
2 GB on the size of the swap space.
Assuming that the disk drives are IBM 3390s, the minidisk sizes you require are:
v Small system: 100 cylinders for the LINUX for S/390 files and 200 cylinders for
the LINUX for S/390 file system
v Full system: 200 cylinders for the LINUX for S/390 files, and approximately 1000
cylinders for the LINUX for S/390 file system. The swap space will require an
additional 200 cylinders (of the second minidisk).
The following description assumes that you are installing the simple system, that
have a new LINUX for S/390 user ID, that the minidisk used for the LINUX for
S/390 files is device 191, and the one used for the file system is device 192. Ask
your VM system administrator to assign these devices to your VM guest user ID.
The minidisks in the examples are assigned as minidisk a and minidisk b.
Note that the initial tasks of setting up the user directory, checking the CMSUSER
profile, and preparing the VM guest user profile also apply to the installation of a
full system. Refer to “Chapter 8. Installation using VM - IPL from tape” on page 75
for a description of installing a full system under VM using tape for IPL and
DASD for the file system storage.
Note also that the description used in this chapter uses the VM minidisk device
driver.Note that, because minidisks are used for installation in this chapter, the
description also uses the minidisk device driver. You can also use the DASD
device driver to register your minidisks:
v If you have old minidisks, or want to install more than 255 logical volumes,
you must use this driver.
v If however, you have newer minidisks and require less than 255 logical
volumes, you can use the DASD device driver.

You can also install LINUX for S/390 using the reader for IPL and DASDs for
the file system storage. In this case you would use the DASD device driver. Be
aware that you can encounter problems using the incorrect driver.
Network connection
To run LINUX for S/390 with a network connection you need to define a network
device. This can be either:
v One port of an OSA-2 card (Token Ring or Ethernet)
v A port of a CTC/ESCON card
v A virtual CTC device.
If you are using CTC you have to set up your system connections to correctly
handle the TCP/IP-traffic. Refer to the CTC/ESCON device driver description for
more details.
Your network device has two addresses (send and receive). Ask your VM system
administrator to dedicate these addresses to your VM guest user ID.
User directory
The statements in your user directory should match the following example:
USER MYLINUX password 128M 256M G
*---------------------------------------------------------------------*
INCLUDE CMSUSER
CPU 0 CPUID 100003 NODEDICATE
MACHINE ESA 2
DEDICATE 7800 7800
DEDICATE 7801 7801
MDISK 0191 3390 1501 100 LNXU01 MR Rpassword Wpassword Mpassword
MDISK 0192 3390 1601 200 LNXU01 MR Rpassword Wpassword Mpassword
OPTION QUICKDSP
An explanation of the directory entries:

v The CPU statements (and the number after the MACHINE ESA statement) are only
needed if you are running with SMP
v The numbers after the DEDICATE statements are the device addresses of the
network device
v The MDISK statements specify the two IBM 3390 minidisks (the values would be
different and there would be a third minidisk statement if you were installing
the full system)
v The OPTION QUICKDSP statement prevents the console hanging in certain
circumstances.
Checking the CMSUSER profile

Ensure that your CMSUSER profile looks similar to the following:
PROFILE CMSUSER
*---------------------------------------------------------------------*
IPL CMS
MACH ESA
CONSOLE 0009 3215 T
SPOOL 000C 2540 READER A
SPOOL 000D 2540 PUNCH A
SPOOL 000E 1403 A
LINK MAINT 0190 0190 RR
LINK MAINT 019D 019D RR
LINK MAINT 019E 019E RR
Chapter 7. Installation using VM - IPL from the VM reader 65

Note that the locations of the VM reader (SPOOL 000C 2540 READER A), punch
(SPOOL 000D 2540 PUNCH A), and printer (SPOOL 000E 1403 A) are defined in this
profile.
At this point, the initial tasks have been completed and you are ready to set up
your system. However, your VM administrator has to assign an IP address to your
VM guest user ID. Therefore it is a good idea to keep a note of the details that
have just been defined.
Assigning an IP address to the VM guest user ID

After you have completed your tasks, you need to assign an IP address to your
VM user ID. Ask your VM system administrator to do this, or refer to the VM user
guide for instructions.
Preparing the VM guest user profile

Launch a PComm session via TCP/IP or use any 3270 terminal emulator to
connect to your VM system.
Log-on to your VM guest user ID on your VM host and then prepare your user
profile:
1. Define a minimum storage area on the VM guest memory that is suitable for
your needs (a reasonable memory size is 128MB) by using the command
DEFINE STORAGE 128M
2. Link to a VM TCP/IP disk to be used for the VM client, and then access that
device. For example:
link <disk name> <disk address> <virtual address> RR
access <virtual address> <free file mode>
These steps can be performed automatically the next time you log-on by creating a
PROFILE EXEC file containing the commands as shown below. The file can be
updated at any time during a subsequent session, so you can add the three
commands later:
/* Program: PROFILE EXEC A */
/* Author : "your name" */
/* Version: 15.05.00 */
/* Changed: 15.05.00 by "your name" */
vmfclear /* vmfclears screen */
/* set fullscreen on*/
say "***********************************************"
SAY "* WELCOME TO USER "MYLINUX" AT "123ABCD" *"
say "***********************************************"
SAY "SYSTEM-INFORMATION:"
indicate /* display system resources */
set msg on /* able to receive messages from users */
set emsg on /* error-messages are active */
set impcp on /* enable implicit cp commands under cms */
set run on /* */
SAY "ACTIVATE CP PARAMETERS"
DEFINE STORAGE 128M
cp term chardel off /* to use @ in internet addresses */
SAY "ACTIVATE ACCESS TO TOOLS/DISKS ETC."
link tcpip 198 198 RR /* link to the disk to be used for tcp/ip */
acc 198 Z /* access the disk to be used for tcp/ip */
exit /* ends program */

Preparing minidisk B as a LINUX root file system
Prepare the second minidisk as a LINUX root file system by using, for example,
the following CMS command:
format 192 b (blksize 4096
You can specify a block size of 512 bytes, 1KB, 2KB, or 4KB. The recommended
size is 4KB. Note that the blocksize used to format minidisk B must be the same as
used for the initfs_small.tgz or initfs_big.tgz file system archive.
The system responds with a confirmation request (enter 1 to proceed or 0 to reject

the disk format). You are then asked to enter a disk label (for example, enter
linux).
Use the reserve command to allocate all available blocks of a formatted CMS
minidisk to a unique CMS file:
reserve linux mdisk b
The system responds with a confirmation request (enter 1 to proceed or 0 to reject

the disk reservation).
Transferring the LINUX boot files to minidisk A
Figure 13. Using the VM Reader
You must locate the LINUX for S/390 boot files and transfer them to minidisk A.
The following commands show how to do this:
ftp 12.12.12.12
user=user ID
password=password
cd download directory
bin
locsite fix 80
get initrd.bin initrd.txt
get image.vm.bin vmlinux.txt
quit

An explanation of the process:
1. Use FTP to connect to the server where the kernel and RAMdisk files are
located.
2. Log-on with your user ID.
3. Enter your password.
4. Change directory to get to the download directory.
5. Set binary file transfer.
6. Fix the record length of the transferred files to 80 bytes.
7. Copy (and rename) the initrd.bin file to initrd.txt in your current location.
Note that the initial RAMdisk file (initrd.bin) is a compressed file that the
kernel will uncompress during IPL.
8. Copy (and rename) the kernel, image.vm.bin to vmlinux.txt in your current
location.
9. Then exit FTP.
Creating additional files

Create a VM file with the name LINUX PARM on minidisk a. Enter the following
commands in the file:
mdisk=192 root=/dev/ram0 ro
The first command describes the minidisk:

192 The device number (in hex) for minidisk b
The second command in the example describes the location of the root file system.
root=/dev/ram0 ro
The root file system is mounted on a RAMdisk in the directory /dev/ram0
and is defined as a read-only file system by using the command ro
Create the lin.exec, and lipl.exec files on minidisk a. Refer to “Files stored on
minidisk A” for the content of these files.
When IPL-ing from the vitual reader of VM/ESA, and your parameter file spans
more than one line, make sure that a blank character preceeds any kernel
parameter. To avoid errors you should start on column 2 of the parameter line.
Files stored on minidisk A

The following files should be stored on your A disk:
v VMLINUX TXT
v LIN EXEC
v LIPL EXEC
v INITRD TXT
v LINUX PARM
VMLINUX TXT
This is the LINUX boot file.

LIN EXEC
This REXX executable loads the kernel into the VM reader and also boots
the kernel from the reader. Check that the file has the following content:
/* */
'close rdr'
'purge rdr all'
'spool punch * rdr'
'PUNCH VMLINUX TXT A (NOH'
'PUNCH LINUX PARM A (NOH'
'PUNCH INITRD TXT A (NOH'
'ch rdr all keep nohold'
'i 00c'
An explanation of the commands:

/* */ Informs the system that the file is a REXX executable.
'close rdr'
Closes all open files in the reader so that they can be purged.
'purge rdr all'
Empties the VM reader. Note that this command empties the
reader. You should ensure that any important files have been
moved to another location before issuing this command!
'spool punch * rdr'
Moves the contents of the punch to the reader.
'PUNCH VMLINUX TXT A (NOH'
Moves the LINUX boot file to the reader.
'PUNCH LINUX PARM A (NOH'
Moves the LINUX parameters file to the reader.
'PUNCH INITRD TXT A (NOH'
Moves the initial RAMdisk file (initial root file system) to the
reader.
Makes sure the content of the reader is not changed or deleted
after the process is finished.
'i 00c'
Sends the reader an Initial Program Load (IPL) command — this
boots LINUX for S/390.
LIPL EXEC
The REXX executable is used to re-boot the kernel. It contains the
following commands:
/* */
'i 00c'
An explanation of the commands:

/* */ Informs the system that the file is a REXX executable.
Makes sure the content of the reader is not changed or deleted
after the process is finished.
'i 00c'
Sends the reader an IPL command — this re-boots LINUX for
S/390.

INITRD TXT
This is an initial RAMdisk file and is used as a root file system on initial
boot. Note that the initial RAMdisk file (initrd.bin that you renamed
initrd.txt) is a compressed file that the kernel will uncompress during
IPL.
Booting with LIN EXEC

The following commands must be entered in VM:
1. Enter LIN to run the LIN EXEC executable. This will use the CMS pun command
to put the kernel, the boot parameter, and the initial root file system (RAMdisk)
into the reader and then boot the kernel.
2. You are asked to specify your network environment.
Is your machine connected to a network (Yes/No) ? yes
Select the type of your network device
1) for osa token ring
2) for osa ethernet
3) for channel to channel
Enter your choice (1-3): 1
Please type in the options for the lcs module,
e.g. to select relative port 1 on device 0xfd00 you should enter:
noauto=1 devno_portno_pairs=0xfd00,1: your_lcs_module_parameter
Please enter your host name: your_host_name
Please enter your IP address: your_IP_address
Please enter the net mask: your_net_mask
Please enter the network address: your_network_address
Please enter the broadcast address: your_broadcast_address
Please enter the gateway address: your_gateway_address
Please enter the IP address of the DNS server: your_DNS_server_address
Please enter the DNS search domain: your_DNS_search_domain
The system responds with a summary of the information you have just entered
and asks you to confirm that the information is correct.
Note that the lcs module option is only required for network types
1) osa token ring or 2) osa ethernet
3. When the boot routine has completed, you must enter the default_root_password
pass4root to start LINUX for S/390 in maintenance mode.
The boot messages are not completely accurate for a LINUX for S/390
installation. You cannot enter Ctrl+D to launch LINUX for S/390 because of the
way in which the system is set up.
At a later stage, when your VM guest user ID has been assigned an IP address,
you issue commands to re-boot the system via Telnet.
4. To exit LINUX for S/390 and leave the system running, use the command
#cp disc.
Preparing the file system on your reserved minidisk

Format the LINUX file system on your reserved minidisk:
mke2fs /dev/mnda -b 4096
Mount the reserved minidisk:

mount /dev/mnda /mnt
Change to that directory:

cd /mnt

Locate the complete file system. There are two archive files, initfs_small.tgz or
initfs_big.tgz each containing a file system archive. Copy (for example) the small
file system archive to your reserved minidisk using FTP:
ftp 12.12.12.12
user=user ID
password=password
cd download directory
bin
locsite fix 4096
get initfs_small.tgz
quit
Unpack the archive using the command:

tar xzpBf initfs_small.tgz
Then delete the archive file and create a swap space.
Creating a swap space

Create a swap file on minidisk b (only required for the large file system). Note that
there is a limit of 2 GB on the size of the swap space. If your disk volume is larger
than 2 GB, you must use a smaller disk, or create a swap file of appropriate size
on an existing file system.
For example, use the following commands to generate the swap file (you must be
the root user to do this):
For example:
dd if=/dev/zero of=/mnt/swapfile bs=1M count=128

For example:
/sbin/mkswap -c /mnt/swapfile

For example:
chmod 600 swapfile
Set up the swap file:

For example:
swapon /mnt/swapfile
Check the information about the newly created swap file:

cat /proc/swaps

Activation of the swap space
The swapon command is used for the initial activation of the swap file. An entry in
the /etc/fstab file will activate the swap file on a subsequent IPL.
Editing the ’/mnt/etc/fstab’ file

The /mnt/etc/fstab file refers to DASD devices rather than minidisks. You must
edit the file to replace all occurrences of dasda1 with mnda.
Change to the correct directory:

cd /mnt/etc
Use the screen editor utility in LINUX (sed) to change dasda1 to mnda. Use a
temporary file to store the changes:
sed 's/dasda1/mnda/g' fstab > fstab2
Check that the changes are correct:

cat fstab2
Replace the contents of /mnt/etc/fstab file with the contents of the temporary file:
mv fstab2 fstab
Finishing off
Stop the running LINUX for S/390 system:
halt
The S/390 CPU enters a disabled wait state and (in VM) is in the CP environment.
To enter CMS commands, you must IPL CMS.
Using VM, change the values in your PARM LINE file to ensure that future IPL will
be from the minidisk:
mdisk=192 root=/dev/mnda ro noinitrd
Use lin.exec to re-boot the LINUX for S/390 system. Enter the command:
lin
Re-enter your network parameters (the same values as you entered before) see,
“Booting with LIN EXEC” on page 70.
At this point, you have finished your tasks, however, the VM administrator has to
complete the process of setting up the LINUX for S/390 system, see “Assigning an
IP address to the VM guest user ID” on page 66.
Re-booting with LIPL EXEC

If you ever want to re-boot LINUX for S/390, you can use the following
commands which must be entered in VM:
1. Enter LIPL to run the LIPL EXEC executable. This will re-boot the kernel.
2. When the re-boot routine has completed, you must enter the
default_root_password pass4root to start LINUX for S/390 in maintenance mode.

The boot messages are not completely accurate for a LINUX for S/390
installation. You cannot enter Ctrl+D to launch LINUX for S/390 because of the
way in which the system is set up.
At a later stage, when your VM guest user ID has been assigned an IP address,
you issue commands to re-boot the system via Telnet.
3. To exit LINUX for S/390 and leave the system running, use the command
#cp disc.
Emulating ’Ctrl’ character combinations

The 3215 terminal does not have a Ctrl key. That makes it impossible to enter
control characters directly. The character | in combination with certain other
characters can emulate the Ctrl key:
v |c is interpreted as a Ctrl+C
v |d is interpreted as a Ctrl+D
v |z is interpreted as a Ctrl+Z
v |n is used at the end of the input line (on the terminal) to prevent the generation
of a new line character.
Refer to the 3215 device driver description for more information.
Starting and stopping the system

Enter reboot on the console to re-start the system and halt to stop it.
Remember that, with the system halted, the S/390 CPU enters a disabled wait state
and (in VM) is in the CP environment. To enter CMS commands, you must IPL
CMS.
Remembering your password

The default_root_password is pass4root. For security reasons, it is a good idea to
change this password on the first log-in after installation. Use the passwd command
to change the default_root_password.
If, at a later time, you forget this new password, you can use the following method
to access the password file:
1. IPL from a temporary medium (for example, use the VM reader or the initial
boot tape) using the default_root_password
2. Mount the volume containing your root file system from your standard
installation
3. Access the password file on your standard installation and replace the
encrypted password (the one you forgot) by the encrypted password (the initial
one) from /etc/passwd (in your temporary root file system)
4. Exit the temporary IPL
5. IPL from the medium containing your standard root file system using the
default_root_password
6. Change your password.

Chapter 8. Installation using VM - IPL from tape
This chapter describes how to install LINUX for S/390 on a Virtual Machine (VM)
S/390 by performing the IPL using tape as the IPL medium and DASD for the file
system storage. Installing LINUX for S/390 can be performed using other methods
as described in:
v “Chapter 7. Installation using VM - IPL from the VM reader” on page 63
The following text consists of instructions followed by example output listings.

Within the listings, user input is identified by bold monospaced typeface.
The tasks performed when installing LINUX for S/390 on a VM system fall into
four categories:
v Initial activities: Creating a VM guest user ID: Checking the CMSUSER profile
v Setting up LINUX for S/390 on VM: Preparing the user profile: Preparing the
DASDs: Transferring the LINUX boot files
v Booting the system: Creating a LINUX file system: Creating a swap space
v Post-installation tasks: Starting and stopping the system.
Figure 14. IPL process - VM tape

v Your S/390 system has a TCP/IP connection
v VM is installed and running on your S/390 system
v You know how to use the console connected to your S/390 system
v You are familiar with VM
v You know how to edit a CMS file and enter CP, CMS commands
v If you want to use the IEEE hardware FPU, ensure you have APARs VM62337
and VM62410 installed before bringing up LINUX under VM. Anyone IPL-ing
LINUX under VM/ESA V2R3.0 will need VM61762, too. It already exists in the
2.4.0 base.
v If you want to use TCP/IP for VM/ESA, it is recommended that you install
APAR PQ34318.
v If you are using OSA SF, make sure that you have mapped the IP address
assigned to your VM user ID to the two channels that are used by the OSA-2
card that you intend to dedicate to your LINUX VM guest.

Creating the VM guest user ID
Ask your VM system administrator to create a VM guest user ID or to change your
existing user ID to satisfy the following requirements. Your user ID needs access
to:
v Two read/write-DASDs
v Two dedicated device addresses allocated for one network connection
Note that if you use an existing VM guest user ID, you can perform operations
that remove all data from your user ID!
DASDs
You need to allocate space for the LINUX for S/390 files (kernel, parameters, root
file system, etc.) on a DASD. This can be a new DASD or you can use some free
space on a normal DASD where you already have read/write-access. This lets you
IPL with your root file system on the DASD. If you are installing a full system, you
need a second DASD or part of the first DASD for the swap space. Note that there
is a limit of 2 GB on the size of the swap space.
Assuming that the disk drives are IBM 3390s, the DASD sizes you require are:
v Small system: 100 cylinders for the LINUX for S/390 files and 200 cylinders for
the LINUX for S/390 file system
v Full system: 200 cylinders for the LINUX for S/390 files, and approximately 1000
cylinders for the LINUX for S/390 file system. The swap space will require an
additional 200 cylinders.
The following description assumes that you are installing the full system, that you
have a new LINUX for S/390 user ID, that the DASD used for the LINUX for
S/390 files is dasda, and (if used) the one used for the swap space is dasdb. Ask
your VM system administrator to assign these devices to your VM guest user ID.
Note that the initial tasks of setting up the user directory, checking the CMSUSER
profile, and preparing the VM guest user profile also apply to the installation of a
small system. Refer to “Chapter 7. Installation using VM - IPL from the VM
reader” on page 63 for a description of installing a small system under VM using
the reader for IPL and minidisks for the file system storage.
Note that, because DASDs are used for installation in this chapter, the
description also uses the DASD device driver. You can also install LINUX for
S/390 using tape for IPL and minidisks for the file system storage:
v If you have old minidisks, or want to install more than 255 logical volumes,
you must use the minidisk driver.
v If however, you have newer minidisks and require less than 255 logical
volumes, you can use the DASD device driver.
Be aware that you can encounter problems using the incorrect driver.
Network connection
To run LINUX for S/390 with a network connection you need to define a network
device. This can be either:
v One port of an OSA-2 card (Token Ring or Ethernet)
v A port of a CTC/ESCON card
v A virtual CTC device.

If you are using CTC you have to set up your system connections to correctly
handle the TCP/IP-traffic. Refer to the CTC/ESCON device driver description for
more details.
Your network device has two addresses (send and receive). Ask your VM system
administrator to dedicate these addresses to your VM guest user ID.
User directory
The statements in your user directory should match the following example:
USER MYLINUX password 128M 256M G
*---------------------------------------------------------------------*
INCLUDE CMSUSER
MACHINE ESA 2
DEDICATE 7800 7800
DEDICATE 7801 7801
DASD 0191 3390 1501 100 LNXU01 MR Rpassword Wpassword Mpassword
DASD 0192 3390 1601 200 LNXU01 MR Rpassword Wpassword Mpassword
OPTION QUICKDSP
An explanation of the directory entries:

v The CPU statements (and the number after the MACHINE ESA statement) are only
needed if you are running with SMP
v The numbers after the DEDICATE statements are the device addresses of the
network device
v The DASD statements specify the two IBM 3390 DASDs
v The OPTION QUICKDSP statement prevents the console hanging in certain
circumstances.
Checking the CMSUSER profile

Ensure that your CMSUSER profile looks similar to the following:
PROFILE CMSUSER
*---------------------------------------------------------------------*
IPL CMS
MACH ESA
CONSOLE 0009 3215 T
LINK MAINT 0190 0190 RR
LINK MAINT 019D 019D RR
LINK MAINT 019E 019E RR
At this point, the initial tasks have been completed and you are ready to set up
your system. However, your VM administrator has to assign an IP address to your
VM guest user ID. Therefore it is a good idea to keep a note of the details that
have just been defined.
Assigning an IP address to the VM guest user ID

After you have completed your tasks, you need to assign an IP address to your
VM user ID. Ask your VM system administrator to do this, or refer to the VM user
guide for instructions.
Preparing the VM guest user profile

Launch a PComm session via TCP/IP or use any 3270 terminal emulator to
connect to your VM system.
Chapter 8. Installation using VM - IPL from tape 77

Log-on to your VM guest user ID on your VM host and then prepare your user
profile:
1. Define a minimum storage area on the VM guest memory that is suitable for
your needs (a reasonable memory size is 128MB) by using the command
DEFINE STORAGE 128M
2. Link to a VM TCP/IP disk to be used for the VM client, and then access that
device. For example:
link <disk name> <disk address> <virtual address> RR
access <virtual address> <free file mode>
These steps can be performed automatically the next time you log-on by creating a
PROFILE EXEC file containing the commands as shown below. The file can be
updated at any time during a subsequent session, so you can add the three
commands later:
/* Program: PROFILE EXEC A */
/* Author : "your name" */
/* Version: 15.05.00 */
/* Changed: 15.05.00 by "your name" */
vmfclear /* vmfclears screen */
/* set fullscreen on*/
say "***********************************************"
SAY "* WELCOME TO USER "MYLINUX" AT "123ABCD" *"
say "***********************************************"
SAY "SYSTEM-INFORMATION:"
indicate /* display system resources */
set msg on /* able to receive messages from users */
set emsg on /* error-messages are active */
set impcp on /* enable implicit cp commands under cms */
set run on /* */
SAY "ACTIVATE CP PARAMETERS"
DEFINE STORAGE 128M
cp term chardel off /* to use @ in internet addresses */
SAY "ACTIVATE ACCESS TO TOOLS/DISKS ETC."
link tcpip 198 198 RR /* link to the disk to be used for tcp/ip */
acc 198 Z /* access the disk to be used for tcp/ip */
exit /* ends program */
Copying the IPL files to the VM host

Operating under VM in your CMS-session, get the IPL files from your local
UNIX/Windows NT workstation. For example, use FTP:
ftp your_local_workstation
USER:
username
331 Password required for username.
Password: ********
230 User username logged in.
bin
TYPE i
200 Type set to I.
locsite fix 1024
get image.tape.bin image.txt
get initrd.bin initrd.txt
exit

Building a parameter line
The parameter line file parm.line can be built in VM. Alternatively, you can run
LINUX on another device (for example an Intel PC) and then transfer parm.line as
a binary file to your current environment.
You can create the parameter file in EBCDIC format on a VM system or by using
LINUX. In both cases, the contents of the file are the same.

Where:
where from, to and devno are hexadecimal device numbers of the DASD devices
that you want to be used by LINUX for S/390. You may omit the dasd=...
v root=/dev/ram0 ro
system from initrd.bin.
ipldelay=xyz

you have generated on a UNIX or PC operating system, make sure that your line
contains no special characters (for example, tabs or new lines). In particular your
parameter file cannot span over more than one line and must not be larger that
1023 Byte.
Preparing the tape for IPL

Locate your tape drive and physically insert a blank, formatted, tape into the tape
drive.
Operating under VM in your CMS-session, use the attach command, or ask your
operator to attach the tape to your VM guest.
The format of the attach command is:

attach rdev to userid as vdev

where rdev is the real device number (physical location of tape in the tape device),
userid is the VM guest user ID, and vdev is the virtual device number
(conventionally a ’standard’ location is used for tape devices).
For example:
attach 0649 to your_VM_guest_ID as 0181
The system response is:

TAPE 0649 ATTACHED TO your_VM_guest_ID 0181
Rewind the tape to make sure it is at the beginning. Use the command:
rew 181
Copying the IPL files to the tape

The files must be copied to your tape in the order:
kernel (IMAGE TXT)

parameter file (PARM LINE)
initial RAM disk file (INITRD TXT)
Figure 15. Creating the IPL tape - VM
Note that the initial RAMdisk file (initrd.bin) is a compressed file that the kernel
There are several utilities you can use to transfer the files to your tape for example
ditto or filedef.
Using ditto to copy the files

Operating under VM in your CMS-session, use the ditto command to copy the
files to the tape.

Select the Copy data task by entering the function code 7 <enter>. Then select
CMS file by entering 4 <enter>, and finally Tape data by entering 1 <enter>.
Process View Options Help
-----------------------------------------------------------------------------
DITTO/ESA for VM Task Selection Menu
Select the desired task or enter a DITTO function code, then press Enter.
Use the Menu key to display the menu panel with DITTO function groups.
1. Browse data
2. Edit or update data
3. Work with VTOC
4. Work with VSAM catalog
5. Backup/restore CMS files
6. Print data
7. Copy data +------ Copy Functions ------+
8. Locate data | |
9. Change data | Select type of input data: |
10. Create data | |
11. Position a ta| 1. Tape data |
12. Tape specific| 2. VSAM data |
13. Set processin| 3. MVS/VSE SAM data |
14. Start VSE DIT| 4. CMS file +------ Copy CMS File -------+
| 5. Virtual read| |
| | Select desired output: |
| F1=Help F3=Exit F12=C| 1. Tape data |
+----------------------| 2. VSAM data |
| |
| F1=Help F3=Exit F12=Cancel |
+----------------------------+
Use the ditto data entry window (see below) to copy all three files in the correct
order. The files are copied one at a time, and the example shows the information
required for the first file.
Process View Options Help
------------------------------------------------------------------------------
DITTO/ESA for VM FT - CMS File to Tape
Tapes: 0181
Input: CMS file ID. . . image txt a
Skip count . . . number of records to be skipped

Copy count . . . ALL number of records to be copied
Output: Unit address . . 181 device number of tape

Tape mode. . . . optional recording mode or density code
File ID. . . . .
Record format . F F,FB, V,VB,VS,VBS, D,DB,DS,DBS, or U

Block size . . . 1024 required for blocked output
Rewind the tape to the beginning and define the storage size as (at least) 16 MB.
rew 181
define store 16M

Using filedef to copy the files
Operating under VM in your CMS-session, use the following commands to copy
all three files to the tape in the correct order.
filedef outmove tap1 (recfm f block 1024 lrecl 1024 perm
filedef inmove disk image txt a
move
filedef inmove disk parm file a
move
filedef inmove disk initrd txt a
move
Rewind the tape to the beginning and define the storage size as (at least) 16 MB.
rew 181
define store 16M
Ensuring you do not format the wrong devices
Checking the DASD devices

Operating under VM in your CMS-session, check the hard disk drives attached to
your system — use q dasd to list the devices and confirm the DASD numbers
DASD 0120 3380 VMSYS2 R/O 67 CYL ON DASD 0238 SUBCHANNEL = 000B
DASD 0150 3380 VM4949 R/W 1000 CYL ON DASD 0949 SUBCHANNEL = 0001
DASD 0151 3380 VM4949 R/W 200 CYL ON DASD 0949 SUBCHANNEL = 0002
...
Detaching unused DASD devices

Warning: Before formatting the DASD devices, detach all of the other DASD
devices on your VM system to ensure that you do not format them by mistake.
Operating under VM in your CMS-session, use the command:

#cp detach vdev
where vdev is the virtual device number of the DASD.
For example:
#cp detach 0238
IPL-ing from tape

Operating under VM in your CMS-session, IPL from the tape:
#cp ipl 181 clear
A large number of screen messages appear with no requirement for user input.
Eventually, the system requests information about your network.

Entering network information
Operating under LINUX for S/390, specify your network environment.
Welcome to Linux for S/390
Is your machine connected to a network (Yes/No) ? yes
yes
Select the type of your network device
1) for osa token ring
2) for osa ethernet
3) for channel to channel
Enter your choice (1-3): 1
1
Please type in the options for the lcs module,
e.g. to select relative port 1 on device 0xfd00 you should enter:
noauto=1 devno_portno_pairs=0xfd00,1: your_lcs_module_parameter
your_lcs_module_parameter
Please enter your host name: your_host_name
your_host_name
Please enter your IP address: your_IP_address
your_IP_address
Please enter the net mask: your_net_mask
your_net_mask
Please enter the network address: your_network_address
your_network_address
Please enter the broadcast address: your_broadcast_address
your_broadcast_address
Please enter the gateway address: your_gateway_address
your_gateway_address
Please enter the IP address of the DNS server: your_DNS_server_address
your_DNS_server_address
Please enter the DNS search domain: your_DNS_search_domain
your_DNS_search_domain
Note that the lcs module option is only required for network types
1) osa token ring or 2) osa ethernet
The system responds with a confirmation of the information you have just entered
and asks you to confirm that information.
Configuration will be:
LCS parameter : your_lcs_module_parameter
Host name : your_host_name
IP address : your_IP_address
Net mask : your_net_mask
Net address : your_network_address
Broadcast address: your_broadcast_address
Gateway address : your_gateway_address
DNS IP address : your_DNS_server_address
DNS search domain: your_DNS_search_domain
Is this correct (Yes/No) ? yes
yes
Starting LINUX
Operating under LINUX for S/390, the system provides you with information
about the LINUX boot and asks you to enter a password to start up LINUX. This
is currently set to pass4root and is called the default_root_password in this
document.

Bringing up interface lo
Bringing up interface tr0
Starting portmapper: portmap

Initializing random number generator
Starting INET services: inetd
Starting local
Give root password for maintenance
(or type Control-D for normal startup): default_root_passsword
[root@your_host /root]#
Formatting the devices

Now that LINUX is up and running, you can (on your UNIX/Windows NT
workstation) start a Telnet session to access the LINUX for S/390 system. When
you are asked to enter a password use pass4root which is the
default_root_password.
Telnet your_IP_address
Trying your_IP_address...
Connected to your_IP_address.
Escape character is '|]'.
Linux 2.2.15 (your_host_name) (ttyp0)
your_host_name login: root

Password: default_root_password
Last login: Mon Dec 6 16:40:06 from ...
Format the DASD devices.

[root@your_host /root]# dasdfmt -f /dev/dasda -b 4096
I am going to format the device /dev/dasda with the following parameters:
Major number of device : 94

Minor number of device : 0
Start track : 0
End track : last track of disk
Blocksize : 4096
--->> ATTENTION! <<---
All data in the specified range of that device will be lost.

Type yes to continue, no will leave the disk untouched: yes
The formatting process can take quite a long time. Please do not enter additional
commands until the prompt reappears. Then continue by entering the following
command:
[root@your_host /root]# dasdfmt -f /dev/dasdb -b 4096
I am going to format the device /dev/dasdb with the following parameters:

Major number of device : 94
Minor number of device : 4
Start track : 0
End track : last track of disk
Blocksize : 4096
--->> ATTENTION! <<---
All data in the specified range of that device will be lost.

Type yes to continue, no will leave the disk untouched: yes

Creating a file system
Using Telnet on your UNIX/Windows NT workstation, create a file system for
LINUX. Remember that the device block size must be the same as that used when
formatting the device.
[root@your_host /root]# mke2fs /dev/dasda1 -b 4096
mke2fs 1.15, 15-May-2000 for EXT2 FS 0.5b, 95/08/09

Filesystem label=
OS type: Linux
Block size=4096 (log=0)
Fragment size=4096 (log=0)
103224 inodes, 411522 blocks
20576 blocks (5.00%) reserved for the super user
First data block=1
51 block groups
8192 blocks per group, 8192 fragments per group
2024 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409,
Writing inode tables:

0/51 1/51 2/51 3/51 4/51 5/51 6/51 7/51 8/51 9/51
10/51 11/51 12/51 13/51 14/51 15/51 16/51 17/51 18/51 19/51
20/51 21/51 22/51 23/51 24/51 25/51 26/51 27/51 28/51 29/51
30/51 31/51 32/51 33/51 34/51 35/51 36/51 37/51 38/51 39/51
40/51 41/51 42/51 43/51 44/51 45/51 46/51 47/51 48/51 49/51
50/51 done
Writing superblocks and filesystem accounting information: done
Define the mount point.

[root@your_host /root]# mkdir /mnt/dasda
Mount the device to the DASD.

[root@your_host /root]# mount /dev/dasda1 /mnt/dasda/
Change directory to get to the system root.

[root@your_host /root]# cd /
Creating a swap device

Using Telnet on your UNIX/Windows NT workstation, create a swap device for
LINUX and create paging to transfer the files. Note that there is a limit of 2 GB on
the size of the swap space. If your disk volume is larger than 2 GB, you must use a
smaller disk, or create a swap file of appropriate size on an existing file system.
Setting up swapspace version 1, size = 543727616 bytes
Transferring the complete LINUX file system to LINUX for S/390

Using Telnet on your UNIX/Windows NT workstation, transfer the archive (for
example, initfs_big.tgz) of the complete LINUX file system to the LINUX
system. When you are asked to enter a password use pass4root which is the
default_root_password.

ftp your_IP_address
Connected to your_IP_address.
220 your_host FTP server (Version wu-2.4.2-VR17(1) Tue May 16 13:54:53 CET 2000) ready.
Name (your_IP_address:username): root
331 Password required for root.
Password: default_root_password
230 User root logged in.
Using binary mode to transfer files.
ftp> dir
drwxr-x--- 2 root root 1024 May 13 21:14 .
drwxr-xr-x 15 root root 1024 May 15 18:10 ..
-rw------- 1 root root 1058 May 6 17:08 .bash_history
ftp> bin
200 Type set to I.
ftp> put initfs_big.tgz /mnt/dasda/initfs.tgz
local: initfs.tgz remote: /mnt/dasda/initfs.tgz
226 Transfer complete.
ftp> quit
221 Goodbye.
[username@abc123 username]$ exit
Restoring file system from the archive

Operating under LINUX for S/390, extract the files from the tar archive.
[root@your_host /root]# cd /mnt/dasda
[root@your_host /mnt/dasda]# tar xfzBp initfs.tgz

Operating under LINUX for S/390, change directory to get to the /boot directory
of your LINUX file system:
cd /mnt/dasda/boot
Edit the parameter file (PARM LINE) in the /mnt/dasda/boot directory of your
LINUX file system. Ensure that it contains the following information (you might
find it easier to use the vi editor):
dasd=150-151 root=/dev/dasda1 ro noinitrd
where 150–151 is the range of DASD devices (in this case there are only two, 150
and 151). You might want to use ipldelay=1m to delay the boot process for one
minute (this allows the system components time to stabilize after the IPL).
particular your parameter file cannot span over more than one line and must not
be larger that 1023 Byte.
Write the boot record by using the silo command (see “silo” on page 159). You can
use the silo command in two ways:
v You can run it in a test-mode to see whether everything looks all right. To test
enter the silo command as follows:

v You can run the command to really write the boot record. To do this add the -t2
option to the silo command as follows:
Adapt the first fstab entry to the root device (you might have to use the vi
editor). fstab is located in /etc/fstab. For example:
/dev/dasdb1 swap swap defaults 0 0
Shut down your LINUX for S/390 system using the command:
[root@your_host /root/mnt/dasda]# shutdown -h now
IPL-ing from DASD

Operating under LINUX for S/390, IPL from DASD using the CP commands on
the console.
#cp ipl <root device address> clear
You are prompted again for the network information. Refer to “Entering network
information” on page 83 for more details.

Chapter 9. Installing - Multiprise 3000
Installing LINUX for S/390 on a Multiprise 3000 is very similar to the
native/LPAR installation described in “Chapter 5. Installation - native single image
and LPAR - VM/ESA” on page 35. This is the variant using VM/ESA to create the
IPL tape.
There are some important differences in the area of network connections and I/O
device driver setup, and these differences are described in example format in this
chapter.
Before installing LINUX for S/390 on a Multiprise 3000, you should be familiar
with the technical architecture of the machine. Two ITSO Redbooks are available:
v Multiprise 3000 Technical Introduction: SG24-5633
v Multiprise 3000 Basic Emulated I/O Definitions: SG24-5669
A microcode fix (MCF P6433051) can solve certain types of problem that occur
during IPL. For example, the LCS device can fail to start up after you have
successfully performed an IPL from tape on a LPAR, stopped LINUX, and then
re-booted from tape.
I/O settings
The following example assumes that two Token Ring adapters are being used,
where the MPTS Logical Adapter number 0 is used for OS/2 exclusively and
MPTS Logical Adapter number 1 is used by LINUX for S/390.
The following shows the definition within MPTS in OS/2 which will be used in
the Support Element TCP/IP settings:
IBM PCI Token Ring Family Adapter (IBMTRP.OS2)
0 - IEEE802.2
0 - IBM OS/2 NETBIOS
0 - TCP/IP
Now you have to define the TCP/IP settings in the Support Element:
1. Log-on to the Support Element as
v user ACDADMIN
v default password is PASSWORD
2. Select the View window and click on Console Actions
3. Select 'Support Element Settings' and click on the 'Enable LAN Connection'
check box.
4. You will be asked to provide the Adapter Number.
v Enter 0 for the Logical Adapter number specified within MPTS in OS/2
v Click Apply.
Please also refer to the Redbook Multiprise 3000 Basic Emulated I/O Definitions
Chapter 4.
Please note that you cannot use the same LAN adapter with OS/2 TCP/IP and
LINUX for S/390 TCP/IP.

You will need at least a second adapter to be used by LINUX for S/390. This
adapter should be defined within MPTS in OS/2 as follows:
IBM PCI Token Ring Family Adapter (IBMTRP.OS2)
1 - IBM IEEE802.2
The Token Ring adapter which is used by LINUX for S/390 must be defined
without the TCP/IP protocol driver. You will need the logical adapter number later
in order to configure the LINUX for S/390 TCP/IP definitions. You have to
configure the appropriate IOCDS definitions for read and write channels:
...
...
CHPID PATH=FC,TYPE=EIO,SHARED
...
...
CNTLUNIT CUNUMBR=0E22,PATH=(FC),UNIT=3088,UNITADD=((22))
CNTLUNIT CUNUMBR=0E23,PATH=(FC),UNIT=3088,UNITADD=((23))
...
...
IODEVICE ADDRESS=(0E22),CUNUMBR=(0E22),UNIT=3088,PARTITION=(LINUX390)
IODEVICE ADDRESS=(0E23),CUNUMBR=(0E23),UNIT=3088,PARTITION=(LINUX390)
...
...
You have to enter the definitions in the emulated I/O DEVMAP where the
addresses refer to your settings in the IOCDS. In this example, Device Driver
Manager 9 is LCS3172, but it can be another number depending on your
configuration.
Adr Device Label Atype Size Mgr FN/P
22 3088 9
23 3088 9
The parameters in the parameter line file have to be adjusted accordingly:

... devno_portno_pairs=0x0e22,1
This means that the LCS device driver uses device number 0xe22 for the read
channel and the write channel device number is implicitly 0xe23 (read channel
device number + 1).
The Logical Adapter number 1 is defined within MPTS for OS/2.

Part 3. Configuration procedures
Chapter 10. Upgrading from LINUX 2.2.13 to DASD . . . . . . . . . . . . . . . . 96
LINUX 2.2.15 . . . . . . . . . . . . . 93 Memory optimization . . . . . . . . . . . 96
Compiler optimization. . . . . . . . . . . 96
Chapter 11. Tuning your LINUX for S/390 Apache tuning . . . . . . . . . . . . . 97
installation . . . . . . . . . . . . . . 95 Connectivity between LINUX for S/390 and other
IEEE emulation . . . . . . . . . . . . . 95 S/390 operating systems . . . . . . . . . . 97
Networking . . . . . . . . . . . . . . 95

Chapter 10. Upgrading from LINUX 2.2.13 to LINUX 2.2.15
You should be aware of some changes that have been incorporated into 2.2.14 and
are also valid for 2.2.15:
v The names of the dasd devices have changed from dd?1 to dasd?1
v The major number of the dasd device has changed to 94
v The major number of the minidisk device has changed to 95
v The name of the osa device drivers has changed from osa2lan.o to lcs.o
v The version name of the kernel has changed to 2.2.15
If you want to update to 2.2.15 you need to do the following:

1. Compile a new kernel image, a new silo and a new ipleckd.boot
2. Copy the new kernel-image and ipleckd.boot to /boot, and the new silo to
/sbin
3. Create the directory /lib/modules/2.2.15/net and copy the new lcs-2.2.15.o
to /lib/modules/2.2.15/net/lcs.o.
4. Recreate the minidisk and dasd nodes in /dev
cd /dev
rm mnd* dd*
mknod mnda b 95 0; mknod mndb b 95 1; mknod mndc b 95 2; ...
mknod dasda b 94 0; mknod dasdb b 94 4; mknod dasdc b 94 8; ...
mknod dasda1 b 94 1; mknod dasdb1 b 94 5; "mknod dasdc1 b 94 9; ...
5. Modify your parameter line in /boot and replace every /dev/dd?1 entry with
the corresponding /dev/dasd?1. For example the parameter line:
dasd=192-194 root=/dev/dda1 ro noinitrd
should be replaced by:

dasd=192-194 root=/dev/dasda1 ro noinitrd
6. Change any dd?1 entries in your /etc/fstab to the new equivalent name
dasd?1. For example:
/dev/dda1 / ext2 defaults,errors=remount-ro 0 1
becomes:
7. Change the insmod line in /etc/rc.d/rc.sysinit from:
insmod /lib/modules/2.2.13/net/osa2lan.o
to:
insmod /lib/modules/2.2.15/net/lcs.o
8. If you want to IPL from DASD then rerun silo: "silo -f -d -p -
b ipleckd.boot"
The ELF ABI name for the dynamic linker has been changed from ld-linux.so.2
to ld.so.1. If you want to use old binaries with the new glibc make a link in /lib
cd /lib
ln -s ld-2.1.2.so ld-linux.so.2

Chapter 11. Tuning your LINUX for S/390 installation
General tuning information for LINUX is available from the following web site:
v http://tune.linux.com
IEEE emulation
G5 and G6 (or newer) versions of S/390 are capable of performing floating point
calculations according to the IEEE standard. On S/390 this format is called Binary
Floating Point (BFP) format. BFP calculations are always possible in native single
image or LPAR mode. If you want to use the IEEE hardware FPU using VM,
ensure you have APARs VM62337 and VM62410 installed before bringing up
LINUX under VM. Anyone IPL-ing LINUX under VM/ESA V2R3.0 will need
VM61762, too. It already exists in the 2.4.0 base.
G3 and G4 versions use software emulation to provide the IEEE facility. You need
to set the kernel configuration option, IEEE FPU emulation, to (Y) when you
compile your own kernel. Refer to “IEEE FPU emulation” on page 123 for more
details.
Because the software emulation is noticeable slower than the hardware FPU, you
should try to avoid intensive use of floating point calculations with G3 or G4
versions.
Networking
Virtual CTC devices are used to provide high speed internal connections between
any two operating systems running under VM. ESCON devices are used to
provide these connections under VM or in an LPAR. For example, you can connect
two LINUX for S/390 systems together or a LINUX for S/390 and a OS/390
system. Refer to “CTC/ESCON” on page 141 for more details.
It is essential to define the correct MTU size for the channel device, otherwise it
will not work properly. The same MTU size (default 1500) must be used for the
LINUX for S/390 side of the channel as is used on the remote side. For high
performance, the MTU size must be as large as possible, for example 32 K for
communications between LINUX for S/390 and OS/390.
For outgoing network traffic, one of three types of OSA card is used:
v OSA-2 ENTR
v OSA-2 FENET
v OSA Express Fast Ethernet
The MTU size is fixed for Ethernet, so (apart from normal networking
good-practice) the only way to tune the network performance is to choose the card
most suitable for your requirements:
v The Ethernet and Token Ring (OSA-2 ENTR) card is limited to a data transfer
speed of 10 Mbit/s (Ethernet) or 16 Mbit/s (Token Ring) and is suitable for a
lightly loaded web server or a moderate number of Telnet sessions.
v The Fast Ethernet (OSA-2 FENET) card has been mainly superseded by the OSA
Express Fast Ethernet (OSA Express Fast Ethernet) card. This card operates at

100 Mbit/s and is recommended for web serving and other high bandwidth use.
This card requires a microcode fix (MCL 324 or above) to be applied before it
can be used with LINUX for S/390.
For information about setting-up Token Ring networks and improving Ethernet
performance by workload planning, refer to the Linux Network Administrators’ Guide
available on the World Wide Web from the Linux Documentation project at
DASD
For optimum performance in most cases you should use a 4K block size with your
DASDs. However, because each file takes up a multiple of 4 KB, if you have a
large number of small files, you may want to use a smaller block size.
Note however that the DASD used for IPL must have a block size of 2K or 4K. It
is also important to use a 4K block size for the swap space.
In a VM installation of LINUX for S/390, a special case exists where it can be

better to avoid file system caching. For example, LINUX for S/390 might allocate a
similar amount of virtual memory to the file system cache and to the application.
Because VM can page out the file system cache, it is possible for the data to be
written to the disk twice, once by LINUX for S/390 and then again by VM. In this
case you should reduce the amount of memory available to LINUX for S/390 until
all of the memory is used by the application. This problem does not occur in
native single image or LPAR mode. An alternative solution for a VM installation is
to set Virtual=Real or Virtual=Fixed for the VM Guest.
It is better to use dedicated channels to the DASD rather than sharing channels
with another operating system. For example, if OS/390 is using a channel that
LINUX for S/390 requires, the channel must be closed (by OS/390) and then
reopened (by LINUX for S/390) before it can be used.
Memory optimization
The S/390 system slows down when there is a lot of paging to the DASD. The
amount of paging to DASD can be reduced by the use of a RAM-disk used as a
swap device. The S/390 architecture supports up to 64 GB of XPRAM but LINUX
for S/390 can directly access only 2 GB. This would normally limit the size and
usefulness of the RAM-disk. However, the additional memory can be declared as
expanded storage and used with the XPRAM driver as a file system. XPRAM is a
block device driver and should be used to control the additional memory. Refer to
“XPRAM” on page 139 for more details.
Compiler optimization
Compiler optimization can provide useful speed enhancements, however you must
be careful if you need to debug because some optimization options can make it
impossible to recognize the code. The –03 option will still let you debug the code.
The –mno–backchain option removes the need to write a backchain and it is then
impossible to locate the calling spec of any function. This option provides a 5%
speed enhancement but you can no longer read the code.

Apache tuning
A very informative document about Apache performance tuning can be found on
the Apache web site:
v http://www.apache.org/docs/misc/perf-tuning.html
In short, experiment with the following options:
v Set FollowSymLinks option unless you really do not want it.
v Set AllowOverride to None unless you really need it.
v Explicitly list all DirectoryIndex file options from most to least commonly used.
v Tune KeepAliveTimeout starting with 3 ranging to 30 per content and connection
types.
v Some server applications use multiple processes to handle individual requests.
Tune StartServers starting with 64 increasing in steps of 32 until performance
drops off. Tune MaxClients starting with the value of StartServers. Note that
scaling performance can fall dramatically if MaxClients is too high.
v For SMP systems listening on a single socket, try recompiling after defining
SINGLE_LISTEN_UNSERIALIZED_ACCEPT.
Connectivity between LINUX for S/390 and other S/390 operating

systems
Network connections from LINUX for S/390 to other S/390 operating systems are
based on:
v Ethernet, using the OSA-2 ENTR or OSA Express Fast Ethernet network adapter
v Fast Ethernet using OSA-2 FENET or OSA Express Fast Ethernet network
adapter
v Token Ring using 3172 or OSA-2 ENTR
v CTC using ESCON adapters or (under VM) virtual CTC connections
v IUCV (if both operating systems run as guests under the same VM)
For more information about these devices, refer to:
v LINUX for S/390: LCS Device Driver - for the OSA cards.
v “CTC/ESCON” on page 141 - for the ESCON and virtual CTC connections.
v “IUCV” on page 144 - for the IUCV device.
Communication between LINUX for S/390 and other S/390 operating systems
(OS/390, VSE or VM) can be established using standard TCP/IP (or UDP/IP)
connections. Based on TCP/IP or UDP/IP, you can run remote applications, for
example, Telnet, rlogin, FTP, http, NFS, etc. [reference to general TCP/IP book].
Chapter 11. Tuning your LINUX for S/390 installation 97

Part 4. Kernel building
Chapter 12. Building the kernel . . . . . . 101 Network file systems . . . . . . . . . . . 119
Preliminary steps . . . . . . . . . . . . 101 Partition types . . . . . . . . . . . . . 119
Configuring the parameters . . . . . . . . 102 Kernel hacking . . . . . . . . . . . . . 120
Checking the configuration . . . . . . . . . 103 Load an alternate configuration file . . . . . . 120
Checking the dependencies . . . . . . . . . 103 Save configuration to an alternate file . . . . . 121
Compiling the kernel . . . . . . . . . . . 103 Exit ’menuconfig’ . . . . . . . . . . . . 121
Compiling for IPL from tape . . . . . . . 104
Installing the modules . . . . . . . . . . 104 Chapter 15. Kernel parameter options . . . . 123
Finishing off. . . . . . . . . . . . . . 104 IEEE FPU emulation . . . . . . . . . . . 123
Built-in IPL record support . . . . . . . . . 124
Chapter 13. Using ’config’ or ’oldconfig’ . . . 107 IPL method generated into head.S . . . . . . 124
Sample output listing. . . . . . . . . . . 107 Support for VM minidisk . . . . . . . . . 124
Cross-reference to configuration options . . . . 109 Support for synchronous read-write . . . . . . 125
Support for DASD devices . . . . . . . . . 125
Chapter 14. Using ’menuconfig’ . . . . . . 111 Support for ECKD disks. . . . . . . . . . 125
File handling . . . . . . . . . . . . . 111 Support for FBA disks . . . . . . . . . . 126
Main menu . . . . . . . . . . . . . . 112 Support for DIAG access to CMS reserved
Code maturity level option . . . . . . . . . 113 minidisk . . . . . . . . . . . . . . . 126
Processor type and features. . . . . . . . . 113 XPRAM device support . . . . . . . . . . 126
Loadable module support . . . . . . . . . 114 LCS device support . . . . . . . . . . . 127
General setup . . . . . . . . . . . . . 114 CTC device support . . . . . . . . . . . 127
S/390 block device drivers . . . . . . . . . 115 IUCV device support . . . . . . . . . . . 127
S/390 network device support. . . . . . . . 116 Support for 3215 line mode terminal . . . . . 128
S/390 terminal and console options . . . . . . 116 Support for console output on 3215 line mode
Networking options . . . . . . . . . . . 117 terminal . . . . . . . . . . . . . . . 128
QoS and/or fair queueing . . . . . . . . . 118 Support for hardware console . . . . . . . . 128
Filesystems . . . . . . . . . . . . . . 118 Console output on hardware console . . . . . 129

Chapter 12. Building the kernel
Before deciding to change the details in the kernel source code, consider whether
installing one of the LINUX for S/390 kernel images provided in the LINUX for
S/390 kernel patches will be a more appropriate solution to your requirements.
Your build system must have the following software installed (as a minimum):
v kernel source 2.2.15 with the LINUX for S/390 patch
v gcc version 2.95.2 or newer supporting LINUX for S/390
v binutils version 2.9.1 or newer supporting LINUX for S/390
v glibc 2.1.2 or newer supporting LINUX for S/390
v sed
v bash
v make version 3.77 or newer.

v You are confident in your ability to modify the kernel parameters without
severely damaging the system
v You cannot locate a pre-compiled kernel image that meets your requirements
(that is, a suitable kernel does not already exist)
v You are able to make an emergency IPL tape available (or preferably a complete
backup on tape).
If you decide to modify your LINUX for S/390 kernel, you should use the
instructions outlined in the following sections. In this way you will be sure of
completing all of the tasks necessary to ensure the system runs properly when you
have finished. For example, you might have to install and link additional modules
after you have compiled and installed the kernel.
1. “Preliminary steps”
2. “Configuring the parameters” on page 102
3. “Checking the configuration” on page 103
4. “Checking the dependencies” on page 103
5. “Compiling the kernel” on page 103
6. “Installing the modules” on page 104
7. “Finishing off” on page 104
Preliminary steps
Before working with the kernel, there are a number of precautions that you should
take:
v Make a backup copy of the current kernel and all modules corresponding to this
kernel. It is important to make a backup even if you are replacing your kernel
with a new version. This is because the new system might not run properly and
you can use the backup to reload the old system
v Decide whether you want to modify the complete kernel, or only change some
modules. If you only change some modules, you might not have to build the
kernel.

If you are upgrading or replacing the kernel, obtain the new kernel or patch and
load it into the directory /usr/src. This will probably create a new directory
usr/src/linux, which will overwrite your last version of the kernel source. You
will need to check the symbolic links to the /usr/include directory to ensure the
following two links are valid:
v ln -sf /usr/src/linux/include/linux /usr/include/linux
v ln -sf /usr/src/linux/include/asm /usr/include/asm
Your first step in modifying the kernel, is to change to the /usr/src/linux

directory and enter the command make distclean. This cleans up the LINUX for
S/390 distribution, resetting all options to their default values and removing all
object files from the system. If you enter make clean instead of make distclean,
you will only delete the object files.
Configuring the parameters

To configure the parameters, make sure you are in the /usr/src/linux directory
and enter the command make config.
In make config, you select what you want to include in the resident kernel and
what features you want to have available as dynamically loadable modules. See
“Chapter 13. Using ’config’ or ’oldconfig’” on page 107 for an example of a
make config listing. You will generally select the minimal resident set that is
needed to boot:
v The type of file system used for your root partition (for example, ext2)
v Normal hard disk drive support (for example, DASD)
v Network support
v TCP/IP support.
The set of modules is constantly increasing, and you will be able to select the
option (M) when responding to the prompts shown in make config for those
features that the current kernel can offer as loadable modules. You can completely
enable or disable the use of your set of modules by using the CONFIG_MODVERSIONS
option during make config.
make config requires bash to allow it work. Bash will be searched for in $BASH,
/bin/bash and /bin/sh (in that order), so it must be located in one of these
directories for it to work. make config must be performed even if you are only
upgrading to the next patch. New configuration options are added in each release,
and odd problems will turn up if the configuration files are not set up as expected.
If you want to upgrade your existing configuration with minimal work, use
make oldconfig, which will keep your old kernel and only ask you questions about
new or modified options.
Alternative configuration commands are:

v make menuconfig — Text based menus, radiolists and windows, see “Chapter 14.
Using ’menuconfig’” on page 111
v make oldconfig — Same as make config except all questions based on the
contents of your existing ./.config file
v make xconfig — This X windows based configuration tool is currently not
available with LINUX for S/390.

Notes on make config:
v Keeping unnecessary drivers in the LINUX for S/390 kernel will make it bigger,
and can cause problems: for example, unnecessary networking options might
confuse some drivers.
v Selecting the kernel hacking option and changing the source code directly
usually result in a bigger or slower LINUX for S/390 kernel (or both). Thus you
should probably answer (N) to the questions for development, experimental, or
debugging features.
Checking the configuration

There are a pair of scripts that check the source tree for problems. These scripts do
not have to be run each time you build the kernel, but it is a good idea to check
for these types of errors and discrepancies at regular intervals.
make checkconfig checks the source tree for missing instances of #include <linux>.
This needs to be done occasionally, because the C preprocessor will silently give
bad results if these symbols haven’t been included (it treats undefined symbols in
preprocessor directives as defined to 0). Superfluous uses of #include <linux> are
also reported, but you can ignore these, because smart CONFIG_* dependencies
make them harmless. You can run make checkconfig without configuring the
kernel. Also, make checkconfig does not modify any files.
make checkhelp checks the source tree for options that are in Config.in files but
are not documented in scripts/Configure.help. Again, this needs to be done
occasionally. If you have hacked the kernel and changed configuration options or
are adding new ones, it is a good idea to make checkhelp (and add help as
necessary) before you publish your patch. Also, make checkhelp does not modify
any files.
Checking the dependencies

All of the source dependencies must be set each time you configure a new LINUX
for S/390 kernel.
Enter make dep to set up all the dependencies correctly. make dep is a synonym for
the long form, make depend. This command performs two tasks:
v It computes dependency information about which .o files depend on which .h
files. It records this information in a top-level file named .hdepend and in one
file per source directory named .depend.
v If you have CONFIG_MODVERSIONS enabled, make dep computes symbol version
information for all of the files that export symbols (note that both resident and
modular files can export symbols). If you do not enable CONFIG_MODVERSIONS,
you only have to run make dep once, right after the first time you configure the
kernel. The .hdepend files and the .depend file are independent of your
configuration. If you do enable CONFIG_MODVERSIONS, you must run make dep
because the symbol version information depends on the configuration.
Compiling the kernel

Enter make image to create a LINUX for S/390 kernel image. This compiles the
source code and leaves the kernel image in the current directory (usually
/usr/src/linux/arch/s390/boot).
Chapter 12. Building the kernel 103

Note that make zImage and make bzImage are not supported by the LINUX for
S/390 kernel.
Compiling for IPL from tape

If you want to make a boot tape, you must transfer a set of files to the IPL tape.
For more information see one of the sections describing how to create an IPL-able
tape, for example “Creating the tape - overview” on page 23. The files,
image.tape.bin (renamed as image.txt), parm.line, and initrd.bin (renamed as
initrd.txt) are the ones used during the installation process.
If you want to IPL from tape, ensure that the following configuration settings are
used:
v CONFIG_IPL is set
v CONFIG_IPL_TAPE is set
v CONFIG_BLK_DEV_RAM is set
v CONFIG_BLK_DEV_INITRD is set.
Additionally you should keep the default configuration settings to make sure that
all requirements to get a running LINUX for S/390 kernel are met.
Installing the modules

If you configured any of the parts of the LINUX for S/390 kernel as modules by
selecting (M) in the kernel parameter option, you will have to create the modules
and then link them to the kernel.
You create the modules by entering the command make modules. This will compile
all of the modules and update the linux/modules directory. This directory will now
contain a set of symbolic links, pointing to the various object files in the kernel
tree.
After you have created all your modules, you must enter make modules_install.
This will copy all of the newly made modules into subdirectories under
/lib/modules/kernel_release/, where kernel_release is 2.2.15 (the current kernel
version).
As soon as you have rebooted the newly made kernel, you can use the utilities
insmod and rmmod to install and remove modules without recompiling the kernel.
Read the man-pages for insmod and rmmod to find out how to configure and
remove a module.
Finishing off
You should always keep a backup LINUX for S/390 kernel available in case
something goes wrong. This backup must also include the modules corresponding
to that kernel. If you are installing a new kernel with the same version number as
your working kernel, make a backup of your modules’ directory before you do a
make modules_install.
In order to boot your new kernel, you’ll need to copy the kernel image (found in
/usr/src/linux/arch/s390/boot/image after compilation) to the place where your
regular bootable kernel is located. This will be on your IPL tape.

To see how to create a tape from which you can perform an IPL, refer to:
v “Chapter 8. Installation using VM - IPL from tape” on page 75
Chapter 12. Building the kernel 105

Chapter 13. Using ’config’ or ’oldconfig’
Use make config to configure all of the LINUX for S/390 kernel options, or use
make oldconfig to keep your current kernel options and change only those options
that are new or have been modified in the latest kernel release.
Use make config or make oldconfig when you only have access to a line based
console. If you can use a screen based console, you might find make menuconfig
gives you a better interface (see “Chapter 14. Using ’menuconfig’” on page 111).
The following output listing shows an example of the complete configuration script
that results from a make config. See “Chapter 15. Kernel parameter options” on
page 123 for more information about individual options.
Sample output listing

rm -f include/asm
( cd include ; ln -sf asm-s390 asm)
/bin/sh scripts/Configure arch/s390/config.in
#
# Using defaults found in .config
#
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
*
* Processor type and features
*
Symmetric multi-processing support (CONFIG_SMP) [Y/n/?]
IEEE FPU emulation (CONFIG_IEEEFPU_EMULATION) [Y/n/?]
*
* Loadable module support
*
Enable loadable module support (CONFIG_MODULES) [Y/n/?]
Set version information on all symbols for modules (CONFIG_MODVERSIONS) [N/y/?]
Kernel module loader (CONFIG_KMOD) [Y/n/?]
*
* General setup
*
Fast IRQ handling (CONFIG_FAST_IRQ) [Y/n/?]
Builtin IPL record support (CONFIG_IPL) [Y/n/?]
IPL method generated into head.S (tape, vm_reader) [vm_reader]
defined CONFIG_IPL_VM
Networking support (CONFIG_NET) [Y/n/?]
System V IPC (CONFIG_SYSVIPC) [Y/n/?]
BSD Process Accounting (CONFIG_BSD_PROCESS_ACCT) [N/y/?]
Sysctl support (CONFIG_SYSCTL) [Y/n/?]
Kernel support for ELF binaries (CONFIG_BINFMT_ELF) [Y/m/n/?]
*
* S/390 block device drivers
*
Loopback device support (CONFIG_BLK_DEV_LOOP) [Y/m/n/?]
Network block device support (CONFIG_BLK_DEV_NBD) [N/y/m/?]
Multiple devices driver support (CONFIG_BLK_DEV_MD) [N/y/?]
RAM disk support (CONFIG_BLK_DEV_RAM) [Y/m/n/?]
Initial RAM disk (initrd) support (CONFIG_BLK_DEV_INITRD) [Y/n/?]
XPRAM disk support (CONFIG_BLK_DEV_XPRAM) [N/y/m/?]
Support for VM minidisk (VM only) (CONFIG_MDISK) [N/y/?] y
Support for synchronous read-write (CONFIG_MDISK_SYNC) [N/y/?] (NEW)

Support for DASD devices (CONFIG_DASD) [Y/m/n/?]
*
* DASD disciplines
*
Support for ECKD Disks (CONFIG_DASD_ECKD) [Y/n/?]
Support for FBA Disks (CONFIG_DASD_FBA) [Y/n/?]
Support for S/390 tape devices (CONFIG_S390_TAPE) [N/y/m/?]
Support for DIAG access to CMS reserved minidisk (CONFIG_DASD_MDSK) [N/y/?]
*
* S/390 Network device support
*
Channel Device Configuration (Temporary Option) (CONFIG_CHANDEV) [N/y/?]
Network device support (CONFIG_NETDEVICES) [Y/n/?]
scripts/Configure: menu_option: command not found
*
* S390 Network devices
*
Lan Channel Station Interface (CONFIG_LCS) [Y/m/n/?]
CTC device support (CONFIG_CTC) [Y/n/?]
IUCV device support (VM only) (CONFIG_IUCV) [Y/n/?]
Dummy net driver support (CONFIG_DUMMY) [N/y/m/?]
Ethernet (10 or 100Mbit) (CONFIG_NET_ETHERNET) [Y/n/?]
Token Ring driver support (CONFIG_TR) [Y/n/?]
*
* S/390 Terminal and Console options
*
Support for 3215 line mode terminal (CONFIG_3215) [Y/n/?]
Support for console on 3215 line mode terminal (CONFIG_3215_CONSOLE) [Y/n/?]
Support for HWC line mode terminal (CONFIG_HWC) [Y/n/?]
console on HWC line mode terminal (CONFIG_HWC_CONSOLE) [Y/n/?]
*
* Networking options
*
Packet socket (CONFIG_PACKET) [Y/m/n/?]
Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?]
Routing messages (CONFIG_RTNETLINK) [N/y/?]
Netlink device emulation (CONFIG_NETLINK_DEV) [N/y/m/?]
Network firewalls (CONFIG_FIREWALL) [N/y/?]
Socket Filtering (CONFIG_FILTER) [N/y/?]
Unix domain sockets (CONFIG_UNIX) [Y/m/n/?]
TCP/IP networking (CONFIG_INET) [Y/n/?]
IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?]
IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [N/y/?]
IP: kernel level autoconfiguration (CONFIG_IP_PNP) [N/y/?]
IP: optimize as router not host (CONFIG_IP_ROUTER) [N/y/?]
IP: tunneling (CONFIG_NET_IPIP) [N/y/m/?]
IP: GRE tunnels over IP (CONFIG_NET_IPGRE) [N/y/m/?]
IP: aliasing support (CONFIG_IP_ALIAS) [N/y/?]
IP: TCP syncookie support (not enabled per default) (CONFIG_SYN_COOKIES) [N/y/?]
*
* (it is safe to leave these untouched)
*
IP: Reverse ARP (CONFIG_INET_RARP) [N/y/m/?]
IP: Allow large windows (not recommended if <16Mb of memory) (CONFIG_SKB_LARGE) [Y/n/?]
The IPv6 protocol (EXPERIMENTAL) (CONFIG_IPV6) [N/y/m/?]
*
*
*
The IPX protocol (CONFIG_IPX) [N/y/m/?]
Appletalk DDP (CONFIG_ATALK) [N/y/m/?]
CCITT X.25 Packet Layer (EXPERIMENTAL) (CONFIG_X25) [N/y/m/?]
LAPB Data Link Driver (EXPERIMENTAL) (CONFIG_LAPB) [N/y/m/?]
Bridging (EXPERIMENTAL) (CONFIG_BRIDGE) [N/y/?]
802.2 LLC (EXPERIMENTAL) (CONFIG_LLC) [N/y/?]
Acorn Econet/AUN protocols (EXPERIMENTAL) (CONFIG_ECONET) [N/y/m/?]
WAN router (CONFIG_WAN_ROUTER) [N/y/m/?]
Fast switching (read help!) (CONFIG_NET_FASTROUTE) [N/y/?]

Forwarding between high speed interfaces (CONFIG_NET_HW_FLOWCONTROL) [N/y/?]
CPU is too slow to handle full bandwidth (CONFIG_CPU_IS_SLOW) [N/y/?]
*
* QoS and/or fair queueing
*
QoS and/or fair queueing (CONFIG_NET_SCHED) [N/y/?]
*
* Filesystems
*
Quota support (CONFIG_QUOTA) [N/y/?]
Kernel automounter support (CONFIG_AUTOFS_FS) [N/y/m/?]
ADFS filesystem support (read only) (EXPERIMENTAL) (CONFIG_ADFS_FS) [N/y/m/?]
Amiga FFS filesystem support (CONFIG_AFFS_FS) [N/y/m/?]
Apple Macintosh filesystem support (experimental) (CONFIG_HFS_FS) [N/y/m/?]
DOS FAT fs support (CONFIG_FAT_FS) [N/y/m/?]
ISO 9660 CDROM filesystem support (CONFIG_ISO9660_FS) [N/y/m/?]
Minix fs support (CONFIG_MINIX_FS) [N/y/m/?]
NTFS filesystem support (read only) (CONFIG_NTFS_FS) [N/y/m/?]
OS/2 HPFS filesystem support (read only) (CONFIG_HPFS_FS) [N/y/m/?]
/proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
QNX filesystem support (EXPERIMENTAL) (CONFIG_QNX4FS_FS) [N/y/m/?]
ROM filesystem support (CONFIG_ROMFS_FS) [N/y/m/?]
Second extended fs support (CONFIG_EXT2_FS) [Y/m/n/?]
System V and Coherent filesystem support (CONFIG_SYSV_FS) [N/y/m/?]
UFS filesystem support (CONFIG_UFS_FS) [N/y/m/?]
SGI EFS filesystem support (read only) (experimental) (CONFIG_EFS_FS) [N/y/m/?]
*
* Network File Systems
*
Coda filesystem support (advanced network fs) (CONFIG_CODA_FS) [N/y/m/?]
NFS filesystem support (CONFIG_NFS_FS) [Y/m/n/?]
NFS server support (CONFIG_NFSD) [N/y/m/?]
SMB filesystem support (to mount WfW shares etc.) (CONFIG_SMB_FS) [N/y/m/?]
NCP filesystem support (to mount NetWare volumes) (CONFIG_NCP_FS) [N/y/m/?]
*
* Partition Types
*
BSD disklabel (BSD partition tables) support (CONFIG_BSD_DISKLABEL) [N/y/?]
Macintosh partition map support (CONFIG_MAC_PARTITION) [N/y/?]
SMD disklabel (Sun partition tables) support (CONFIG_SMD_DISKLABEL) [N/y/?]
Solaris (x86) partition table support (CONFIG_SOLARIS_X86_PARTITION) [N/y/?]
Unixware slices support (EXPERIMENTAL) (CONFIG_UNIXWARE_DISKLABEL) [N/y/?]
*
* Kernel hacking
*
Kernel profiling support (CONFIG_PROFILE) [N/y/?]
Remote GDB kernel debugging (CONFIG_REMOTE_DEBUG) [N/y/?]
*** End of Linux kernel configuration.

*** Check the top-level Makefile for additional configuration.
*** Next, you may run 'make dep'.
Cross-reference to configuration options

The LINUX for S/390-specific configuration options shown in the sample output
listing are described in the following sections:
v “IEEE FPU emulation” on page 123
v “Built-in IPL record support” on page 124
v “IPL method generated into head.S” on page 124
v “Support for VM minidisk” on page 124
v “Support for synchronous read-write” on page 125
v “Support for DASD devices” on page 125
v “Support for ECKD disks” on page 125
Chapter 13. Using ’config’ or ’oldconfig’ 109

v “Support for FBA disks” on page 126
v “Support for DIAG access to CMS reserved minidisk” on page 126
v “XPRAM device support” on page 126
v “LCS device support” on page 127
v “CTC device support” on page 127
v “IUCV device support” on page 127
v “Support for 3215 line mode terminal” on page 128
v “Support for console output on 3215 line mode terminal” on page 128
v “Support for hardware console” on page 128
v “Console output on hardware console” on page 129

Chapter 14. Using ’menuconfig’
You can use make menuconfig to edit individual LINUX for S/390 kernel options
out of sequence and you can discard your settings at any time. You need a screen
based console device to use make menuconfig. If you only have access to a line
based console, you must use make config, see “Chapter 13. Using ’config’ or
’oldconfig’” on page 107 for more details.
Some options can be built directly into the kernel. Other options can be made into
dynamically loadable modules. Some options can be completely removed
altogether. There are also certain kernel parameters which are not really selectable
options (Y) or (N), but instead values must be entered for them or selected from a
list (decimal or hexadecimal numbers or possibly text).
The menu items begin with various types of bracket to indicate that the features:
v [*] are configured to be built in to the kernel.
v [ ] are configured to be removed from the kernel.
v <M> are configured to be modularized.
v < > are module capable features.
v <*> could have been modules, but have been built into the kernel.
Modules are linked to the kernel after booting.
Some menu items contain subordinate options that are displayed only when the
menu item has been selected.
File handling
You can revise your settings up until you save the configuration. You will be given
a last chance to confirm them prior to exiting menuconfig, see “Exit ’menuconfig’”
on page 121.
If menuconfig quits with an error while saving your configuration, you can look in
the file /usr/src/linux/.menuconfig.log for information which can help you
determine the failure cause.
You can also save the current configuration to a file of your choice, or load a
previously saved configuration, see “Save configuration to an alternate file” on
page 121 and “Load an alternate configuration file” on page 120.
Menuconfig supports the use of alternate configuration files for those who, for
various reasons, find it necessary to switch between different kernel configurations.
At the end of the main menu you will find two options. One is for saving the
current configuration to a file of your choosing. The other option is for loading a
previously saved alternate configuration. Even if you don’t use alternate
configuration files, but during a session you decide to restore your previously
saved settings from .config, you can use the Load Alternate... to do so without
restarting menuconfig.

Main menu
The following example shows the different sets of configuration options:
Linux Kernel v2.2.15 Configuration
──────────────────────────────────────────────────────────────────────────────
┌─────────────────────────────── Main Menu ───────────────────────────────┐
│ Arrow keys navigate the menu. <Enter> selects submenus --->. │
│ Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, │
│ <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help. │
│ Legend: [*] built-in [ ] excluded <M> module < > module capable │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Code maturity level options ---> │ │
│ │ Processor type and features ---> │ │
│ │ Loadable module support ---> │ │
│ │ General setup ---> │ │
│ │ S/390 block device drivers ---> │ │
│ │ S/390 Network device support ---> │ │
│ │ S/390 Terminal and Console options ---> │ │
│ │ --- Character devices │ │
│ │ [*] Unix98 PTY support │ │
│ │ (256) Maximum number of Unix98 PTYs in use (0-2048) │ │
│ │ Networking options ---> │ │
│ │ Filesystems ---> │ │
│ │ Kernel hacking ---> │ │
│ │ --- │ │
│ │ Load an Alternate Configuration File │ │
│ │ Save Configuration to an Alternate File │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > │
└─────────────────────────────────────────────────────────────────────────┘
The following links point to the remaining menuconfig menus:

v “Code maturity level option” on page 113
v “Processor type and features” on page 113
v “Loadable module support” on page 114
v “General setup” on page 114
v “S/390 block device drivers” on page 115
v “S/390 network device support” on page 116
v “S/390 terminal and console options” on page 116
v “Networking options” on page 117
v “QoS and/or fair queueing” on page 118
v “Filesystems” on page 118
v “Network file systems” on page 119
v “Partition types” on page 119
v “Kernel hacking” on page 120
v “Save configuration to an alternate file” on page 121
v “Load an alternate configuration file” on page 120
v “Exit ’menuconfig’” on page 121.

Code maturity level option
The Code Maturity Level option is intended to reduce the number of options that
are displayed. This can help by not showing the code/drivers that are either
incomplete or still under development:
──────────────────────────────────────────────────────────────────────────────
┌────────────────────── Code maturity level options ──────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Prompt for development and/or incomplete code/drivers │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
Processor type and features

The Processor Type and Features options allow you to configure the kernel to
match your S/390 hardware installation.
──────────────────────────────────────────────────────────────────────────────
┌────────────────────── Processor type and features ──────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Symmetric multi-processing support │ │
│ │ [*] IEEE FPU emulation │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
The LINUX for S/390 Processor Type and Features menu option is described in the
following section:
v “IEEE FPU emulation” on page 123.
Chapter 14. Using ’menuconfig’ 113

Loadable module support
The Loadable Module Support option lets you use dynamically loaded modules
that are linked to your basic kernel.
──────────────────────────────────────────────────────────────────────────────
┌──────────────────────── Loadable module support ────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Enable loadable module support │ │
│ │ [ ] Set version information on all symbols for modules │ │
│ │ [*] Kernel module loader │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
General setup
The General Setup options configure your kernel’s interaction with certain external
programs, this includes:
v kernel networking support
v the synchronization and exchange of information between kernel and program
v instructing the kernel to write process accounting information to a file
v dynamically changing certain kernel parameters and variables on the fly.
──────────────────────────────────────────────────────────────────────────────
┌───────────────────────────── General setup ─────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Fast IRQ handling │ │
│ │ [*] Builtin IPL record support │ │
│ │ (tape) IPL method generated into head.S │ │
│ │ [*] Networking support │ │
│ │ [*] System V IPC │ │
│ │ [ ] BSD Process Accounting │ │
│ │ [ ] Sysctl support │ │
│ │ <*> Kernel support for ELF binaries │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘

The LINUX for S/390 General Setup menu options are described in the following
sections:
v “IPL method generated into head.S” on page 124.
S/390 block device drivers

The S/390 Block Device Drivers options allow the kernel to be set up to use the
various block devices available with your S/390 system.
──────────────────────────────────────────────────────────────────────────────
┌────────────────────── S/390 block device_drivers ───────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ <*> Loopback device support │ │
│ │ < > Network block device support │ │
│ │ [ ] Multiple devices driver support │ │
│ │ <*> RAM disk support │ │
│ │ [*] Initial RAM disk (initrd) support │ │
│ │ < > XPRAM disk support │ │
│ │ [*] Support for VM minidisk (VM only) │ │
│ │ [ ] Support for synchronous read-write │ │
│ │ <*> Support for DASD devices │ │
│ │ --- DASD disciplines │ │
│ │ [*] Support for ECKD Disks │ │
│ │ [*] Support for FBA Disks │ │
│ │ < > Support for S/390 tape devices │ │
│ │ [ ] Support for DIAG access to CMS reserved minidisk │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
Note that the Support for DIAG access to CMS reserved minidisk option is
available only when the Support for VM minidisk option is not selected.
The S/390 Block Device Drivers menu options unique to LINUX for S/390 are
described in the following sections:
v “Support for ECKD disks” on page 125.

S/390 network device support
The S/390 Network Device Support options allow the kernel to be set up to use
the various network devices available with your S/390 system.
──────────────────────────────────────────────────────────────────────────────
┌───────────────────── S/390 Network device support ──────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Network device support │ │
│ │ --- S390 Network devices │ │
│ │ <*> Lan Channel Station Interface │ │
│ │ [*] CTC device support │ │
│ │ [*] IUCV device support (VM only) │ │
│ │ < > Dummy net driver support │ │
│ │ [*] Ethernet (10 or 100Mbit) │ │
│ │ [*] Token Ring driver support │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
The S/390 Network device support menu options unique to LINUX for S/390 are
described in the following sections:
v “IUCV device support” on page 127.
S/390 terminal and console options

The S/390 Terminal and Console options allow the kernel to be set up to use the
various line mode terminals (or emulators) available with your S/390 system.
──────────────────────────────────────────────────────────────────────────────
┌────────────────── S/390 Terminal and Console options ───────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Support for 3215 line mode terminal │ │
│ │ [*] Support for console on 3215 line mode terminal │ │
│ │ [*] Support for hardware console │ │
│ │ [*] console output on hardware console │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘

The S/390 Terminal and Console options menu options unique to LINUX for
S/390 are described in the following sections:
v “Console output on hardware console” on page 129.
Networking options
The Networking options allow the kernel to interact with the network devices
attached to your S/390 and also lets you optimize the performance of
communications within and outside your system.
──────────────────────────────────────────────────────────────────────────────
┌────────────────────────── Networking options ───────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ <*> Packet socket │ │
│ │ [*] Kernel/User netlink socket │ │
│ │ [ ] Routing messages │ │
│ │ < > Netlink device emulation │ │
│ │ [ ] Network firewalls │ │
│ │ [ ] Socket Filtering │ │
│ │ <*> Unix domain sockets │ │
│ │ [*] TCP/IP networking │ │
│ │ [ ] IP: multicasting │ │
│ │ [ ] IP: advanced router │ │
│ │ [ ] IP: kernel level autoconfiguration │ │
│ │ [ ] IP: optimize as router not host │ │
│ │ < > IP: tunneling │ │
│ │ < > IP: GRE tunnels over IP │ │
│ │ [ ] IP: aliasing support │ │
│ │ [ ] IP: TCP syncookie support (not enabled per default) │ │
│ │ --- (it is safe to leave these untouched) │ │
│ │ < > IP: Reverse ARP │ │
│ │ [*] IP: Allow large windows (not recommended if <16Mb of memory) │ │
│ │ < > The IPv6 protocol (EXPERIMENTAL) │ │
│ │ --- │ │
│ │ < > The IPX protocol │ │
│ │ < > Appletalk DDP │ │
│ │ < > CCITT X.25 Packet Layer (EXPERIMENTAL) │ │
│ │ < > LAPB Data Link Driver (EXPERIMENTAL) │ │
│ │ [ ] Bridging (EXPERIMENTAL) │ │
│ │ [ ] 802.2 LLC (EXPERIMENTAL) │ │
│ │ < > Acorn Econet/AUN protocols (EXPERIMENTAL) │ │
│ │ < > WAN router │ │
│ │ [ ] Fast switching (read help!) │ │
│ │ [ ] Forwarding between high speed interfaces │ │
│ │ [ ] CPU is too slow to handle full bandwidth │ │
│ │ QoS and/or fair queueing ---> │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘

QoS and/or fair queueing
The QoS and/or Fair Queueing option allows fine tuning of the network device
packet handling algorithms.
──────────────────────────────────────────────────────────────────────────────
┌─────────────────────── QoS and/or fair queueing ────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] QoS and/or fair queueing │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
Filesystems
The Filesystems options allow you to define the filesystems used to access your
storage devices (hard disk, CDROM etc.).
──────────────────────────────────────────────────────────────────────────────
┌────────────────────────────── Filesystems ──────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] Quota support │ │
│ │ < > Kernel automounter support │ │
│ │ < > ADFS filesystem support (read only) (EXPERIMENTAL) │ │
│ │ < > Amiga FFS filesystem support │ │
│ │ < > Apple Macintosh filesystem support (experimental) │ │
│ │ < > DOS FAT fs support │ │
│ │ < > ISO 9660 CDROM filesystem support │ │
│ │ < > Minix fs support │ │
│ │ < > NTFS filesystem support (read only) │ │
│ │ < > OS/2 HPFS filesystem support (read only) │ │
│ │ [*] /proc filesystem support │ │
│ │ < > QNX filesystem support (EXPERIMENTAL) │ │
│ │ < > ROM filesystem support │ │
│ │ <*> Second extended fs support │ │
│ │ < > System V and Coherent filesystem support │ │
│ │ < > UFS filesystem support │ │
│ │ < > SGI EFS filesystem support (read only) (experimental) │ │
│ │ Network File Systems ---> │ │
│ │ Partition Types ---> │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘

Network file systems
The Network File Systems options let you decide which network filesystem is most
appropriate for your system.
──────────────────────────────────────────────────────────────────────────────
┌───────────────────────── Network File Systems ──────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ < > Coda filesystem support (advanced network fs) │ │
│ │ <*> NFS filesystem support │ │
│ │ < > NFS server support │ │
│ │ < > SMB filesystem support (to mount WfW shares etc.) │ │
│ │ < > NCP filesystem support (to mount NetWare volumes) │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
Partition types
The Partition Types options lets you gain access to the hard disk partitions of other
device types.
──────────────────────────────────────────────────────────────────────────────
┌──────────────────────────── Partition Types ────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] BSD disklabel (BSD partition tables) support │ │
│ │ [ ] Macintosh partition map support │ │
│ │ [ ] SMD disklabel (Sun partition tables) support │ │
│ │ [ ] Solaris (x86) partition table support │ │
│ │ [ ] Unixware slices support (EXPERIMENTAL) │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘

Kernel hacking
The Kernel Hacking options allow you access and control over the kernel in certain
situations. These options should be used with care!
──────────────────────────────────────────────────────────────────────────────
┌──────────────────────────── Kernel hacking ─────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] Kernel profiling support │ │
│ │ [ ] Remote GDB kernel debugging │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────┤
└─────────────────────────────────────────────────────────────────────────┘
Load an alternate configuration file

For various reasons, you might want to keep different kernel configurations
available on a single S/390 system. Entering a file name here will allow you to
later retrieve, modify and use the current configuration as an alternate to whatever
configuration options you have selected at that time.
┌─────────────────────────────────────────────────────┐
│ Enter the name of the configuration file you wish │
│ to load. Accept the name shown to restore the │
│ configuration you last retrieved. Leave blank to │
│ abort. │
│ ┌─────────────────────────────────────────────────┐ │
│ │arch/s390/defconfig │ │
│ └─────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────┤
│ < Ok > < Help > │
└─────────────────────────────────────────────────────┘

Save configuration to an alternate file
For various reasons, you might want to keep several different kernel configurations
available on a single S/390 system. If you have saved a previous configuration in a
file other than the kernel’s default, entering the name of the file here will allow
you to modify that configuration.
┌─────────────────────────────────────────────────────┐
│ Enter a filename to which this configuration │
│ should be saved as an alternate. Leave blank to │
│ abort. │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────┤
│ < Ok > < Help > │
└─────────────────────────────────────────────────────┘
Exit ’menuconfig’
When you have completed your modifications to the kernel, you are asked
whether you want to save the new kernel configuration. Normally, you would
respond by selecting the Yes option, but you might have made modifications that
you do not want to keep. In that case you can exit the configuration process
without saving the changes by selecting the No option.
┌──────────────────────────────────────────────────────────┐
│ Do you wish to save your new kernel configuration? │
├──────────────────────────────────────────────────────────┤
│ < Yes > < No > │
└──────────────────────────────────────────────────────────┘

Chapter 15. Kernel parameter options
The LINUX for S/390 specific kernel parameter options are described in the
following sections:
v “IEEE FPU emulation”
v “IPL method generated into head.S” on page 124
v “Support for ECKD disks” on page 125
v “IUCV device support” on page 127
v “Console output on hardware console” on page 129.
IEEE FPU emulation

Configuration option
CONFIG_IEEEFPU_EMULATION
Capable of being a module? -- (Module Name)
No
Value Required by LINUX for S/390
Dependent on S/390 version, see Description
Description
With S/390 versions G5 and G6 (or newer), the S/390 systems are capable
of calculating floating point numbers in IEEE-format.
LINUX for S/390 provides an IEEE floating point emulation. This can be
configured on, enter (Y) or off, enter (N) during kernel compilation time. If
you have IEEE-emulation configured on, floating point arithmetic can be
performed on any S/390 system, however it will be slow on those systems
using the emulation.
On S/390 versions G3, G4 (or elder ones) you must run with
IEEE-emulation configured on (Y).
On S/390 versions G5, G6 (or newer) you can make use of the hardware
IEEE-arithmetic. VM has to be enabled to allow it to use and provide the
hardware IEEE-arithmetic. This occurs automatically when you are running
VM 2.4 or you have VM 2.3 with a PTF applied that enables the

IEEE-arithmetic. If you do not have VM 2.4 or did not apply the PTF to
VM 2.3, then you still can (and have to) rely on the IEEE-emulation as on
the older S/390 systems.
Built-in IPL record support

CONFIG_IPL
No
Yes
Description
With this option turned on an IPL loader is generated at the start of the
kernel image. That makes it possible to ’boot’ from the kernel image
directly without the need of a separate loader. This makes sense for a
medium that is sequentially read from the start at IPL time like a (VM)
reader or a tape. The type of the loader generated to the head of the kernel
image is chosen by the ’IPL method generated into head.S’ selection.
IPL method generated into head.S

CONFIG_IPL_VM
No
See Description
Description
There are two loaders available for the generation into the kernel. ’tape’
selects the loader for an IPL from a tape device, ’vm_reader’ selects the
loader for an IPL from a VM virtual reader.
Support for VM minidisk

CONFIG_MDISK
No
No
Description
This option is used under VM only. With this flag enabled (Y) your S/390
can use a reserved minidisk under VM. VM internally uses the DIAG 250
to access the minidisk. When this boot parameter is enabled, several
parameters (the virtual device ID, the size, offset and blocksize) must be
passed to the kernel parameter file for each device. The minidisk must be
formatted and reserved under VM/CMS.
When you are running a native installation, you would use
CONFIG_DASD to configure your DASD.

Support for synchronous read-write
CONFIG_MDISK_SYNC
No
No, VM only
Description
This option is used under VM only. You can make the minidisk operation
synchronous. Normally a DIAG 250 is issued to start an I/O operation and
the finish of the operation is reported with an external interrupt. With this
flag enabled (Y), the DIAG 250 is issued synchronously.
Support for DASD devices

CONFIG_DASD
dasd_mod.o
See Description
Description
This is used mainly in native installations.
Enable this option (Y) to support access to S/390 hard disks called DASD
(Direct Access Storage Device). You must enable this option to have disk
access on a native/LPAR system. Running under VM you can alternatively
choose CONFIG_MDISK.
When enabled (Y), this option lets you specify additional options for
DASD access, see “Support for ECKD disks”.
Support for ECKD disks

CONFIG_DASD_ECKD
No
See Description
Description
This is used mainly in native installations.
Enable this option (Y) if you have ECKD-type DASDs like IBM 3380s or
3390s. ECKD devices are the most commonly used devices in S/390, so
you should enable this option unless you are very sure you do not have
any ECKD devices.
This option is a subordinate of CONFIG_DASD, see “Support for DASD
devices”.
Chapter 15. Kernel parameter options 125

Support for FBA disks
CONFIG_DASD_FBA
No
See Description
Description
This is used mainly under VM/ESA for the virtual disk in storage
VFB-512. Enable this option (Y) if you want to access your FBA devices
(for example, the virtual disk in storage of VM/ESA).
devices” on page 125.
Support for DIAG access to CMS reserved minidisk

CONFIG_DASD_MDSK
No
See Description
Description
This is applicable under VM/ESA only. Enable this option (Y) if you want
to access your disks by means of VM/ESA’s DIAG250 opcode instead of
CCW execution. You might want to do this, if CCW access to your device
is currently unsupported under LINUX for S/390 or you require the
additional capabilities of VM/ESA such as cross-guest DASD caching or
enhanced error recovery.
devices” on page 125.
XPRAM device support

CONFIG_XPRAM
xpram.o
See Description
Description
This is used to allow more than 2 GB of main storage to be accessed by
LINUX for S/390. Enable this option (Y) to support access to expanded
storage of up to 16 TB (S/390 hardware currently supports 64 GB). The
expanded storage can be subdivided into partitions.
Read the Device Driver description for more information.

LCS device support
CONFIG_LCS
lcs.o
See Description
Description
LAN Channel Station (LCS) defines the methodology that is used by
TCP/IP S/390 operating systems to control the operation of Local Area
Networks (LAN) resident in a local adapter such as the Open Systems
Adapter (OSA) or a channel attached platform such as the 3172. If you
want to use a LAN under LINUX, enter (Y) here.
Read the LINUX for S/390: LCS Device Driver document for more
information.
CTC device support

CONFIG_CTC
No
No
Description
If you want to use channel connections under LINUX, enter (Y) here. This
gives you the possibility to make TCP/IP connections via virtual, parallel
or ESCON channels between LINUX for S/390 and other S/390 operating
systems (LINUX for S/390, OS/390, VM/ESA and VSE/ESA).
IUCV device support

CONFIG_IUCV
No
No
Description
This is a VM only device driver. Enter (Y) to enable a fast communication
between VM user IDs. At boot the VM user ID need to be passed to the
kernel. Using ifconfig a point-to-point connection can be established to
the LINUX for S/390 system running on the other VM user ID. Note that
both kernels need to be compiled with this option and both need to be
booted with the user ID of the other VM account.

Support for 3215 line mode terminal
CONFIG_3215
No
No
Description
The 3215 console driver is used to read and write to a 3215 line mode
console. Real 3215 devices are no longer available in an S/390
environment, therefore the 3215 driver can only be used under VM. On a
native S/390 system the initialization function of the 3215 driver returns
without registering the driver to the system.
Entering (Y) to this option switches on the compilation of parts 1) and 2) of
the 3215 terminal driver. The option makes it possible to use “Support for
console output on 3215 line mode terminal”.
Support for console output on 3215 line mode terminal

CONFIG_3215_CONSOLE
No
No
Description
This option is subordinate to “Support for 3215 line mode terminal”.
This option enables console output on the first 3215 console in the system.
It prints kernel errors and kernel warnings to the 3215 terminal in addition
to the normal output on the TTY device.
Support for hardware console

CONFIG_HWC
No
See Description
Description
The hardware console is an alternative terminal, usually required for a
native LINUX for S/390 installation although it is also run under VM.
You would normally enter (Y) for this option in a native installation if your
hardware configuration includes a hardware console. In a VM installation,
without a hardware console, you would normally enter (N).

Console output on hardware console
CONFIG_HWC_CONSOLE
No
No
Description
This option is subordinate to “Support for hardware console” on page 128.
This option enables console output on the first hardware console in the
system. It prints kernel errors and kernel warnings to the hardware console
in addition to the normal output on the TTY device.

Part 5. Reference information
Chapter 16. Using LINUX for S/390 device Using the 3215 . . . . . . . . . . . . 146
drivers . . . . . . . . . . . . . . . 133 Special characters: . . . . . . . . . . 146
Common device support . . . . . . . . . 133 3270 emulation . . . . . . . . . . . 146
Hardware console . . . . . . . . . . . . 147
Chapter 17. LINUX for S/390 device drivers . . 135 Features . . . . . . . . . . . . . . 147
DASD . . . . . . . . . . . . . . . . 135 Special characters: . . . . . . . . . . 147
Features . . . . . . . . . . . . . . 135 Limitations . . . . . . . . . . . . . 148
Limitations . . . . . . . . . . . . . 135 Usage . . . . . . . . . . . . . . . 148
Example . . . . . . . . . . . . . . 137 Chapter 18. FAQs . . . . . . . . . . . 151
Using DASD . . . . . . . . . . . . 137 Do I have a G3 or above processor? . . . . . . 151
VM minidisk . . . . . . . . . . . . . 138 How do I edit a file using the hardware or 3215
Features . . . . . . . . . . . . . . 138 consoles? . . . . . . . . . . . . . . . 151
Kernel parameter syntax. . . . . . . . . 138 How do I set up TCP/IP under VM using IUCV? 152
Example . . . . . . . . . . . . . . 139 Setting up TCP/IP on the VM host with IUCV 152
Optional items . . . . . . . . . . . . 139 Modify parm line . . . . . . . . . . . 153
XPRAM . . . . . . . . . . . . . . . 139 Modify your user directory . . . . . . . . 153
Features . . . . . . . . . . . . . . 139 How do I boot from a VM reader? . . . . . . 153
Limitations . . . . . . . . . . . . . 139 How do I enter CP commands in a running LINUX
Kernel parameter syntax. . . . . . . . . 139 environment? . . . . . . . . . . . . . 154
Example . . . . . . . . . . . . . 140 Is the network interface card working on my
Module parameter syntax . . . . . . . . 140 MP3000? . . . . . . . . . . . . . . . 154
Example . . . . . . . . . . . . . 140
CTC/ESCON . . . . . . . . . . . . . 141 Chapter 19. LINUX for S/390 references. . . . 155
Features . . . . . . . . . . . . . . 141 LINUX documents . . . . . . . . . . . 155
Limitations . . . . . . . . . . . . . 141 S/390 documents . . . . . . . . . . . . 155
Example . . . . . . . . . . . . . . 142 Chapter 20. execs, shell scripts, and tools. . . 157
Activation of the CTC connection . . . . . 142 netsetup . . . . . . . . . . . . . . . 157
Recovery procedure after a crash . . . . . . 143 silo . . . . . . . . . . . . . . . . . 159
IUCV . . . . . . . . . . . . . . . . 144 Usage . . . . . . . . . . . . . . . 159
Limitations . . . . . . . . . . . . . 144 Parameters . . . . . . . . . . . . . 160
Optional items . . . . . . . . . . . . 144 Additional keywords . . . . . . . . . . 160
VM side (TCP/IP service machine) . . . . 144 dasdfmt . . . . . . . . . . . . . . . 161
LINUX side (VM guest user ID) . . . . . 144
3215 line mode terminal . . . . . . . . . . 145 Chapter 21. File system .tar file contents . . . 163
Features . . . . . . . . . . . . . . 145 initfs_small.tgz . . . . . . . . . . . . . 163
Limitations . . . . . . . . . . . . . 145 initfs_big.tgz . . . . . . . . . . . . . 164
Example . . . . . . . . . . . . . 146

Chapter 16. Using LINUX for S/390 device drivers
This chapter describes the device drivers specific to the LINUX for S/390 kernel. A
description of how to build the kernel using these device drivers is given in
“Part 4. Kernel building” on page 99. For more specific information about the
device driver structure, see the documents in the kernel source tree at,
linux/Documentation/s390. Other useful information sources are listed in
“Chapter 19. LINUX for S/390 references” on page 155.

v You are familiar with LINUX device driver descriptions
v You are familiar with the S/390 devices attached to your system.
Common device support

Because the ESA/390 architecture is different from that used by the Intel PC, the
I/O concepts used by S/390 device drivers are also different.
LINUX was originally designed for the Intel PC architecture which uses two
cascaded 8259 programmable interrupt controllers (PIC) that allow a maximum of
15 different interrupt lines. All devices attached to that type of system share those
15 interrupt levels (or IRQs). In addition, the bus systems (ISA, MCA, EISA, PCI,
etc.) might allow shared interrupts, different polling methods, DMA processing,
etc.
Unlike other hardware device architectures, ESA/390 implements a channel

subsystem that provides a unified view of the devices attached to the system.
Although a large variety of peripheral attachments are defined for the ESA/390
architecture, they are all accessed in the same manner using I/O interrupts. Every
single device attached to the system is uniquely identified by a subchannel and the
ESA/390 architecture allows up to 64K devices to be attached.
In order to avoid the introduction of a new I/O concept to the common LINUX
code, LINUX for S/390 preserves the IRQ concept and semantically maps the
ESA/390 subchannels to LINUX as IRQs. This allows LINUX for S/390 to support
up to 64K different IRQs, each representing a unique device.
The unified I/O access method used by LINUX for S/390 allows the operating
system to implement all of the hardware I/O attachment functionality that each
device driver would otherwise have to provide itself. A common I/O device driver
is provided which uses a functional layer to provide a generic access method to
the hardware. The driver comprises a set of I/O support routines, some of which
are common LINUX interfaces, while others are LINUX for S/390 specific:
get_dev_info()
Allows a device driver to find out what devices are attached (visible) to
the system, and to determine their current status.
request_irq()
Assigns the ownership of a specific device to a device driver.
free_irq()
Releases the ownership of a specific device.

disable_irq()
Prevents a specific device from presenting interrupts to the device driver.
enable_irq()
Allows a device to present I/O interrupts to the device driver.
do_IO()
Initiates an I/O request.
halt_IO()
Terminates the I/O request that is currently being processed by the device.
do_IRQ()
This is an interrupt pre-processing routine that is called by the interrupt
entry routine whenever an I/O interrupt is presented to the system. The
do_IO() routine determines the interrupt status and calls the device specific
interrupt handler according to the rules (flags) defined by do_IO().

Chapter 17. LINUX for S/390 device drivers
This chapter describes how to use the device drivers in a comprehensive manner
and divides the information into the following sections:
v “DASD”
v “VM minidisk” on page 138
v “XPRAM” on page 139
v “CTC/ESCON” on page 141
v “IUCV” on page 144
v “3215 line mode terminal” on page 145
v “Hardware console” on page 147.
DASD
S/390 disk devices, DASDs (Direct Access Storage Device) are managed by LINUX
for S/390 via the DASD device driver. It is valid for all types of DASDs and
represents them to LINUX for S/390 as block devices, namely ″dasd″. Currently
the DASD driver uses a single major number (94) and 4 minor numbers per
volume (1 for the physical volume and 3 for partitions). Thus you can have up to
64 DASD devices in your system.
Features
The driver currently supports ECKD-devices, FBA-devices, and (under VM/ESA)
any DASD devices supported by VM/ESA, by means of DIAG 250 access.
Limitations
We performed our testing on IBM 3380 and 3390 type disks of different sizes,
under VM and on the bare hardware (LPAR), using internal disks of the Multiprise
as well as a RAMAC virtual array. Additionally we have 9345 beta-support,
although it appears to be stable, we have not tested an IPL from 9345. Virtual
ECKD-type disks exported by an Enterprise Storage Server (Seascape), or by
RAMAC and RAMAC RVA, should work fine as well.
We have also tested using a VM/ESA virtual disk as an FBA-device.
We currently implement one partition per volume, which is the whole volume,
skipping the first blocks according to the scheme outlined in Figure 16 on page 136.

Figure 16. DASD partitioning scheme
These are reserved for IPL records and IBM’s volume label to assure accessibility of
the DASD from other operating systems (OS). In a later stage we will provide
support of partitions, perhaps VTOC oriented or using a kind of partition table in
the label record.
Note that the dasdfmt utility is only able to format DASDs that have already been
formatted using another disk formatting utility. If you have unformatted DASD in
your system, use a device support facility such as ICKDSF to initially format the
DASD.
Because the full set of S/390 error recovery actions are not implemented, you may
encounter problems if you use DASDs with faulty tracks or records, particularly
old 3380 and 3390 devices.
OS/390 will flag the DASD devices as RESERVE during a backup.
The size of any swap device or file may not exceed 2 GB. Similarly, the limit for
the main memory that can be defined is slightly less than 2 GB. Refer to “XPRAM”
on page 139 for information about the expanded memory capability.
The gcc compiler flag '-fno-caller-saves' must be set.
Kernel parameter syntax

The DASD driver is configured by a kernel parameter added to the parameter line:
dasd=range[,...] | autodetect | probeonly
where:
v range is either of the form from-to or devno.
v autodetect | probeonly determines whether DASDs are actually registered to
LINUX for S/390 (autodetect) or whether you are just inspecting the set of
DASDs to see if they can be registered (probeonly).
probeonly is the default and causes messages to be written to the log for each
device that can be accessed by LINUX for S/390. autodetect causes the devices
to be ordered by subchannel number in ascending order.

The kernel parameter dasd=from-to,... can be issued an arbitrary number of
times in the kernel’s parameter line, or not issued at all. The from and to
parameters must be given in hexadecimal notation without a leading 0x.
If you supply one or more kernel parameters dasd=from-to,..., the different

instances are processed in order of appearance. A minor number is reserved for
any DASD device that you specify, up to the maximum of 64 volumes. Additional
DASDs are ignored. If you do not supply the dasd=from-to,... kernel parameter,
the DASD driver registers all supported DASDs of your system by allocating them
a minor number (in ascending order) of the subchannel number.
An additional DASD parameter causes the DASD driver to use DIAG 250
commands to perform I/O on the devices included in the range:
dasd_force_diag=range[,...]
where range is either of the form from-to or devno.
The specified devices must be CMS formatted and it is strongly recommended that
they are also CMS reserved. The device numbers should have been included in a
preceding dasd=range statement to avoid confusion.
Example
dasd=192-195,5a10 dasd_force_diag=194
This reserves minor numbers 0, 4, 8, and 12 for device numbers 192, 193, 194, and
195 respectively. Device 5a10 is made accessible at minor number 16 (/dev/dasde)
and the storage available for the file system is made available at minor number 17
(/dev/dasde1).
Device 194 is accessed by means of VMs CMS opcode DIAG 250 instead of by
channel programs.
Using DASD
Before using an ECKD type DASD as a LINUX for S/390 hard disk you have to
low-level format the disk. This should be done using LINUX for S/390 by issuing
an ioctl called BIODASDFORMAT on the file descriptor of the opened volume
/dev/dasd<letter>. The provided utility dasdfmt is an interface to this ioctl which
does some additional checks.
Caution: Using dasdfmt as well as the raw ioctl can accidentally destroy your
running LINUX for S/390 and you will have to reinstall from scratch. See the
help given by dasdfmt - help for further information. The dasdfmt utility consists
of several processes. Take care to allow sufficient time for each process to end
before attempting to enter an additional command. The formatting process can
take quite a long time depending on the size of the hard disk.
Before using a DASD as a LINUX for S/390 disk, you have to create a file system
on it. You should build an ext2-file system on each device unless you want to use
it as a swap device or paging space. Then you should create a swap-file system on
that device.
Note that the blocksize of the file system must be larger than (or equal to) the
blocksize given to the dasdfmt command. It is recommended that the two
blocksize values are equal.
Chapter 17. LINUX for S/390 device drivers 137

Alternatively:
v Low-level format
Before using an ECKD-DASD as a LINUX hard disk you have to low-level
format the tracks by issuing the BLKDASDFORMAT-ioctl on that device. This will
erase any data on that volume including IBM volume labels, VTOCs etc. The
ioctl can take a struct format_data * or NULL as an argument.
typedef struct {
int start_unit;
int stop_unit;
int blksize;
} format_data_t;
When a NULL argument is passed to the BLKDASDFORMAT_ioctl the whole disk is

formatted to a blocksize of 4096 bytes. Otherwise start_unit and stop_unit are
the first and last track to be formatted. If stop_unit is -1 it implies that the
DASD is formatted from start_unit up to the last track. blksize can be any
power of two between 512 and 4096. We recommend you set blksize to 1024 or
higher (ideally 4096) because the ext2fs file system uses 1KB blocks and you
gain approximately 50% of capacity increasing your blksize from 512 byte to
1KB.
v Make a file system
Then you can mk??fs the file system of your choice on that volume or partition
(?? are wildcard characters). For reasons of sanity you should build your file
system on the partition /dev/dasd?1 instead of the whole volume. You lose 3
blocks of disk space, but can be sure that you can reuse your data after the
introduction of a real partition table.
v /proc/dasd files
The file /proc/dasd/devices shows available DASDs and some parameters like
the hard sector size (blocksize of format). The files /proc/dasd/statistics and
/proc/dasd/debug are not used in the current context but are useful for
debugging reasons.
You must have CONFIG_DASD, CONFIG_DASD_ECKD, CONFIG_DASD_FBA, and
CONFIG_DASD_MDSK, enabled in the configuration of your current kernel to access
IBM DASDs.
VM minidisk
Under VM it is possible to divide DASDs into logical partitions, so-called
minidisks. These minidisks have a unique 16 bit identification, the virtual device
number. Each virtual device can be formatted from VM and used with the CMS
file system. Also, it is possible to create a reserved minidisk, which creates one big
file the size of the whole virtual device. This reserved file can be written to under
CMS and be accessed with a special Opcode DIAG 250 in a block device manner.
Features
A reserved minidisk must be formatted with a blocksize of 512 bytes, 1KB, 2KB or
4KB. It may have any size.

The kernel parameters can be copied into the LINUX parameter file.
mdisk=vdev

where:
vdev virtual device number as hex number
It is possible to have more than one mdisk= statement in the LINUX PARM file, the
assignment to the minor number of device will be in order of the statements.
Example
The command:
mdisk=193,194
Optional items
A reserved minidisk is created with the following steps:
1. Format minidisk with blocksize x
2. Reserve minidisk
Example:
format 192 b (blksize 4096
reserve mnda mnda b
XPRAM
The S/390 architecture supports more RAM than can be accessed as main memory.
The LINUX for S/390 main memory is limited to 2 GB. However, additional
memory can be declared as expanded storage. The S/390 architecture allows
applications to access up to 16 TB of expanded storage (although the current
hardware can only be equipped with up to 64 GB memory). Memory in the
expanded storage range can be copied in 4 KB blocks to, or from, the main
memory.
An interesting feature of expanded storage is that is persistent with respect to IPLs

(booting) but volatile with respect to IMLs (power off/on).
The XPRAM device driver is a block device driver that supports LINUX for S/390
allowing it to access the expanded storage. Thus XPRAM can be used as a basis for
fast swap devices and/or fast file systems.
Features
XPRAM automatically detects whether expanded storage is available on the
system. The expanded storage can be subdivided into up to 32 partitions, the
default being a single partition. The XPRAM device driver has major number 35.
The partitions have minor numbers 0 through 31. The hard sector size of XPRAM
is set to 4096 bytes.
Limitations
If expanded storage is not available, XPRAM cannot be used. Its initialization fails
gracefully with a log message reporting the lack of expanded storage.

The kernel parameter is optional. The default defines the whole expanded storage
to be one partition.
xpram_parts=number_of_partition[,partition_size[,...]]

where number_of_partitions defines how many partitions the expanded storage is
split into. The i-th partition_size defines the size of the i-th partition. The syntax
for sizes is:
[0x]non-negative_integer[k|K|m|M|g|G]
If the 0x prefix is used the subsequent number is interpreted as a hexadecimal

value, otherwise it is interpreted as a decimal value (default). The
non-negative_integer value may be followed by a magnitude:
v k or K for kilo (1024) is the default
v m or M for Mega (1024*1024)
v g or G for Giga (1024*1024*1024)
The non-negative_integer value multiplied by its magnitude defines the
partition’s size in bytes. The default size is 0.
Any partition defined with a non-zero size is allocated the amount of memory
specified by its non-negative_integer parameter.
You can automatically allocate the remaining memory between a set of partitions
by specifying zero for the size of each partition in the set. The following formula is
used to calculate the size for each of these partitions:
(available expanded storage - sum of all non-zero sizes specified)
computed size = ----------------------------------------------------------------
number of partitions with zero sizes
This formula is only a good approximation of the actual size allocated to each
partition. Because of the requirement to assign blocks in multiples of 4K, partitions
can be larger or smaller than the estimate produced by the calculation. In addition,
there might be an amount of memory left as a ″guard space″ between two
partitions.
Example
xpram_parts=4,0x800M,0,0,0x1000M
This allocates the extended storage into four partitions. Partition 1 has 2 GB,
partition 4 has x 4 GB, and partitions 2 and 3 use equal parts of the remaining
storage. If the total amount of extended storage was 16 GB, then partitions 3 and 4
would each have approximately 5 GB.
Module parameter syntax

XPRAM may be used as module. The syntax of the module parameters passed to
insmod differs from the kernel parameter syntax:
[devs=number_of_devices [sizes=size[,size,...]]]
where:
v number_of_devices is used to define the number of partitions.
v size is a non-negative integer that defines the partition’s size. Only decimal
values are allowed and no magnitudes are accepted. The size will be interpreted
in KB.
Example
devs=4 sizes=2097152,8388608,4194304,2097152
This allocates a total of 16 GB of extended storage into four partitions, of

(respectively) size 2 GB, 8 GB, 4 GB, and 2 GB.

CTC/ESCON
A CTC or an ESCON connection are the typical high speed connections between
mainframes. The difference between them is the media type which is used to
transfer the data. The data packages and the protocol on both media are the same.
v The CTC channel uses a copper cable to connect from one mainframe to the
other. The signals are transferred on parallel cables, like the PLIP device driver
does. These connections are no longer used between mainframes. Nowadays the
CTC connection is only used as a virtual CTC. A virtual CTC is a connection
inside a VM system. A virtual CTC can be used to connect two LINUX for S/390
systems running under VM or a LINUX for S/390 system with the TCP/IP
running under VM.
v An ESCON channel uses a fibre optic connection and the signals are passed in
sequence over the connection. These connections are used to connect two
mainframes where each system runs in its own box or in an LPAR.
The LINUX for S/390 CTC/ESCON device driver is a network device, which uses
TCP/IP to connect different operating systems together (OS/390, VM, VSE or a
LINUX on S/390). One ctcn or esconn network device needs two dedicated
channels of the same type. One channel is used for read the other for write. Both
physical channels are mapped to one logical network device. The following picture
shows the connection of two systems via CTC:
Figure 17. Connection of two systems via CTC
The current implementation of the CTC network device driver can handle up to 8
CTC connections and/or 8 ESCON connections. In autosense mode the driver
always picks 16 parallel/ESCON channels with the lowest sub-channel IDs. When
a CTC definition is in the kernel parameter file, the channels have to be in the first
64 CTC/ESCON sub-channel ID’s. This value (MAX_CHANNEL_DEVICES) can be
changed in the ctc.c file.
Features
Can be configured from a kernel parameter line.
Limitations
This CTC option cannot be specified in the kernel parameter file which is used as
input for SILO on native systems. If it is specified, LINUX for S/390 cannot be
booted. A solution for this problem is to define the CTC Adapters as two adjacent
3088s in the IOCS. The following example defines the CTC IODEVICE for the two
systems:
v System A:
IODEVICE ADDRESS=(500,2),CUNUMBR=001, x
UNIT=CTC,UNITADD=0

v System B:
UNIT=CTC,UNITADD=1
UNIT=CTC,UNITADD=0

Normally the CTC driver selects the channels in order (automatic channel
selection). If you need to use the channels in a different order or do not want to
use automatic channel selection with your installation, you can make these choices
using the ctc= kernel keyword.
ctc=0,0xrrrr,0xwwww,dddd
Where:
v rrrr is the read channel address
v wwww is the write channel address
v dddd is the network device (ctc0 to ctc7 for a parallel channel, escon0 to escon7
for ESCON channels).
To switch the automatic channel selection off, use the ctc= keyword with the
parameter noauto. This might be necessary if your installation uses 3271 devices or
other devices that use the CTC device type and model, but operate with a different
protocol.
ctc=noauto
Note that the CTC kernel parameter must be written to the parameter file:
v If you are using a native installation, this is parameter -p in the silo parameter
file
v For a VM installation, include the parameter in the parm.line file
Example
For one network drive:
ctc=0,0x600,0x601,ctc0
Or for two network devices:

ctc=0,0x601,0x600,ctc0 ctc=0,0x605,0x608,escon3
Activation of the CTC connection

1. Connection
Prior to the activation, there is a channel connection required. This can be a real
connection or a virtual:
v Real Channels
Connect the systems with a pair of channels to the remote system. Verify that
both times, the read channel is connected to the write channel.
v VM Channels
Define two virtual channels to your user ID. This can be done with the
following commands:
def ctc c04
def ctc c05

Connect the virtual channels with the channels from the VM TCP/IP user ID.
You have to couple the read channel to the VM TCP/IP write channel and
the write channel to the VM TCP/IP read channel. The coupling can be done
with the following commands:
couple c04 tcpip c05
couple c05 tcpip c04
The VM TCP/IP channel numbers depend on the customization at the

Remote Side. In this example, the CTC read channel c04 is connected to the
VM TCP/IP write channel c05. Similarly, CTC write (c05) is connected to VM
TCP/IP read (c04).
You can write the def and couple commands into the profile dataset.
Instead of connecting to the VM TCP/IP user ID, you can also connect to
another VM user ID, where a LINUX for S/390, OS/390 or VSE is running.
Note: In this case the Remote Side also needs to be a VM Guest

2. Definitions on the Remote Side
Setup the TCP/IP on the remote side, as described in the reference manuals.
This can varying depending of the different operating system which is used on
the remote side.
3. Activation on the Remote Side
Activate the channels on the remote side.
4. Activation on the LINUX for S/390 Side
The network devices can be activated with the ifconfig command. It is
necessary to define the right MTU size for the channel device, otherwise it will
not work properly. Please use the same MTU size (default 1500) that is defined
on the remote side:
ifconfig ctc0 10.0.51.3 pointopoint 10.0.50.1 netmask 255.0.0.0 mtu 32760
Where:
10.0.51.3
is the IP address of the local network device. (ctc0 to ctc7 or escon0 to
escon7)
10.0.50.1
is the IP address of the remote side.
Remember that the keyword in the ifconfig command changes from ctc to
escon when a native installation is performed. For example:
ifconfig escon0 10.0.0.1 pointopoint 10.0.50.1 netmask 255.0.0.0 mtu 32760
Recovery procedure after a crash

In a native LINUX for S/390 system, if one system of a CTC connection crashes, it
is not possible to simply reconnect to the remote CTC side after a reboot. The
correct procedure is:
1. Stop the CTC connection on the LINUX for S/390 side using:
ifconfig escon0 down
2. Activate the channels on the remote side.
3. Activate the channels on the LINUX for S/390 side, for example:
ifconfig escon0 10.0.0.1 pointopoint 10.0.50.1 netmask 255.0.0.0 mtu 32760

IUCV
The Inter User Communication Vehicle (IUCV) is a communication facility that
allows a program running in a virtual machine to communicate with other virtual
machines, with a control program or even with itself.
The communication takes place over a predefined linkage called a path. Each
virtual machine can have multiple paths and can receive and send multiple
messages on the same path simultaneously.
The LINUX for S/390 IUCV device driver is a network device, which uses IUCV to
connect LINUX kernels running on different VM user IDs or to connect a LINUX
kernel to a TCP/IP service machine. The TCP/IP service machine serves as a
gateway to the network, if properly configured.
The following picture shows the possible connection of two LINUX for S/390
machines:
Figure 18. Connection of two systems using IUCV
Limitations
To use this driver, a running TCP/IP service machine is required on the one side,
and on the other side, LINUX for S/390 must be running under VM.
Optional items
VM side (TCP/IP service machine)
The standard definitions in the VM TCP/IP configuration files apply.
For more information of the VM TCP/IP configuration see: TCP/IP V2R4 for VM:
Plan and Cust (SC31608203)
LINUX side (VM guest user ID)

To use this driver the following configuration commands must be issued:
v The PARM file must include the user ID you want to connect to, for example:
iucv=userid0,userid1,...

this can also be the TCP/IP service machine’s user ID TCP/IP.
v Communication via TCP/IP service machine.
Enter:
>ifconfig iucv0 <your TCP address> pointopoint <address service machine> [options]<
– pointopoint is required to establish a p-to-p connection to a service machine
– optional options (for example, netmask 255.255.0.0).
Enter:
>route add -net default iucv0<
– to add default route.
If not already started during boot: >inetd&< to start demon processes.
Now start Telnet or FTP or...

v direct user-to-user (guest-to-guest) communication.
Enter:
ifconfig iucv0 <guest 0 TCP address> pointopoint <guest 1 TCP address>
(on guest 0)
Enter:
ifconfig iucv0 <guest 1 TCP address> pointopoint <guest 0 TCP address>
(on guest 1)start working...
3215 line mode terminal

The 3215 terminal device driver makes it possible to use a 3270 terminal in 3215
emulation mode as a line-mode terminal with LINUX for S/390.
If both the 3215 and Hardware console are compiled into the kernel, the
appropriate console will be chosen at run-time according to the environment:
v In VM, the 3215 console will be enabled and the Hardware console suppressed.
v In an LPAR or native environment, the Hardware console will be enabled and
the 3215 suppressed.
The intended use of the 3215 terminal device driver is solely to launch LINUX.
When LINUX is running, the user should access LINUX for S/390 via Telnet,
because the terminal is a line-mode terminal and is unable to support applications
such as vi. Therefore it is strongly recommended that you assign dump to the TERM
environment variable so that at least applications like less give appropriate
output.
Features
v Provides a line mode typewriter terminal.
v Console output on the first 3215 terminal.
Limitations
This driver only works in combination with VM. In a single image or in LPAR
mode the 3215 terminal device driver initialization function just exists without
registering the driver.

Due to a problem with the translation of code pages (500, 037) on the host, the
pipe command ( |) cannot be intercepted by the console. If you need to use this
command, execute it from a Telnet session.

The 3215 console device driver does not require any parameters if it is used under
VM. If it is used with a P/390 system, you have to specify the condev kernel
parameter. This supplies the device driver with the subchannel number of the 3215
device. The reason that you need this parameter is that there is no simple way to
recognize a 3215 device attached to a P/390.
The kernel parameter syntax is:

condev=cuu
where cuu is the device Control Unit and Unit address, and is a hexadecimal
number (preceded by 0x).
Example
condev=0x001f
This forces the 3215 device driver to use the device number 0x1f for its 3215
device (the prefix 0x denotes a hexadecimal number).
Using the 3215

A 3215 terminal is a line mode terminal. The user enters a complete line and
presses enter to let the system know that a line has been completed. The device
driver then issues a read to get the completed line, adds a new line and hands
over the input to the generic TTY routines.
Special characters:
The 3215 terminal does not have a control key. That makes it impossible to enter
control characters directly. To be able to enter at least some of the more important
control characters, the character | can have a special meaning. There are four cases:
v The two character input line |c is interpreted as a Ctrl+C. This is used to cancel
the process that is currently running in the foreground of the terminal.
v The two character input line |d is interpreted as a Ctrl+D. This is used to
generate an end of file (EOF) indication.
v The two character input line |z is interpreted as a Ctrl+Z. This is used to stop a
process.
v The two characters |n at the end of an input line suppresses the automatic
generation of a new line. This makes it possible to enter single characters, for
example those characters that are needed for yes/no answers in the ext2 file
system utilities.
If the special characters don’t seem to work, make sure you have the correct
codepage in your terminal emulator. One that works is codepage 037 United States.
3270 emulation
If you are accessing the console using x3270, then you should add the following
settings to the .XDefaults file in order to get the correct code translation:
! X3270 keymap and charset settings for Linux
x3270.charset: us-intl
x3270.keymap: circumfix
x3270.keymap.circumfix: :<key>asciicircum: Key("|")\n

Hardware console
The hardware console is an alternative terminal, usually required for a native
LINUX for S/390 installation although it is also run under VM. If both the 3215
and Hardware console are compiled into the kernel, the appropriate console will
be chosen at run-time according to the environment:
v In VM, the 3215 console will be enabled and the Hardware console suppressed.
v In an LPAR or native environment, the Hardware console will be enabled and
the 3215 suppressed.
The intended use of the hardware console device driver is solely to launch LINUX.
When LINUX is running, the user should access LINUX for S/390 via Telnet,
because the console is a line-mode terminal and is unable to support applications
such as vi. Therefore it is strongly recommended that you assign dump to the TERM
environment variable so that at least applications like less give appropriate
output.
The hardware console driver code is separated into three different files plus header
files - one for the low level hardware console handling, another one to make use of
the low level driver as a LINUX console and the third one as a bridge between the
generic terminal code of the kernel and the low level hardware console driver.
Note that there are different options that must be selected during kernel
configuration to enable the LINUX terminal on the Hardware console and to
enable the LINUX console on the Hardware console.
The feature of the hardware console driver is the ability to support the kernel and
user space in parallel. Accordingly there are two different interfaces within the
kernel: console and terminal (short: TTY) to interact with the hardware console
driver. The TTY processes all output requests from outside of the kernel - user
space - the consoles write only kernel messages, but are not able to get input from
the operator.
Features
The hardware console uses a small subset of the hardware console API to interact
with a command interface on the SA/SE (stand alone support element) or a
connected HMC (hardware management console).
Special characters:
The Hardware console does not have a control key. That makes it impossible to
enter control characters directly. To be able to enter at least some of the more
important control characters, the character | can have a special meaning. There are
four cases:
v The two character input line |c is interpreted as a Ctrl+C. This is used to cancel
the process that is currently running in the foreground of the terminal.
v The two character input line |d is interpreted as a Ctrl+D. This is used to
generate an end of file (EOF) indication.
v The two character input line |z is interpreted as a Ctrl+Z. This is used to stop a
process.
v The two characters |n at the end of an input line suppresses the automatic
generation of a new line. This makes it possible to enter single characters, for
example those characters that are needed for yes/no answers in the ext2 file
system utilities.

If the special characters don’t seem to work, make sure you have the correct
codepage in your terminal emulator. One that works under VM is codepage 037
United States.
Under VM make sure that the 3270 emulator session (e.g. PCCOM) is configured
correctly with the codepage 037 United States in order to accept the special keys
(Ctrl-keys like |c, |d, etc.).
The ENTER key is simulated by entering:

#CP VI VMSG \n
The SPACE key is simulated by entering:

#CP VI VMSG \n (a blank followed by a \n).
Limitations
v Displaying large files might cause some missing sections within the output
because of the latency of the hardware interface employed by the device.
v In native or LPAR environments, you occasionally have to use the Delete button
of the GUI on the Service Element or Hardware Management Console to enable
further output. This is relevant to:
– SE version 1.6.1 or older on G5, G6, and Multiprise 3000.
– SE version 1.5.2 or older on G3, G4, and Multiprise 2000.
v Messages concerning the Hardware console operation that are generated by the
Hardware console driver, cannot be provided to the syslog and are therefore
unavailable with dmesg.
v Output from the head/top is deleted if the amount exceeds approximately 30
Kbyte per LPAR (or image) on SE or HMC.
v Applications such as vi are not supported because of the HWC’s line-mode
nature.
Usage
When you use the hardware console driver running under VM it is important to
consider how the input is handled. Instead of writing into the suitable field within
the graphical user interface at the service element you have to use the
VInput-command provided by VM. Please have a look at the following examples
that are written at the input line of a 3270-Terminal or 3270-Terminal-Emulation
(for example, x3270).
Note that, in the examples, capitals within VInput and its parameters processed by
VM/CP mask the entries you have to make. The lower case letters are optional
and are shown for readability.
VInput VMSG ls -l
(the bash will call ls -l after this command was sent via VInput to the hardware
console as a non-priority command - VMSG).
VInput PVMSG echo *
(the bash will execute echo * after this command was sent via VInput to the
hardware console as a priority command - PVMSG).

The hardware console driver is capable to accept both if supported by the
hardware console within the specific machine/VM. Please inspect your boot
messages to check the Hardware console’s capability to cope with non-priority or
priority commands respectively on your specific machine. Remember the
Hardware console’s inability to make its own messages available via dmesg.
Now let us have a look at some features of VInput (found out experimentally).
1. Use ″ twice if you mean a single ″.
VInput example: VInput PVMSG echo ""Hello world, here is ""$0
(normally: echo "Hello world, here is "$0)
2. Do not use # within VInput commands.
# is interpreted as a comment character by VInput. This character and all
following characters are cut off by VInput and are invisible for the hardware
console and the hardware console driver.
3. All characters in lower case are converted by VM to upper case.
If you type VInput VMSG echo $PATH, the driver will get ECHO $PATH and will
convert it into echo $path. LINUX and the bash are case sensitive and cannot
execute such a command. To resolve this problem, the Hardware console uses a
defined character (%) under VM to distinguish between upper and lower case
characters. This behavior and the defined character (%) are adjustable at
build-time by editing the driver sources, or at run-time by use of the
ioctl-interface. Some examples:
v input: VInput VMSG ECHO $PATH
output: echo $path
v input: vi vmsg echo $%PATH%
output: echo $PATH
v input: #cp vi pvmsg echo ""%%%H%ello, here is ""$0 #name of this
process
output: CP VI PVMSG ECHO "%%%H%ELLO, HERE IS "$0
NAME OF THIS PROCESS
HCPCMD001E Unknown CP command: NAME
echo "%Hello, here is "$0
%Hello, here is -bash

Chapter 18. FAQs
The following FAQs are included to help reduce the number of service calls to
your system administrator:
v “Do I have a G3 or above processor?”
v “How do I edit a file using the hardware or 3215 consoles?”
v “How do I set up TCP/IP under VM using IUCV?” on page 152
v “How do I boot from a VM reader?” on page 153
v “How do I enter CP commands in a running LINUX environment?” on page 154
v “Is the network interface card working on my MP3000?” on page 154.
Do I have a G3 or above processor?

Question: Do I have an immediate-and-relative-instruction facility installed?
Answer: Try the following. If you get an operation exception similar to that shown
in the example below, you do not have an immediate-and-relative-instruction
facility installed.
00: SYS CLEAR
00: Storage cleared - system reset.
00: ST 8000 A71A0123 A71A0321
00: Store complete.
00: ST P 80000 80008000
00: Store complete.
00: TR INST
00: B
00: -> 00008000 AHI A71A0123
00: *** 00008000 PROG 0001 -> 00000000 OPERATION
How do I edit a file using the hardware or 3215 consoles?

Question: I need to edit a file, however, I only have the hardware console or the
3215 console.
Answer: Occasionally, you might have to edit a text file by using a line mode
console. In this case, you will have to rely on the ed editor. In other circumstances,
you might be able to use a different editor, but in the worst case scenario, you will
have to use ed.
For example, you might want to edit the file /etc/sysconfig/network.
The current content might be:

NETWORKING=yes
FORWARD_IPV4=no
HOSTNAME=test.testdomain
GATEWAYDEV=/dev/tr0
GATEWAY=192.168.1.1

If you want to change the host name and gateway, you would use the following
sequence. Enter the text shown in italic:
[you@host]$ ed /etc/sysconfig/network
110
3c
HOSTNAME=newname.domain
.
5c
GATEWAY=12.12.12.12
.
wq
100
[you@host]$
The content of the file has changed (the changes are in bold):
NETWORKING=yes
FORWARD_IPV4=no
HOSTNAME=newname.domain
GATEWAYDEV=/dev/tr0
GATEWAY=12.12.12.12
You can find some more instructions on using ed at the www address:
http://nl.linux.org/doc/user/node161.html
If you go to any UNIX or LINUX system, including LINUX for S/390, you can
enter the command man ed and get a comprehensive set of information about the
ed editor.
How do I set up TCP/IP under VM using IUCV?

Question: I need to communicate with other machines. How do I set up TCP/IP
on my VM host using IUCV?
Answer: The installation instructions assumed that you already had a TCP/IP
connection, but an example of using IUCV connections has been written by
Gordon Wolfe of Boeing. The following description is based on his information.
LINUX can communicate with other hosts using TCP/IP. There are many ways to
connect TCP/IP to LINUX for S/390, including
v real CTC
v real 3172s or CISCO routers attached to the virtual machine
v virtual CTC between the LINUX for S/390 virtual machine and the TCP/IP
machine on the host
v IUCV between TCP/IP and the LINUX virtual machine
The last two require no additional hardware, and of the two, IUCV provides
almost two and a half times the speed, up to about 500 Mb/sec. The following
describes how to set up an IUCV connection between LINUX for S/390 under VM
and the VM host’s TCP/IP stack.
Setting up TCP/IP on the VM host with IUCV

This is an additional task that you must perform in the initial activities section of
your installation. Refer to, for example, “Chapter 7. Installation using VM - IPL
from the VM reader” on page 63.
First, you will have to go to your TCP/IP communications staff and have them
assign you some IP addresses that are not being used, and create a subnet of your

VM host. You will end up with the IP address of the <your_host_name> server and
the subnet mask. This approach does not require any additional hardware, and
does not require that <your_host_name> be put in the Domain Name Server or
listed in the routers. This means that you will only be able to get to
<your_host_name> by starting a Telnet session from your VM host. Using this
setup, you will not be able to use Telnet from your PC. If you are an expert on
TCP/IP, you can probably work with your TCP/IP staff to make <your_host_name>
known to the entire local network.
In PROFILE TCPIP in the TCP/IP user ID on your VM host, add the following lines
in the appropriate sections:
HOME
<your_IP_address> <your_host_name>
;
DEVICE <your_host_name> IUCV 0 0 <your_host_name> B
LINK <your_host_name> IUCV ) <your_host_name>
;
BSDROUTINGPARMS TRUE
<your_host_name> 9216 0 <your_subnet_mask> <your_IP_address>
ENDBSDROUTINGPARMS
;
START <your_host_name>
You will have to cycle TCP/IP before this becomes effective.
Modify parm line

At a later stage, you will have to include the iucv=TCPIP parameter in your
parameter line file, for example:
mdisk=192 root=/dev/mnda ro dasd= iucv=TCPIP
Refer to, for example, “Creating additional files” on page 68 for more information
about parameter line files.
Modify your user directory

Modify your user directory (see for example, “User directory” on page 65) to
include the following:
IUCV ALLOW
IUCV ANY PRIORITY
IUCV *CCS PRIORITY MSGLIMIT 255
The IUCV statements are required to communicate with TCP/IP on your VM host.
How do I boot from a VM reader?

Question: How do I boot from a VM reader ?
Answer: You need to perform certain tasks to be able to IPL from the reader:
1. FTP the kernel image.vm.bin and rename it vmlinux.txt with record format
fixed 80.
FTP the RAM disk initrd.bin (if you have one) and rename it initrd.txt with
record format fixed 80.
2. Create a parameter file linux.parm (up to 3 records, simple text).
For example:
mdisk=192 root=/dev/mnda ro
Chapter 18. FAQs 153

3. Transfer the image(s) to the reader with the commands:
spool pun * rdr
pun vmlinux txt a ( noh
pun linux parm a ( noh
pun initrd txt a ( noh
4. Change the characteristics of the rdr file:
ch rdr <spoolids> keep nohold
5. IPL with i 00c
You need to change the reader files again (see 3) before you can re-IPL an
image that has already been loaded. The order of the files in the reader is
important. First the LINUX image, second the parameter file and third the
RAM disk. You can change the order with the VM command:
order rdr <spoolid>
Some more useful information which may save some time.

v q rdr displays the reader’s spool IDs
v purge rdr <spoolid/all> cleans out the reader
v ch rdr all keep nohold has to be done on each IPL otherwise you get an
elaborate IPL error
v locsite fix 80 in your getlin ftp script etc.
v The parameter file is EBDIC so when transferring from a PC use ASCII
v Put:
define storage 128m
ch rdr all keep nohold
in your PROFILE EXEC. If you have not defined enough storage, the kernel will
generate a prog 7 addressing exception at the beginning of the start up process
(before the console is running properly) and the console will not be able to
report the error.
Note that a much more detailed description is available, refer to “Chapter 7.

Installation using VM - IPL from the VM reader” on page 63.
How do I enter CP commands in a running LINUX environment?

Question: When running LINUX (for example in a Telnet session), how do I enter
the VM commands required during the IPL process?
Answer: Enter #cp commands on your 3215 or hardware console. For example,
#cp q userid gives you the guest name and the VM System Identifier.
Is the network interface card working on my MP3000?

Question: Why are packets not being received by the Token Ring- or
Ethernet-interface on my MP3000?
Answer: Make sure that OS/2 does not take the interface for its own TCP/IP stack.
If that is the case, either remove TCP/IP from the card or assign TCP/IP to
another card. If you reassign TCP/IP, the card must use Multi-Protocol Transport
Services (MPTS) and it must not be the first interface. The scenario that applies to
TCP/IP also applies to the NetBIOS protocol.

Chapter 19. LINUX for S/390 references
Whether you are new to LINUX, have some LINUX experience, or are a long time
UNIX expert you are going to need documentation to make the most of your
LINUX for S/390 system. The same applies if you are anything other than an
expert S/390 user.
Because it is unusual to find individuals with in-depth knowledge of both LINUX

and the S/390 architecture, we have provided some suggested reading for both
subject areas.
LINUX documents
Many useful documents have been written about LINUX, and of course UNIX
books in general are quite useful. Information is also available on-line in electronic
form if you have access to an on-line network like the Internet. A good place to
start is www.linuxresources.com.
Special mention must be made of the books of the Linux Documentation Project
which are available via anonymous FTP from the FTP site sunsite.unc.edu in the
/pub/Linux/docs subdirectory. They are also available in HTML format from its
home page on the World Wide Web at http://www.linuxdoc.org/
There are too many publications available to allow a definitive selection, but the
type of document you might find useful includes the following titles:
v Linux for Dummies — Jon ″maddog″ Hall / IDG Books Worldwide
v Linux in a Nutshell : A Desktop Quick Reference (Nutshell Handbook) — Ellen
Siever, et al / O’Reilly & Associates
v Running Linux — Matt Welsh, Lar Kaufman / O’Reilly & Associates
v Linux, Second Edition: Installation, Configuration, and Use — Michael Kofler /
Addison-Wesley Pub Co
v Red Hat Linux Unleashed — David Pitts, et al / MacMillan Publishing Company
v Slackware Linux Unleashed — Tim Parker(Editor), Timothy Parker / Sams
Publishing
v SuSE Linux 6 Unleashed (Unleashed) —Billy Ball, Daniel Robbins / Sams
Publishing
v Caldera OpenLinux 2.2 Unleashed (Unleashed) — David Skoll, Lyle Taylor / Sams
Publishing.
Many other large publishers have produced books for LINUX. These are available
from all good computer bookstores (both bricks-and-mortar and on-line).
S/390 documents
Documents about S/390 systems are available as on-line books via the IBMlink
home page of the World Wide Web at http://www.elink.ibmlink.ibm.com/pbl/pbl.
Alternatively, to order IBM publications on CD-ROM, contact your IBM
representative or write to the IBM branch office serving your locality.

ITSO redbooks are available from the IBM Redbooks web site at
http://www.redbooks.ibm.com/
Some of the most useful titles are compilations of documents for VM and for
S/390. These are available as printed and on-line media and include a
comprehensive set of documents from subject introductions to highly detailed
technical descriptions.
v IBM VM Collection on CD: Online Library Omnibus Edition: SK2T-2067-16
v IBM Online Library S/390 Rainbow Collection: SK2T-2177-10
v IBM S/390 Redbooks Collection: SK2T-217-21.

Chapter 20. execs, shell scripts, and tools
The following execs, shell scripts, and tools are used during installation.
netsetup
This shell script is used to set up the network.
#! /bin/bash
#
# readln reads a line into $ans.
#
function readln () {
echo -n "$1"
IFS='@' read ans || exit 1
ans=′echo $ans | sed -e 's/| *//'′
}
#
# yes_no reads either a yes or a no into $ans
#
function yes_no () {
while :; do
readln "$1"
case "$ans" in
[yY] | [yY]es) ans=yes
break;;
[nN] | [nN]o) ans=no
break;;
esac
done
}
echo
echo "Welcome to Linux for S/390"
confok=0
while [ $confok = 0 ]; do
yes_no "Is your machine connected to a network (Yes/No) ? "
if [ "$ans" = "yes" ]; then
while :; do
echo "Select the type of your network device"
echo "1) for osa token ring"
echo "2) for osa ethernet"
echo "3) for channel to channel"
readln "Enter your choice (1-3): "
case "$ans" in
1)
ip_dev=tr0
echo "Please type in the options for the lcs module, e.g. to select"
echo "relative port 1 on device 0xfd00 you should enter: "
echo "noauto=1 devno_portno_pairs=0xfd00,1"
readln "lcs parameter: "
lcs_parm=$ans
break;;
2)
ip_dev=eth0
echo "Please type in the options for the lcs module, e.g. to select"
echo "relative port 1 on device 0xfd00 you should enter: "
echo "noauto=1 devno_portno_pairs=0xfd00,1"
readln "lcs parameter: "
lcs_parm=$ans

break;;
3)
ip_dev=ctc0
break;;
esac
done
readln "Please enter your host name: "
ip_host=$ans
readln "Please enter your IP address: "
ip_addr=$ans
readln "Please enter the net mask: "
ip_netmask=$ans
if [ "$ip_dev" = "ctc0" ]; then
readln "Please enter the IP address of your peer: "
ip_peer=$ans
ip_gateway=$ans
else
readln "Please enter the broadcast address: "
ip_broadcast=$ans
readln "Please enter the gateway address: "
ip_gateway=$ans
fi
readln "Please enter the net address: "
ip_network=$ans
readln "Please enter the IP address of the DNS server: "
ip_dns=$ans
readln "Please enter the DNS search domain: "
ip_search=$ans
echo
echo "Configuration will be:"
if [ "$ip_dev" = "tr0" -o "$ip_dev" = "eth0" ]; then
echo "LCS parameter : $lcs_parm"
fi
echo "Host name : $ip_host"
echo "IP address : $ip_addr"
echo "Net mask : $ip_netmask"
echo "Peer IP address : $ip_peer"
else
echo "Broadcast address: $ip_broadcast"
echo "Gateway address : $ip_gateway"
fi
echo "Net address : $ip_network"
echo "DNS IP address : $ip_dns"
echo "DNS search domain: $ip_search"
yes_no "Is this correct (Yes/No) ? "
if [ "$ans" = "yes" ]; then
cat > /etc/sysconfig/network <<EOF
NETWORKING=yes
FORWARD_IPV4=no
HOSTNAME=$ip_host
GATEWAYDEV=$ip_dev
GATEWAY=$ip_gateway
EOF
cat > /etc/sysconfig/network-scripts/ifcfg-$ip_dev <<EOF
DEVICE=$ip_dev
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
REMIP=$ip_peer
NETWORK=$ip_network
NETMASK=$ip_netmask
IPADDR=$ip_addr
EOF
else
cat > /etc/sysconfig/network-scripts/ifcfg-$ip_dev <<EOF

DEVICE=$ip_dev
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
BROADCAST=$ip_broadcast
NETWORK=$ip_network
NETMASK=$ip_netmask
IPADDR=$ip_addr
EOF
if [ "$lcs_parm" = "" ]; then
cat > /etc/conf.modules <<EOF
alias $ip_dev lcs
EOF
else
cat > /etc/conf.modules <<EOF
alias $ip_dev lcs
options lcs $lcs_parm
EOF
fi
fi
cat > /etc/resolv.conf <<EOF
search $ip_search
nameserver $ip_dns
EOF
hostname $ip_host
confok=1
fi
else
confok=1
fi
done
rm /etc/rc.d/init.d/netsetup
rm /etc/rc.d/rc3.d/S00netsetup
exit
silo
This tool is used to make DASDs (direct access storage devices) bootable. It takes a
kernel image, a parameter file, a bootsector file, and the device node as input.
Additionally, the file /etc/silo.conf, or the file specified by using the -F file name
parameter, is parsed for additional options.
The parameter line in the parameter file should contain the following entries (note
that you should avoid additional whitespace separating the entries, because the
overall size of a kernel parameter line is limited):
v root=/dev/... (this has to match the DASD parameter)
v ro
v noinitrd (only necessary if the kernel was compiled with initial RAM disk
support on).
From the config-file /etc/silo.conf, you can specify:
append= [any optional parameter], for example, noinitrd ro
Usage
silo -d ipldevice [-hV?] [-t[#]] [-v[#]]
[-F config-file] [-b bootsector]
[-f image] [-p parameterfile] [-B bootmap]
Chapter 20. execs, shell scripts, and tools 159

Parameters
Note that the defaults for these parameters can be overwritten by entering
keywords in the config-file. The format used for each parameter keyword is shown
in monospaced text in the following descriptions.
-d ipldevice
Set ipldevice=devicenode to set the IPL device to a specific device node.
The device node specified must be the node of the ’full’ device and not
one of a partition.
-h Prints out a short usage message.
-V Print version number and exit silo.
-? Prints out a short usage message.
-t[#] By default, silo runs with a testlevel of 2, which means that no
modifications are made to the disk. A testing level of 1 means that a
bootmap is generated with a temporary file name, but the IPL records of
the disk are not modified. The disk is made IPL-able only with a testing
level of 0 or below. Set testlevel=level to decrease the testing level from
the default by the value of level. Use the short form -t[#] to decrease the
testing level by one, or #, respectively.
-v[#] Set verbose=level to specify the level of verbosity used. Increases
verbosity, or sets verbosity to #, respectively.
-F config-file
There are some defaults for the most common parameters compiled into
the binary. You can overwrite these defaults by your own using
/etc/silo.conf or another config-file specified by -F config-file. All
values set by defaults or the config-file can be overwritten using the
command line options of silo.
-b bootsector
Set bootsect=bootsect to specify the name of the bootsector to be used as
IPL record for that volume. The default name is /boot/ipleckd.boot.
-f image
Set image=image to specify the name of the image that is going to be IPL-ed
from that volume. The default name is ./image.
-p parameterfile
Set parmfile=parameter file to specify the name of the parameter file
holding the kernel parameters to be used during setup of the kernel. The
default name is ./parmfile.
-B bootmap
Set map=bootmap to specify the name of the bootmap used to hold the map
information needed during IPL. The default name is ./boot.map. In
test-only mode this name is replaced by a temporary name.
Additional keywords
Some additional entries for the config-file:
ramdisk=ramdisk image
Optionally specifies the name of a ramdisk image to be used as an initial
ramdisk.
root=device node
Specifies the device holding the root device of the IPL-ed system.

readonly
Sets the flag to mount the device holding the root device of the IPL-ed
system. The device is mounted in read only mode before the final mount is
done by /etc/fstab.
append= [list of parameters]
Used in the config-file to set additional parameters to be added to the
parameter file. These parameters are added to any parameter file specified
on the command line. The old parameter file is preserved and a new one is
created with a temporary name.
For example, if you have problems with your OSA-2 card during IPL
(usually this happens only in native ESA/390 Single Image mode), you
might want to insert a delay to allow the card to reset. Inserting the
following entry in the append command will then cause it to be added to
the temporary parm.line file:
ipldelay=xyz
where xyz is the delay period. For example, 30s means a delay of thirty
seconds immediately after the IPL and before initializing the OSA-2 card,
2m means a delay of two minutes. The value xyz must be a number
followed by either s or m. A value of 2m is recommended as a minimum.
This setting is not DASD specific.
dasdfmt
This tool is used to low-level format direct access storage devices (DASD). Note
that dasdfmt is only able to format DASDs that have already been formatted using
another disk formatting utility. If you have unformatted DASD in your system, use
a device support facility such as ICKDSF to initially format the DASD.
dasdfmt uses an ioctl call to the DASD driver to format tracks. A start and end
track for formatting can be specified, as well as a blocksize (hard sector size).
Remember that the formatting process can take quite a long time. The syntax of
the utility is as follows:
dasdfmt [-tvy] [-s start_track] [-e end_track] [-b blocksize] -f dev_filename
| -n 390_devno
dasdfmt -help prints out an overview of the syntax.
The parameters are:

v -f specifies the device node in the file system. This must be the whole device,
not a partition.
v -n specifies the device number of the disk to format.
Exactly one of the parameters -f and -n must be specified.
The following parameters are necessary, however, if you do not specify their
values, you are prompted for them. You can use the default values by pressing the
<enter> key:
v -s specifies the start track of the formatting. A value of 0 (first track of disk) is
the default value.
v -e specifies the last track of the formatting. A value of -1 means the last track on
the disk and is the default value.
v -b specifies the blocksize. Default value is blocksize of 4096.
Chapter 20. execs, shell scripts, and tools 161

The following parameters are optional:
v -v prints out more messages.
v -y omits the security prompt and formats the disk directly (for batch use by
daring people!).
v -t switches to a test mode, the DASD will not be formatted.

Chapter 21. File system .tar file contents
The initfs_small.tgz and initfs_big.tgz collections contain the LINUX for
S/390 file system and other LINUX utilities and applications.
initfs_small.tgz
The following packages are contained in the initfs_small.tgz collection:
setup-2.0.5-1.noarch.rpm
filesystem-1.3.5-1.noarch.rpm
basesystem-6.0-4.noarch.rpm
ldconfig-1.9.5-15.s390.rpm
glibc-2.1.3-0.s390.rpm
glibc-profile-2.1.3-0.s390.rpm
glib-1.2.5-1.s390.rpm
shadow-utils-19990827-2.s390.rpm
mktemp-1.5-1.s390.rpm
termcap-9.12.6-15.s390.rpm
libtermcap-2.0.8-18.s390.rpm
bash-1.14.7-16.s390.rpm
ncurses-4.2-18.s390.rpm
cracklib-2.7-5.s390.rpm
cracklib-dicts-2.7-5.s390.rpm
pwdb-0.60-1.s390.rpm
info-3.12h-2.s390.rpm
zlib-1.1.3-5.s390.rpm
bdflush-1.5-10.s390.rpm
bison-1.27-3.s390.rpm
bzip2-0.9.0c-1.s390.rpm
chkconfig-1.0.7-2.s390.rpm
e2fsprogs-1.15-3.s390.rpm
ed-0.2-12.s390.rpm
file-3.26-6.s390.rpm
fileutils-4.0-1.s390.rpm
findutils-4.1-31.s390.rpm
flex-2.5.4a-6.s390.rpm
gawk-3.0.3-7.s390.rpm
gdbm-1.8.0-2.s390.rpm
getty_ps-2.0.7j-7.s390.rpm
nscd-2.1.3-0.s390.rpm
grep-2.3-2.s390.rpm
gzip-1.2.4-14.s390.rpm
less-332-6.s390.rpm
libtool-1.3.3-1.noarch.rpm
m4-1.4-12.s390.rpm
make-3.77-6.s390.rpm
mingetty-0.9.4-10.s390.rpm
vixie-cron-3.0.1-40.s390.rpm
modutils-2.1.121-12.s390.rpm
logrotate-3.3.2-1.s390.rpm
mount-2.9o-1.s390.rpm
losetup-2.9o-1.s390.rpm
net-tools-1.51-3.s390.rpm
portmap-4.0-15.s390.rpm
netkit-base-0.10-29.s390.rpm
procps-2.0.2-2.s390.rpm
psmisc-18-3.s390.rpm
routed-0.10-14.s390.rpm
sed-3.02-4.s390.rpm
sysklogd-1.3.31-12.s390.rpm
tcp_wrappers-7.6-7.s390.rpm

telnet-0.10-27.s390.rpm
time-1.7-9.s390.rpm
initscripts-4.48-1.s390.rpm
perl-5.00503-6.s390.rpm
sharutils-4.2-12.s390.rpm
tar-1.12-9.s390.rpm
textutils-1.22-9.s390.rpm
vim-common-5.4-2.s390.rpm
vim-minimal-5.4-2.s390.rpm
which-1.0-11.s390.rpm
pam-0.68-7.s390.rpm
util-linux-2.9o-13.s390.rpm
passwd-0.63-1.s390.rpm
SysVinit-2.74-11.s390.rpm
sh-utils-1.16-23.s390.rpm
ftp-0.10-22.s390.rpm
rpm-3.0.3-3.s390.rpm
tcsh-6.08.00-6.s390.rpm
indent-2.2.0-1.s390.rpm
wu-ftpd-2.4.2vr17-3.s390.log
e2fsprogs-devel-1.15-3.s390.rpm
gdbm-devel-1.8.0-2.s390.rpm
glib-devel-1.2.5-1.s390.rpm
glibc-devel-2.1.3-0.s390.rpm
ncurses-devel-4.2-18.s390.rpm
popt-1.3-1.s390.rpm
rpm-devel-3.0.3-3.s390.rpm
zlib-devel-1.1.3-5.s390.rpm
initfs_big.tgz
The following packages are contained in the initfs_big.tgz collection:
setup-2.0.5-1.noarch.rpm
filesystem-1.3.5-1.noarch.rpm
basesystem-6.0-4.noarch.rpm
ldconfig-1.9.5-15.s390.rpm
glibc-2.1.3-0.s390.rpm
glibc-profile-2.1.3-0.s390.rpm
glib-1.2.5-1.s390.rpm
shadow-utils-19990827-2.s390.rpm
mktemp-1.5-1.s390.rpm
termcap-9.12.6-15.s390.rpm
libtermcap-2.0.8-18.s390.rpm
bash-1.14.7-16.s390.rpm
ncurses-4.2-18.s390.rpm
cracklib-2.7-5.s390.rpm
cracklib-dicts-2.7-5.s390.rpm
pwdb-0.60-1.s390.rpm
info-3.12h-2.s390.rpm
zlib-1.1.3-5.s390.rpm
bdflush-1.5-10.s390.rpm
bison-1.27-3.s390.rpm
bzip2-0.9.0c-1.s390.rpm
chkconfig-1.0.7-2.s390.rpm
e2fsprogs-1.15-3.s390.rpm
ed-0.2-12.s390.rpm
file-3.26-6.s390.rpm
fileutils-4.0-1.s390.rpm
findutils-4.1-31.s390.rpm
flex-2.5.4a-6.s390.rpm
gawk-3.0.3-7.s390.rpm
gdbm-1.8.0-2.s390.rpm
getty_ps-2.0.7j-7.s390.rpm
nscd-2.1.3-0.s390.rpm
grep-2.3-2.s390.rpm
gzip-1.2.4-14.s390.rpm

less-332-6.s390.rpm
libtool-1.3.3-1.noarch.rpm
m4-1.4-12.s390.rpm
make-3.77-6.s390.rpm
mingetty-0.9.4-10.s390.rpm
vixie-cron-3.0.1-40.s390.rpm
modutils-2.1.121-12.s390.rpm
logrotate-3.3.2-1.s390.rpm
mount-2.9o-1.s390.rpm
losetup-2.9o-1.s390.rpm
net-tools-1.51-3.s390.rpm
portmap-4.0-15.s390.rpm
netkit-base-0.10-29.s390.rpm
procps-2.0.2-2.s390.rpm
psmisc-18-3.s390.rpm
routed-0.10-14.s390.rpm
sed-3.02-4.s390.rpm
sysklogd-1.3.31-12.s390.rpm
tcp_wrappers-7.6-7.s390.rpm
telnet-0.10-27.s390.rpm
time-1.7-9.s390.rpm
initscripts-4.48-1.s390.rpm
perl-5.00503-6.s390.rpm
sharutils-4.2-12.s390.rpm
tar-1.12-9.s390.rpm
textutils-1.22-9.s390.rpm
vim-common-5.4-2.s390.rpm
vim-minimal-5.4-2.s390.rpm
which-1.0-11.s390.rpm
pam-0.68-7.s390.rpm
util-linux-2.9o-13.s390.rpm
passwd-0.63-1.s390.rpm
SysVinit-2.74-11.s390.rpm
sh-utils-1.16-23.s390.rpm
ftp-0.10-22.s390.rpm
rpm-3.0.3-3.s390.rpm
tcsh-6.08.00-6.s390.rpm
indent-2.2.0-1.s390.rpm
wu-ftpd-2.4.2vr17-3.s390.log
e2fsprogs-devel-1.15-3.s390.rpm
gdbm-devel-1.8.0-2.s390.rpm
glib-devel-1.2.5-1.s390.rpm
glibc-devel-2.1.3-0.s390.rpm
ncurses-devel-4.2-18.s390.rpm
popt-1.3-1.s390.rpm
rpm-devel-3.0.3-3.s390.rpm
zlib-devel-1.1.3-5.s390.log
XFree86-3.3.5-3.s390.rpm
XFree86-75dpi-fonts-3.3.5-3.s390.rpm
XFree86-100dpi-fonts-3.3.5-3.s390.rpm
XFree86-cyrillic-fonts-3.3.5-3.s390.rpm
XFree86-libs-3.3.5-3.s390.rpm
XFree86-doc-3.3.5-3.s390.rpm
XFree86-Xvfb-3.3.5-3.s390.rpm
XFree86-Xnest-3.3.5-3.s390.rpm
XFree86-xfs-3.3.5-3.s390.rpm
apache-1.3.9-4.s390.rpm
apache-devel-1.3.9-4.s390.rpm
autoconf-2.13-5.noarch.rpm
automake-1.4-5.s390.rpm
diffutils-2.7-16.s390.rpm
groff-1.11a-9.s390.rpm
man-1.5g-6.s390.rpm
ntsysv-1.0.7-2.s390.rpm
texinfo-3.12h-2.s390.rpm
vim-enhanced-5.4-2.s390.rpm
vim-X11-5.4-2.s390.rpm
Chapter 21. File system .tar file contents 165

X11R6-contrib-3.3.2-6.s390.rpm
Xaw3d-1.3-21.s390.rpm
bash2-2.03-4.s390.rpm
bash2-doc-2.03-4.s390.rpm
byacc-1.9-11.s390.rpm
chkfontpath-1.5-1.s390.rpm
cvs-1.10.6-2.s390.rpm
xemacs-21.1.4-2.s390.rpm
xemacs-info-21.1.4-2.s390.rpm
xemacs-X11-21.1.4-2.s390.rpm
xemacs-el-21.1.4-2.s390.rpm
xemacs-extras-21.1.4-2.s390.rpm
gettext-0.10.35-13.s390.rpm
ghostscript-5.10-10.s390.rpm
ghostscript-fonts-5.10-3.noarch.rpm
gmp-2.0.2-10.s390.rpm
gperf-2.7-5.s390.rpm
libjpeg6a-6a-4.s390.rpm
libjpeg-6b-9.s390.rpm
libpng-1.0.3-4.s390.rpm
libtiff-3.4-6.s390.rpm
newt-0.50-13.s390.rpm
patch-2.5-8.s390.rpm
pdksh-5.2.13-3.s390.rpm
procps-X11-2.0.2-2.s390.rpm
python-1.5.2-7.s390.rpm
python-tools-1.5.2-7.s390.rpm
python-docs-1.5.2-7.s390.rpm
pythonlib-1.23-1.noarch.rpm
tkinter-1.5.2-7.s390.rpm
readline-2.2.1-5.s390.rpm
rsh-0.10-25.s390.rpm
slang-1.2.2-4.s390.rpm
tcl-8.0.5-30.s390.rpm
tk-8.0.5-30.s390.rpm
expect-5.28-30.s390.rpm
tclx-8.0.5-30.s390.rpm
tix-4.1.0.6-30.s390.rpm
itcl-3.0.1-30.s390.rpm
tftp-0.10-23.s390.rpm
unzip-5.40-1.s390.rpm
utempter-0.5.1-2.s390.rpm
xloadimage-4.1-12.s390.rpm
xpaint-2.4.9-8.s390.rpm
xpm-3.4k-1.s390.rpm
zsh-3.0.5-15.s390.log
Xaw3d-devel-1.3-21.s390.rpm
XFree86-devel-3.3.5-3.s390.rpm
gmp-devel-2.0.2-10.s390.rpm
lesstif-devel-0.86.5-2.s390.rpm
libjpeg-devel-6b-9.s390.rpm
libpng-devel-1.0.3-4.s390.rpm
libtermcap-devel-2.0.8-18.s390.rpm
newt-devel-0.50-13.s390.rpm
python-devel-1.5.2-7.s390.rpm
readline-devel-2.2.1-5.s390.rpm
slang-devel-1.2.2-4.s390.rpm
xpm-devel-3.4k-1.s390.rpm

Part 6. Appendixes

Appendix. Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information about the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

GNU General Public Licence, Version 2, June 1991
LINUX for S/390 is licenced under the GNU General Public Licence which is reproduced
below:
Copyright (C) 1989, 1991

Free Software Foundation, Inc.
59 Temple Place,
Suite 330,
Boston,
MA 02111-1307
USA
Everyone is permitted to copy and distribute verbatim copies of this license

document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share
and change it. By contrast, the GNU General Public License is intended to
guarantee your freedom to share and change free software--to make sure the
software is free for all its users. This General Public License applies to most of the
Free Software Foundation’s software and to any other program whose authors
commit to using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to your
programs, too.
When we speak of free software, we are referring to freedom, not price. Our
General Public Licenses are designed to make sure that you have the freedom to
distribute copies of free software (and charge for this service if you wish), that you
receive source code or can get it if you want it, that you can change the software
or use pieces of it in new free programs; and that you know you can do these
things.
To protect your rights, we need to make restrictions that forbid anyone to deny
you these rights or to ask you to surrender the rights. These restrictions translate
to certain responsibilities for you if you distribute copies of the software, or if you
modify it.
For example, if you distribute copies of such a program, whether gratis or for a
fee, you must give the recipients all the rights that you have. You must make sure
that they, too, receive or can get the source code. And you must show them these
terms so they know their rights.
We protect your rights with two steps:

1. copyright the software, and
2. offer you this license which gives you legal permission to copy, distribute
and/or modify the software.
Also, for each author’s protection and ours, we want to make certain that everyone
understands that there is no warranty for this free software. If the software is
modified by someone else and passed on, we want its recipients to know that what
they have is not the original, so that any problems introduced by others will not
reflect on the original authors’ reputations.

Finally, any free program is threatened constantly by software patents. We wish to
avoid the danger that redistributors of a free program will individually obtain
patent licenses, in effect making the program proprietary. To prevent this, we have
made it clear that any patent must be licensed for everyone’s free use or not
licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
GNU General Public Licence: Terms and conditions for

copying, distribution and modification
0. This License applies to any program or other work which contains a notice
placed by the copyright holder saying it may be distributed under the terms of this
General Public License. The ″Program″, below, refers to any such program or work,
and a ″work based on the Program″ means either the Program or any derivative
work under copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in the term
″modification″.) Each licensee is addressed as ″you″.
Activities other than copying, distribution and modification are not covered by this
License; they are outside its scope. The act of running the Program is not
restricted, and the output from the Program is covered only if its contents
constitute a work based on the Program (independent of having been made by
running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program’s source code as
you receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice and
disclaimer of warranty; keep intact all the notices that refer to this License and
to the absence of any warranty; and give any other recipients of the Program
a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may
at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus
forming a work based on the Program, and copy and distribute such
modifications or work under the terms of Section 1 above, provided that you
also meet all of these conditions:
a. You must cause the modified files to carry prominent notices stating that
you changed the files and the date of any change.
b. You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to be
licensed as a whole at no charge to all third parties under the terms of this
License.
c. If the modified program normally reads commands interactively when run,
you must cause it, when started running for such interactive use in the
most ordinary way, to print or display an announcement including an
appropriate copyright notice and a notice that there is no warranty (or
else, saying that you provide a warranty) and that users may redistribute
the program under these conditions, and telling the user how to view a
copy of this License. (Exception: if the Program itself is interactive but does
not normally print such an announcement, your work based on the
Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable
sections of that work are not derived from the Program, and can be
Appendix. Notices 171

reasonably considered independent and separate works in themselves, then
this License, and its terms, do not apply to those sections when you distribute
them as separate works. But when you distribute the same sections as part of
a whole which is a work based on the Program, the distribution of the whole
must be on the terms of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part regardless of who
wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to
work written entirely by you; rather, the intent is to exercise the right to
control the distribution of derivative or collective works based on the
Program.
In addition, mere aggregation of another work not based on the Program with
the Program (or with a work based on the Program) on a volume of a storage
or distribution medium does not bring the other work under the scope of this
License.
3. You may copy and distribute the Program (or a work based on it, under
Section 2) in object code or executable form under the terms of Sections 1 and 2
above provided that you also do one of the following:
a. Accompany it with the complete corresponding machine-readable source
code, which must be distributed under the terms of Sections 1 and 2 above
on a medium customarily used for software interchange; or,
b. Accompany it with a written offer, valid for at least three years, to give any
third party, for a charge no more than your cost of physically performing
source distribution, a complete machine-readable copy of the corresponding
source code, to be distributed under the terms of Sections 1 and 2 above on
a medium customarily used for software interchange; or,
c. Accompany it with the information you received as to the offer to distribute
corresponding source code. (This alternative is allowed only for
noncommercial distribution and only if you received the program in object
code or executable form with such an offer, in accord with Subsection b
above.)
The source code for a work means the preferred form of the work for making
modifications to it. For an executable work, complete source code means all the
source code for all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation of the
executable. However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the operating
system on which the executable runs, unless that component itself accompanies
the executable.
If distribution of executable or object code is made by offering access to copy

from a designated place, then offering equivalent access to copy the source
code from the same place counts as distribution of the source code, even
though third parties are not compelled to copy the source along with the object
code.
4. You may not copy, modify, sublicense, or distribute the Program except as
expressly provided under this License. Any attempt otherwise to copy, modify,
sublicense or distribute the Program is void, and will automatically terminate
your rights under this License. However, parties who have received copies, or
rights, from you under this License will not have their licenses terminated so
long as such parties remain in full compliance.

5. You are not required to accept this License, since you have not signed it.
However, nothing else grants you permission to modify or distribute the
Program or its derivative works. These actions are prohibited by law if you do
not accept this License. Therefore, by modifying or distributing the Program (or
any work based on the Program), you indicate your acceptance of this License
to do so, and all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program),
the recipient automatically receives a license from the original licensor to copy,
distribute or modify the Program subject to these terms and conditions. You
may not impose any further restrictions on the recipients’ exercise of the rights
granted herein. You are not responsible for enforcing compliance by third
parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or
for any other reason (not limited to patent issues), conditions are imposed on
you (whether by court order, agreement or otherwise) that contradict the
conditions of this License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by all those
who receive copies directly or indirectly through you, then the only way you
could satisfy both it and this License would be to refrain entirely from
distribution of the Program.
If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply and the
section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or
other property right claims or to contest validity of any such claims; this
section has the sole purpose of protecting the integrity of the free software
distribution system, which is implemented by public license practices. Many
people have made generous contributions to the wide range of software
distributed through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing to
distribute software through any other system and a licensee cannot impose that
choice.
This section is intended to make thoroughly clear what is believed to be a
consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries
either by patents or by copyrighted interfaces, the original copyright holder
who places the Program under this License may add an explicit geographical
distribution limitation excluding those countries, so that distribution is
permitted only in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the
General Public License from time to time. Such new versions will be similar in
spirit to the present version, but may differ in detail to address new problems
or concerns.
Each version is given a distinguishing version number. If the Program specifies
a version number of this License which applies to it and ″any later version″,
you have the option of following the terms and conditions either of that
version or of any later version published by the Free Software Foundation. If
the Program does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free programs
whose distribution conditions are different, write to the author to ask for
permission. For software which is copyrighted by the Free Software
Foundation, write to the Free Software Foundation; we sometimes make
exceptions for this. Our decision will be guided by the two goals of preserving
the free status of all derivatives of our free software and of promoting the
sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING
THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE
PROGRAM ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO
IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY
WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS
PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING
ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM
(INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use
to the public, the best way to achieve this is to make it free software which
everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to
the start of each source file to most effectively convey the exclusion of warranty;
and each file should have at least the ″copyright″ line and a pointer to where the
full notice is found.
<one line to give the program’s name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this
program; if not, write to the Free Software Foundation, Inc., 59 Temple Place,
Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts
in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type ′show w'.
This is free software, and you are welcome to redistribute it under certain
conditions; type ′show c' for details.
The hypothetical commands ′show w' and ′show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may be
called something other than ′show w' and ′show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school,
if any, to sign a ″copyright disclaimer″ for the program, if necessary. Here is a
sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program ′Gnomovision'
(which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may consider it
more useful to permit linking proprietary applications with the library. If this is
what you want to do, use the GNU Library General Public License instead of this
License.
Trademarks
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both:
Advanced Peer-to-Peer Networking OS/2

APPN OS/390
CICS OSA
Common User Access PowerPC
e-business RACF
ECKD RAMAC
ESA/390 S/390
ESCON Seascape
IBM System/390
Micro Channel VM/ESA
Multiprise VSE/ESA
MVS VTAM
UNIX is a registered trademark in the United States and other countries licensed
exclusively through The Open Group.
LINUX is a registered trademark of Linus Torvalds and others.
Microsoft, Windows NT, and MSDOS are registered trademarks of Microsoft

Corporation in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks
of others.

Glossary
This glossary includes IBM product terminology A
as well as selected other terms and definitions.
Additional information can be obtained in: APPN. Advanced Peer-to-Peer Networking.
v The American National Standard Dictionary for
Information Systems , ANSI X3.172-1990, B
copyright 1990 by the American National
Standards Institute (ANSI). Copies may be bash. Bourne-again shell. A portable, command-line
purchased from the American National interface and script interpreter that is compatible with
Standards Institute, 11 West 42nd Street, New the UNIX Bourne and Korn shells and includes some
York, New York 10036. features of the UNIX C shell.
v The ANSI/EIA Standard–440-A, Fiber Optic BSD. Berkeley Software Distribution. Pertaining to
Terminology. Copies may be purchased from any of the series of UNIX specifications or
the Electronic Industries Association, 2001 implementations distributed by the University of
Pennsylvania Avenue, N.W., Washington, DC California at Berkeley. The mnemonic ″BSD″ is usually
20006. followed by a number to specify the particular version
of UNIX that was distributed (for example, BSD 4.3).
v The Information Technology Vocabulary
Many vendors use BSD specifications as standards for
developed by Subcommittee 1, Joint Technical
their UNIX products.
Committee 1, of the International Organization
for Standardization and the International
Electrotechnical Commission (ISO/IEC C
JTC1/SC1).
CCW. channel command word. A doubleword at the
v The IBM Dictionary of Computing , New York: location in main storage specified by the channel
McGraw-Hill, 1994. address word. One or more CCWs make up the
v Internet Request for Comments: 1208, Glossary channel program that directs data channel operations.
of Networking Terms
CDROM. High-capacity read-only memory in the
v Internet Request for Comments: 1392, Internet form of an optically read compact disc.
Users’ Glossary
CHPID. channel path identifier. In a channel
v The Object-Oriented Interface Design: IBM
subsystem, a value assigned to each installed channel
Common User Access Guidelines, Carmel,
path of the system that uniquely identifies that path to
Indiana: Que, 1992. the system.
CICS. Customer Information Control System. An IBM

licensed program that enables transactions entered at
remote terminals to be processed concurrently by
user-written application programs. It includes facilities
for building, using, and maintaining databases.
CMS. conversational monitor system. A virtual

machine operating system that provides general
interactive time sharing, problem solving, and program
development capabilities, and operates only under
control of the VM control program.
CP. control program. The part of VM that creates and

manages the virtual machines. It is often referred to as
the ’hypervisor’.
CRC. cyclic redundancy check. A system of error

checking performed at both the sending and receiving
station after a block-check character has been
accumulated.

CTC. channel to channel. A method of connecting two ESCON. Enterprise Systems Connection. A set of IBM
computing devices. products and services that provide a dynamically
connected environment within an enterprise.
CUU. Control Unit and Unit Address. A form of
addressing for S/390 devices using device numbers. Ethernet. A 10-Mbps baseband local area network that
allows multiple stations to access the transmission
cylinder. (1) In an assembly of magnetic disks, the set medium at will without prior coordination, avoids
of all tracks that can be accessed by all the magnetic contention by using carrier sense and deference, and
heads of a comb in a given position. (2) The tracks of a resolves contention by using collision detection and
disk storage device that can be accessed without delayed retransmission. Ethernet uses carrier sense
repositioning the access mechanism. multiple access with collision detection (CSMA/CD).
ext2 file system. second extended file system. The

D default file system for LINUX based on UFS/FFS.
DASD. direct access storage device. A mass storage
medium on which a computer stores data. F
DB2. DATABASE 2. An IBM relational database FBA. fixed-block-architecture type DASD on P/390
management system. (Multiprise 3000) or supported by VM.
device driver. (1) A file that contains the code needed FDDI. Fiber Distributed Data Interface. An American
to use an attached device. (2) A program that enables a National Standards Institute (ANSI) standard for a
computer to communicate with a specific peripheral 100-megabit-per-second LAN using optical fiber cables.
device; for example, a printer, a videodisc player, or a
CD-ROM drive. (3) A collection of subroutines that FTP. File Transfer Protocol. In the Internet suite of
control the interface between I/O device adapters and protocols, an application layer protocol that uses TCP
the processor. and Telnet services to transfer bulk-data files between
machines or hosts.
DITTO. Data Interfile Transfer, Testing, & Operations
utility. An IBM-licenced program that provides
file-to-file services for card I/O, magnetic tape, and G
disk devices.
G3, G4, G5 and G6. The generation name of the
DL/I. Data Language/I. A database access language S/390 CMOS based product family.
used under VSE and CICS/VS.
GRE. generic routing encapsulation. The
DMA. direct memory access. The system facility that encapsulation of data of one protocol type within
allows a device on the Micro Channel bus to get direct another protocol and its transmission over a channel
access to the system or bus memory without the that understands the encapsulating protocol.
intervention of the system processor.
H
E
hardware console. This is a service-call logical
ECKD. extended count-key-data device. A disk processor that is the communication feature between
storage device that has a data transfer rate faster than the main processor and the service processor.
some processors can utilize and that is connected to the
processor through use of a speed matching buffer. A HMC. hardware management console. A console used
specialized channel program is needed to communicate to monitor and control hardware such as the S/390
with such a device. microprocessors.
ELF binaries. executable and linkable format binaries. HFS. hierarchical file system.
Developed by Sun Microsystems as a default executable
format for LINUX. I
EOF. end of file. A coded character recorded on a data
IDCAMS. OS/390, VM/ESA, and VSE/ESA utility
medium to indicate the end of the medium.
that allows users to define, manipulate, or delete
ESA. Enterprise Systems Architecture. An architecture VSAM data sets, define and manipulate integrated
defined for the IBM product family. catalog facility dialogs, and copy, print, or convert SAM
and ISAM data sets to VSAM data sets.
ESA/390. Enterprise Systems Architecture for S/390.

IEBCOPY. OS/390 data set utility used to copy or screen panels and interactive dialogues between the
merge members between one or more partitioned data application programmer and terminal user.
sets, in full or in part. Can be used to create a backup
of a partitioned data set into a sequential data set and IRQ. interrupt request. A request for processing on a
to copy members from the backup into a partitioned particular priority level. It may be generated by the
data set. active program, the processing unit, or an I/O device.
IEBGENER. OS/390 data set utility used to create a IUCV. inter-user communication vehicle. A VM facility
backup of a sequential data set or a member of a for passing data between virtual machines and VM
sequential data set. Can produce a partitioned data set components.
or member of a partitioned data set from a sequential
data set. Can expand, edit, print, and manipulate
partitioned and sequential data sets.
J
JCL. job control language. A control language used to
IEEE FPU. Institute of Electrical and Electronics
identify a job to an operating system and to describe
Engineers floating point unit. The default floating point
the job’s requirements.
format definition for most modern operating systems.
IMS. Information Management System. A K

database/data communication (DB/DC) system that
can manage complex databases and networks. kernel. The part of an operating system that performs
basic functions such as allocating hardware resources.
IOCDS. I/O configuration data set.
kernel module. A dynamically loadable part of the
IP. Internet Protocol. In the Internet suite of protocols,
kernel. It can be a device driver, file system, etc.
a connectionless protocol that routes data through a
network or interconnected networks and acts as an kernel image. The kernel when loaded into memory.
intermediary between the higher protocol layers and
the physical network.
L
IP address.. The unique 32-bit address that specifies
the location of each device or workstation on the LAPB. link access protocol balanced. A protocol used
Internet. For example, 9.67.97.103 is an IP address. for accessing an X.25 network at the link level. LAPB is
a duplex, asynchronous, symmetric protocol, used in
IPL. initial program load (or boot). (1) The point-to-point communication.
initialization procedure that causes an operating system
to commence operation. (2) The process by which a LCS. LAN channel station. A protocol used by OSA.
configuration image is loaded into storage at the
beginning of a work day or after a system malfunction. LDP. Linux Documentation Project. An attempt to
(3) The process of loading system programs and provide a centralized location containing the source
preparing a system to run jobs. material for all open source LINUX documentation.
Includes user and reference guides, HOW TOs, and
IPv6. IP version 6. The next generation of the Internet FAQs.
Protocol.
LIBRarian. In VSE, the set of programs that maintains,
IPX. Internetwork Packet Exchange. (1) The network services, and organizes the system and private libraries.
protocol used to connect Novell’s servers, or any The librarian program is used to maintain data which
workstation or router that implements IPX, with other must be readily available to the system, such as
workstations. Although similar to the Internet Protocol programs and catalogued procedures. This data is
(IP), IPX uses different packet formats and terminology. organized in libraries, which are subdivided into
sublibraries, which in turn contain the data, organized
IPX address. IPX address. The 10-byte address, into units called members. Each member is identified
consisting of a 4-byte network number and a 6-byte unambiguously by a library name, sublibrary name,
node address, that is used to identify nodes in the IPX member name and member type. The names may be
network. The node address is usually identical to the freely chosen, the type depends on the type of data
medium access control (MAC) address of the associated contained in the member.
LAN adapter.
linkage editor. A program used to create a phase
ISPF. Interactive System Productivity Facility. An IBM (executable code) from one or more independently
licensed program that serves as a full-screen editor and translated object modules, from one or more existing
dialogue manager. Used for writing application phases, or from both. In creating the phase, the linkage
programs, it provides a means of generating standard
Glossary 179
editor resolves cross references among the modules and the system works. (3) The software that deals with the
phases available as input. The program can catalog the most basic operations that a computer performs.
newly built phases.
OS/390. An IBM licensed program that not only
LINUX for S/390. LINUX is a version of UNIX that includes and integrates functions previously provided
runs on x86, Alpha and PowerPC machines. LINUX for by many IBM software products (including the MVS
S/390 is the port of LINUX to the IBM S/390 operating system) but also (a) is an open, secure
mainframe architecture. operating system for the IBM S/390 family of
enterprise servers, (b) complies with industry
LPAR. logical partition. A fixed-size division of standards, (c) is Year 2000 ready and enabled for
storage. network computing and e-business, and (d) supports
technology advances in networking server capability,
LU. logical unit. A type of network accessible unit that parallel processing, and object-oriented programming.
enables end users to gain access to network resources
and communicate with each other. OSA-2. Open Systems Adapter-2. A common S/390
network interface card.
M
P
MAC. medium access control. In LANs, the sublayer
of the data link control layer that supports PTF. program temporary fix. A temporary solution or
medium-dependent functions and uses the services of bypass of a problem diagnosed by IBM in a current
the physical layer to provide services to the logical link unaltered release of the program.
control (LLC) sublayer. The MAC sublayer includes the
method of determining when a device has access to the PIC. programmable interrupt controller. A hardware
transmission medium. device that processes external interrupts.
major node (number). In VTAM, a set of resources PLP. Packet Layer Protocol.
that can be activated and deactivated as a group. The
number assigned to that group. /proc file system. A virtual file system providing
information about the status of a system. The files are
minidisk. In VM, a direct access storage device or a created on the fly when accessed.
logical subdivision of a direct access storage device that
has its own virtual device number, consecutive virtual PU. physical unit. The component that manages and
cylinders (starting with virtual cylinder 0), and a monitors the resources (such as attached links and
volume table of contents (VTOC) or disk label adjacent link stations) associated with a node.
identifier.
minor node (number). In VTAM, a uniquely defined

R
resource within a major node. The number assigned to
RACF. Resource Access Control Facility. An
that resource.
IBM-licensed program that provides for access control
MPTS. Multi-Protocol Transport Services. A tool in by identifying and by verifying the users to the system,
OS/2, used to bind protocols to LAN adapters. authorizing access to protected resources, logging the
detected unauthorized attempts to enter the system,
and logging the detected accesses to protected
N resources.
NFS. Network File System. A protocol developed by RAID. redundant array of independent disks. A disk
Sun Microsystems, Incorporated, that allows any host subsystem that provides increased performance and/or
in a network to mount another host’s file directories. fault tolerance. Performance is improved by disk
Once mounted, the file directory appears to reside on striping, which interleaves bytes or groups of bytes
the local host. across multiple drives, so more than one disk is reading
and writing simultaneously. Fault tolerance is achieved
NIC. network interface card. by mirroring or parity. Mirroring is 100% duplication of
the data on two drives (RAID 1), and parity calculates
O the data in two drives and stores the result on a third
drive (a bit from drive 1 is XOR’d with a bit from drive
OS. operating system. (1) Software that controls the 2, and the result bit is stored on drive 3).
execution of programs. An operating system may
provide services such as resource allocation,
scheduling, input/output control, and data
management. (2) A set of programs that control how

RAM disk. random access memory used to simulate a
hard disk drive. A temporary storage location in which
T
the central processing unit (CPU) stores and executes
TCP. Transmission Control Protocol. A
its processes.
communications protocol used in the Internet and in
RAMAC. RAID Architecture and Multi-level Adaptive any network that follows the Internet Engineering Task
Cache. An IBM DASD subsystem. Force (IETF) standards for internetwork protocol. TCP
provides a reliable host-to-host protocol between hosts
RARP. Reverse Address Resolution Protocol. (1) In the in packet-switched communications networks and in
Internet suite of protocols, the protocol that maps a interconnected systems of such networks. It uses the
hardware (MAC) address to an IP address. RARP can Internet Protocol (IP) as the underlying protocol.
be used to determine a port’s IP address.
TCP/IP. Transmission Control Protocol/Internet
Protocol. (1) The Transmission Control Protocol and the
S Internet Protocol, which together provide reliable
end-to-end connections between applications over
S/390. System/390. Pertaining to the family of IBM interconnected networks of different types. (2) The suite
enterprise servers that demonstrate outstanding of transport and application protocols that run over the
reliability, availability, scalability, security, and capacity Internet Protocol.
in today’s network computing environments.
Telnet. In the Internet suite of protocols, a protocol
SAM. sequential access method. An access method for that provides remote terminal connection service. It
storing or retrieving data blocks in a continuous allows users of one host to log on to a remote host and
sequence, using either a sequential access or a direct interact as directly attached terminal users of that host.
access device.
Token Ring. (1) According to IEEE 802.5, network
SA/SE. stand alone support element. See SE. technology that controls media access by passing a
token (special packet or frame) between media-attached
SCSI. small computer system interface. A standard stations. (2) A FDDI or IEEE 802.5 network with a ring
hardware interface that enables a variety of peripheral topology that passes tokens from one attaching ring
devices to communicate with one another. station (node) to another.
SE. support element. (1) An internal control element TSO. Time Sharing Option Extensions for the Virtual
of a processor that assists in many of the processor Telecommunications Access Method.
operational functions. (2) A hardware unit that provides
communications, monitoring, and diagnostic functions TTY. teletypewriter. A device used as an output
to a central processor complex. medium.
SLIP, CSLIP, PPP, PLIP, or AX.25/KISS. A protocol

used to run the Internet Protocol (IP) over serial lines, U
such as telephone circuits or RS-232 cables,
interconnecting two systems. For example, UNIX. UNIX operating system. An operating system
Point-to-Point Protocol (PPP) or serial line Internet developed by Bell Laboratories that features
Protocol (SLIP). multiprogramming in a multiuser environment. The
UNIX operating system was originally developed for
SNA. Systems Network Architecture. The IBM use on minicomputers but has been adapted for
architecture that defines the logical structure, formats, mainframes and microcomputers.
protocols, and operational sequences for transmitting
information units through, and controlling the
configuration and operation of, networks. The layered
V
structure of SNA allows the ultimate origins and
volume. A data carrier that is mounted and
destinations of information (the users) to be
demounted as a unit, for example, a reel of tape or a
independent of and unaffected by the specific SNA
disk pack. Some disk units have no demountable packs.
network services and facilities that are used for
In that case, a volume is the portion available to one
information exchange.
read/write mechanism.
Sysctl. system control programming manual control
VM. virtual machine. A virtual data processing
(frame). A means of dynamically changing certain
system. In VM/ESA, the virtual processors, virtual
kernel parameters on the fly.
storage, virtual devices, and virtual channel subsystem
System V. System V inter-process communication is a allocated to a single user. A virtual machine also
suite of library functions and system calls that allow includes any expanded storage dedicated to it.
processes to synchronize and exchange information.
Glossary 181
VM/CMS. virtual machine/conversational monitor VTAM. Virtual Telecommunications Access Method.
system. See CMS. IBM software that controls communication and the flow
of data in an SNA network by providing the SNA
VM/ESA. Virtual Machine/Enterprise Systems application programming interfaces and SNA
Architecture (VM/ESA). An IBM licensed program that networking functions. An SNA network includes
manages the resources of a single computer so that subarea networking, Advanced Peer-to-Peer
multiple computing systems appear to exist. Each Networking (APPN), and High-Performance Routing
virtual machine is the functional equivalent of a real (HPR).
machine.
VM reader, punch, and printer. (1) reader. (a) Part of X

an operating system scheduler that reads an input
stream into the device. (b) A program that reads jobs X.25. X.25. An International Telegraph and Telephone
from an input device or database file and places them Consultative Committee (CCITT) recommendation for
on a job queue. (2) punch. A virtual device which the interface between data terminal equipment and
generates the input for the reader. (3) printer. A virtual packet-switched data networks.
device which spools the data stream from a print queue
to a real print device.
Numbers
VSAM. virtual storage access method. An access
method for indexed or sequential processing of fixed 3215. IBM console printer-keyboard.
and variable length records on direct access devices.
3270. IBM information display system.
The records in a VSE/VSAM data set or file can be
organized: in logical sequence using a key field (key 3380 or 3390. IBM direct access storage device.
sequence); in physical sequence in which they are
written on the data set or file (entry sequence); by 3480 or 3490. IBM magnetic tape subsystem.
using relative record numbers.
VSE/ESA. Virtual Storage Extended/Enterprise

Systems Architecture. An IBM licensed program which
is a software operating system controlling the execution
of programs. Synonymous with VSE/Advanced
Functions.

IBMR
Printed in the United States of America

on recycled paper containing 10%
recovered post-consumer fiber.

Linux For S390 Installation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Linux For S390 Installation

Uploaded by

Copyright:

Available Formats

LINUX for S/390 - kernel patch IBM

LINUX® for S/390®

LINUX® for S/390®

© Copyright IBM Corp. 1999 iii

iv LINUX for S/390: Installation, Configuration and Use

vi LINUX for S/390: Installation, Configuration and Use

This book is an overview of the installation and customization of LINUX for

How this book is organized

Who should read this book

© Copyright IBM Corp. 1999 vii

viii LINUX for S/390: Installation, Configuration and Use

Filenames at web site Renamed files after transfer

This revision also includes maintenance and editorial changes.

© Copyright IBM Corp. 1999 ix

This revision also includes maintenance and editorial changes.

Filenames at web site Renamed files after transfer

This revision also includes maintenance and editorial changes.

x LINUX for S/390: Installation, Configuration and Use

Filenames at web site Renamed files after transfer

This revision also includes maintenance and editorial changes.

This revision also includes maintenance and editorial changes.

xii LINUX for S/390: Installation, Configuration and Use

© Copyright IBM Corp. 1999 1

Figure 1. Information roadmap

© Copyright IBM Corp. 1999 3

S/390 machine types

Although VM allows you to define up to 64 virtual S/390 processors per guest

© Copyright IBM Corp. 1999 5

An interesting feature of expanded storage is that is persistent with respect to IPLs

S/390 devices currently not supported

Please check the web site

6 LINUX for S/390: Installation, Configuration and Use

Hardware support components

The storage is divided into main storage/expanded storage

Chapter 2. Overview to LINUX for S/390 7

Tools and utilities

On the (batch and on-line) conventional parts of OS/390, on VSE/ESA, and on

8 LINUX for S/390: Installation, Configuration and Use

Chapter 2. Overview to LINUX for S/390 9

10 LINUX for S/390: Installation, Configuration and Use

per-user shell customization is equivalent to PROFILE EXEC:

system-wide shell config defaults:

The system configuration are stored and controlled differently on S/390:

Chapter 2. Overview to LINUX for S/390 11

Choosing the LINUX for S/390 run-time environment

Running LINUX for S/390 in a shared environment

© Copyright IBM Corp. 1999 13

Overview of the installation steps

Running LINUX for S/390

14 LINUX for S/390: Installation, Configuration and Use

Establishing the requirements of LINUX for S/390

Prerequisites for installation

Chapter 3. Planning your installation 15

IPL tape requirements

File system preparation

16 LINUX for S/390: Installation, Configuration and Use

Chapter 3. Planning your installation 17

© Copyright IBM Corp. 1999 19

20 LINUX for S/390: Installation, Configuration and Use

Figure 2. Installing on native S/390 or in an LPAR using OS/390, VM/ESA, or VSE/ESA

© Copyright IBM Corp. 1999 21

The IPL process is illustrated in Figure 3.

Figure 3. IPL process