| Installation GuideChapter 24. Troubleshooting Installation on IBM System zThis section discusses some common installation problems and their solutions. For debugging purposes, anaconda logs installation actions into files in the /tmp directory. These files include: /tmp/anaconda.loggeneral anaconda messages /tmp/program.logall external programs run by anaconda /tmp/storage.logextensive storage module information /tmp/yum.logyum package installation messages /tmp/sysloghardware-related system messages
If the installation fails, the messages from these files are consolidated into /tmp/anaconda-tb-identifier, where identifier is a random string. All of the files above reside in the installer's ramdisk and are thus volatile. To make a permanent copy, copy those files to another system on the network using scp on the installation image (not the other way round). 24.1. You are unable to boot Red Hat Enterprise Linux24.1.1. Is Your System Displaying Signal 11 Errors?A signal 11 error, commonly known as a segmentation fault, means that the program accessed a memory location that was not assigned to it. A signal 11 error may be due to a bug in one of the software programs that is installed, or faulty hardware. Ensure that you have the latest installation updates and images from Red Hat. Review the online errata to see if newer versions are available. 24.2. Trouble During the Installation24.2.1. No devices found to install Red Hat Enterprise Linux Error MessageIf you receive an error message stating No devices found to install Red Hat Enterprise Linux, then there may be an issue with your DASD devices. If you encounter this error, add the DASD=<disks> parameter to your parameter file or CMS configuration file (where disks is the DASD range reserved for installation) and start the install again. Additionally, make sure you format the DASDs using the dasdfmt command within a Linux root shell, instead of formatting the DASDs using CMS. Anaconda automatically detects any DASD devices that are not yet formatted and asks you whether to format the devices. 24.2.2. Saving traceback messagesIf anaconda encounters an error during the graphical installation process, it presents you with a crash reporting dialog box: - Details
shows you the details of the error:
- Save
saves details of the error locally or remotely: - Exit
exits the installation process.
If you select from the main dialog, you can choose from the following options: - Logger
saves details of the error as a log file to the local hard drive at a specified location. - Red Hat Customer Support
submits the crash report to Customer Support for assistance. - Report uploader
uploads a compressed version of the crash report to Bugzilla or a URL of your choice.
Before submitting the report, click Preferences to specify a destination or provide authentication details. Select the reporting method you need to configure and click Configure Event. - Logger
Specify a path and a filename for the log file. Check Append if you are adding to an existing log file.
- Red Hat Customer Support
Enter your Red Hat Network username and password so your report reaches Customer Support and is linked with your account. The URL is prefilled and Verify SSL is checked by default.
- Report uploader
Specify a URL for uploading a compressed version of the crash report.
- Bugzilla
Enter your Bugzilla username and password to lodge a bug with Red Hat's bug-tracking system using the crash report. The URL is prefilled and Verify SSL is checked by default.
Once you have entered your preferences, click OK to return to the report selection dialog. Select how you would like to report the problem and then click Forward. You can now customize the report by checking and unchecking the issues that will be included. When finished, click Apply. This screen displays the outcome of the report, including any errors in sending or saving the log. Click Forward to proceed. Reporting is now complete. Click Forward to return to the report selection dialog. You can now make another report, or click Close to exit the reporting utility and then Exit to close the installation process. 24.2.3. Other Partitioning ProblemsIf you create partitions manually, but cannot move to the next screen, you probably have not created all the partitions necessary for installation to proceed. You must have the following partitions as a bare minimum: When defining a partition's type as swap, do not assign it a mount point. Anaconda automatically assigns the mount point for you. 24.3. Problems After Installation24.3.1. Remote Graphical Desktops and XDMCPIf you have installed the X Window System and would like to log in to your Red Hat Enterprise Linux system using a graphical login manager, enable the X Display Manager Control Protocol (XDMCP). This protocol allows users to remotely log in to a desktop environment from any X Window System compatible client (such as a network-connected workstation or X11 terminal). To enable remote login using XDMCP, edit the /etc/gdm/custom.conf file on the Red Hat Enterprise Linux system with a text editor such as vi or nano. In the [xdcmp] section, add the line Enable=true, save the file, and exit the text editor. To enable this change, you will need to restart the X Window System. First, switch to runlevel 4: /sbin/init 4 The graphical display will close, leaving only a terminal. When you reach the login: prompt, enter your username and password. Then, as root in the terminal, switch to runlevel 5 to return to the graphical interface and start the X11 server: /sbin/init 5 From the client machine, start a remote X11 session using X. For example: X :1 -query s390vm.example.com The command connects to the remote X11 server via XDMCP (replace s390vm.example.com with the hostname of the remote X11 server) and displays the remote graphical login screen on display :1 of the X11 server system (usually accessible by using the Ctrl-Alt-F8 key combination). You can also access remote desktop sessions using a nested X11 server, which opens the remote desktop as a window in your current X11 session. Xnest allows users to open a remote desktop nested within their local X11 session. For example, run Xnest using the following command, replacing s390vm.example.com with the hostname of the remote X11 server: Xnest :1 -query s390vm.example.com 24.3.2. Problems When You Try to Log InIf you did not create a user account in the firstboot screens, switch to a console by pressing Ctrl+Alt+F2, log in as root and use the password you assigned to root. If you cannot remember your root password, boot your system into single user mode by appending the boot option single to the zipl boot menu or by any other means to append kernel command line options at IPL. Once you have booted into single user mode and have access to the # prompt, you must type passwd root, which allows you to enter a new password for root. At this point you can type shutdown -r now to reboot the system with the new root password. If you cannot remember your user account password, you must become root. To become root, type su - and enter your root password when prompted. Then, type passwd <username>. This allows you to enter a new password for the specified user account. If the graphical login screen does not appear, check your hardware for compatibility issues. The Hardware Compatibility List can be found at: http://hardware.redhat.com/hcl/ 24.3.3. Your Printer Does Not WorkIf you are not sure how to set up your printer or are having trouble getting it to work properly, try using the Printer Configuration Tool. Type the system-config-printer command at a shell prompt to launch the Printer Configuration Tool. If you are not root, it prompts you for the root password to continue. 24.3.4. Apache HTTP Server or Sendmail stops responding during startupIf Apache HTTP Server (httpd) or Sendmail stops responding during startup, make sure the following line is in the /etc/hosts file: 127.0.0.1 localhost.localdomain localhost Chapter 25. Configuring an Installed Linux on System z InstanceThe following is an example of how to set a DASD online, format it, and make the change persistent. Make sure the device is attached or linked to the Linux system if running under z/VM. CP ATTACH EB1C TO *
To link a mini disk to which you have access, issue, for example: CP LINK RHEL6X 4B2E 4B2E MR DASD 4B2E LINKED R/W
See the z/VM: CP Commands and Utilities Reference, SC24-6175 for details about the commands. 25.1.1. Dynamically setting DASDs onlineTo set a DASD online, follow these steps: Use the cio_ignore command to remove the DASD from the list of ignored devices and make it visible to Linux: # cio_ignore -r device_number
Replace device_number with the device number of the DASD. For example: # cio_ignore -r 4b2e
Set the device online. Use a command of the following form: # chccwdev -e device_number
Replace device_number with the device number of the DASD. For example: # chccwdev -e 4b2e
As an alternative, you can set the device online using sysfs attributes: Use the cd command to change to the /sys/ directory that represents that volume: # cd /sys/bus/ccw/drivers/dasd-eckd/0.0.4b2e/# ls -ltotal 0-r--r--r-- 1 root root 4096 Aug 25 17:04 availability-rw-r--r-- 1 root root 4096 Aug 25 17:04 cmb_enable-r--r--r-- 1 root root 4096 Aug 25 17:04 cutype-rw-r--r-- 1 root root 4096 Aug 25 17:04 detach_state-r--r--r-- 1 root root 4096 Aug 25 17:04 devtype-r--r--r-- 1 root root 4096 Aug 25 17:04 discipline-rw-r--r-- 1 root root 4096 Aug 25 17:04 online-rw-r--r-- 1 root root 4096 Aug 25 17:04 readonly-rw-r--r-- 1 root root 4096 Aug 25 17:04 use_diag Check to see if the device is already online: # cat online0 If it is not online, run the following command to bring it online: # echo 1 > online# cat online1
Verify which block devnode it is being accessed as: # ls -ltotal 0-r--r--r-- 1 root root 4096 Aug 25 17:04 availabilitylrwxrwxrwx 1 root root 0 Aug 25 17:07 block -> ../../../../block/dasdb-rw-r--r-- 1 root root 4096 Aug 25 17:04 cmb_enable-r--r--r-- 1 root root 4096 Aug 25 17:04 cutype-rw-r--r-- 1 root root 4096 Aug 25 17:04 detach_state-r--r--r-- 1 root root 4096 Aug 25 17:04 devtype-r--r--r-- 1 root root 4096 Aug 25 17:04 discipline-rw-r--r-- 1 root root 0 Aug 25 17:04 online-rw-r--r-- 1 root root 4096 Aug 25 17:04 readonly-rw-r--r-- 1 root root 4096 Aug 25 17:04 use_diag As shown in this example, device 4B2E is being accessed as /dev/dasdb.
These instructions set a DASD online for the current session, but this is not persistent across reboots. For instructions on how to set a DASD online persistently, refer to Section 25.1.3, "Persistently setting DASDs online". When you work with DASDs, use the persistent device symbolic links under /dev/disk/by-path/. You can find more information in the DASD Chapter in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6. 25.1.2. Preparing a new DASD with low-level formattingOnce the disk is online, change back to the /root directory and low-level format the device. This is only required once for a DASD during its entire lifetime: # cd# dasdfmt -b 4096 -d cdl -p /dev/disk/by-path/ccw-0.0.4b2e Drive Geometry: 10017 Cylinders * 15 Heads = 150255 Tracks I am going to format the device /dev/disk/by-path/ccw-0.0.4b2e in the following way: Device number of device : 0x4b2e Labelling device : yes Disk label : VOL1 Disk identifier : 0X4B2E Extent start (trk no) : 0 Extent end (trk no) : 150254 Compatible Disk Layout : yes Blocksize : 4096 --->> ATTENTION! <<--- All data of that device will be lost. Type "yes" to continue, no will leave the disk untouched: yescyl 97 of 3338 |#----------------------------------------------| 2% When the progress bar reaches the end and the format is complete, dasdfmt prints the following output: Rereading the partition table... Exiting... Now, use fdasd to partition the DASD. You can create up to three partitions on a DASD. In our example here, we create one partition spanning the whole disk: # fdasd -a /dev/disk/by-path/ccw-0.0.4b2eauto-creating one partition for the whole disk...writing volume label...writing VTOC...checking !wrote NATIVE!rereading partition table... For more information, see the chapter on DASD in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6. After a (low-level formatted) DASD is online, it can be used like any other disk under Linux. For instance, you can create file systems, LVM physical volumes, or swap space on its partitions, for example /dev/disk/by-path/ccw-0.0.4b2e-part1. Never use the full DASD device (dev/dasdb) for anything but the commands dasdfmt and fdasd. If you want to use the entire DASD, create one partition spanning the entire drive as in the fdasd example above. To add additional disks later without breaking existing disk entries in, for example, /etc/fstab, use the persistent device symbolic links under /dev/disk/by-path/. 25.1.3. Persistently setting DASDs onlineThe above instructions described how to activate DASDs dynamically in a running system. However, such changes are not persistent and do not survive a reboot. Making changes to the DASD configuration persistent in your Linux system depends on whether the DASDs belong to the root file system. Those DASDs required for the root file system need to be activated very early during the boot process by the initramfs to be able to mount the root file system. cio_ignore is handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually.
25.1.3.1. DASDs that are part of the root file systemThe only file you have to modify to add DASDs that are part of the root file system is /etc/zipl.conf. Then run the zipl boot loader tool. There is no need to recreate the initramfs. There are two boot parameters to activate DASDs early in the boot process: rd_DASD=
rd_DASD_MOD= - only provided for compatibility with old system configurations. Refer to the dasd= parameter description in the DASD device driver chapter in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6 for details.
The rd_DASD option takes a comma-separated list as input. The list contains a device bus ID and optional additional parameters consisting of key-value-pairs that correspond to DASD sysfs attributes. Below is an example zipl.conf for a system that uses physical volumes on partitions of two DASDs for an LVM volume group vg_devel1 that contains a logical volume lv_root for the root file system. [defaultboot]default=linuxtarget=/boot/[linux] image=/boot/vmlinuz-2.6.32-19.el6.s390x ramdisk=/boot/initramfs-2.6.32-19.el6.s390x.img parameters="root=/dev/mapper/vg_devel1-lv_root rd_DASD=0.0.0200,use_diag=0,readonly=0,erplog=0,failfast=0 rd_DASD=0.0.0207,use_diag=0,readonly=0,erplog=0,failfast=0 rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009" Suppose that you would like to add another physical volume on a partition of a third DASD with device bus ID 0.0.202b. To do this, simply add rd_DASD=0.0.202b to the parameters line of your boot kernel in zipl.conf: [defaultboot]default=linuxtarget=/boot/[linux] image=/boot/vmlinuz-2.6.32-19.el6.s390x ramdisk=/boot/initramfs-2.6.32-19.el6.s390x.img parameters="root=/dev/mapper/vg_devel1-lv_root rd_DASD=0.0.0200,use_diag=0,readonly=0,erplog=0,failfast=0 rd_DASD=0.0.0207,use_diag=0,readonly=0,erplog=0,failfast=0 rd_DASD=0.0.202b rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009" Run zipl to apply the changes of /etc/zipl.conf for the next IPL: # zipl -VUsing config file '/etc/zipl.conf'Target device information Device..........................: 5e:00 Partition.......................: 5e:01 Device name.....................: dasda DASD device number..............: 0201 Type............................: disk partition Disk layout.....................: ECKD/compatible disk layout Geometry - heads................: 15 Geometry - sectors..............: 12 Geometry - cylinders............: 3308 Geometry - start................: 24 File system block size..........: 4096 Physical block size.............: 4096 Device size in physical blocks..: 595416Building bootmap in '/boot/'Building menu 'rh-automatic-menu'Adding #1: IPL section 'linux' (default) kernel image......: /boot/vmlinuz-2.6.32-19.el6.s390x kernel parmline...: 'root=/dev/mapper/vg_devel1-lv_root rd_DASD=0.0.0200,use_diag=0,readonly=0,erplog=0,failfast=0 rd_DASD=0.0.0207,use_diag=0,readonly=0,erplog=0,failfast=0 rd_DASD=0.0.202b rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009' initial ramdisk...: /boot/initramfs-2.6.32-19.el6.s390x.img component address: kernel image....: 0x00010000-0x00a70fff parmline........: 0x00001000-0x00001fff initial ramdisk.: 0x02000000-0x022d2fff internal loader.: 0x0000a000-0x0000afff Preparing boot device: dasda (0201).Preparing boot menu Interactive prompt......: enabled Menu timeout............: 15 seconds Default configuration...: 'linux' Syncing disks...Done. 25.1.3.2. DASDs that are not part of the root file systemDASDs that are not part of the root file system, that is, data disks, are persistently configured in the file /etc/dasd.conf. It contains one DASD per line. Each line begins with the device bus ID of a DASD. Optionally, each line can continue with options separated by space or tab characters. Options consist of key-value-pairs, where the key and value are separated by an equals sign. The key corresponds to any valid sysfs attribute a DASD may have. The value will be written to the key's sysfs attribute. Entries in /etc/dasd.conf are activated and configured by udev when a DASD is added to the system. At boot time, all DASDs visible to the system get added and trigger udev. Example content of /etc/dasd.conf: 0.0.02070.0.0200 use_diag=1 readonly=1 Modifications of /etc/dasd.conf only become effective after a reboot of the system or after the dynamic addition of a new DASD by changing the system's I/O configuration (that is, the DASD is attached under z/VM). Alternatively, you can trigger the activation of a new entry in /etc/dasd.conf for a DASD which was previously not active, by executing the following commands: Use the cio_ignore command to remove the DASD from the list of ignored devices and make it visible to Linux: # cio_ignore -r device_number
For example: # cio_ignore -r 021a
Trigger the activation by writing to the uevent attribute of the device: echo add > /sys/bus/ccw/devices/device-bus-ID/uevent
For example: echo add > /sys/bus/ccw/devices/0.0.021a/uevent
25.2. Adding FCP-Attached Logical Units (LUNs)The following is an example of how to add an FCP LUN. If running under z/VM, make sure the FCP adapter is attached to the z/VM guest virtual machine. For multipathing in production environments there would be at least two FCP devices on two different physical adapters (CHPIDs). For example: CP ATTACH FC00 TO * CP ATTACH FCD0 TO *
25.2.1. Dynamically activating an FCP LUNFollow these steps to activate a LUN: Use the cio_ignore command to remove the FCP adapter from the list of ignored devices and make it visible to Linux: # cio_ignore -r device_number
Replace device_number with the device number of the FCP adapter. For example: To bring the FCP adapter device online, use the following command: # chccwdev -e fc00
Verify that the required WWPN was found by the automatic port scanning of the zfcp device driver: # ls -l /sys/bus/ccw/drivers/zfcp/0.0.fc00/drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630040710bdrwxr-xr-x. 3 root root 0 Apr 28 18:19 0x50050763050b073ddrwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630e060521drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630e860521-r--r--r--. 1 root root 4096 Apr 28 18:17 availability-r--r--r--. 1 root root 4096 Apr 28 18:19 card_version-rw-r--r--. 1 root root 4096 Apr 28 18:17 cmb_enable-r--r--r--. 1 root root 4096 Apr 28 18:17 cutype-r--r--r--. 1 root root 4096 Apr 28 18:17 devtypelrwxrwxrwx. 1 root root 0 Apr 28 18:17 driver -> ../../../../bus/ccw/drivers/zfcp-rw-r--r--. 1 root root 4096 Apr 28 18:17 failed-r--r--r--. 1 root root 4096 Apr 28 18:19 hardware_versiondrwxr-xr-x. 35 root root 0 Apr 28 18:17 host0-r--r--r--. 1 root root 4096 Apr 28 18:17 in_recovery-r--r--r--. 1 root root 4096 Apr 28 18:19 lic_version-r--r--r--. 1 root root 4096 Apr 28 18:17 modalias-rw-r--r--. 1 root root 4096 Apr 28 18:17 online-r--r--r--. 1 root root 4096 Apr 28 18:19 peer_d_id-r--r--r--. 1 root root 4096 Apr 28 18:19 peer_wwnn-r--r--r--. 1 root root 4096 Apr 28 18:19 peer_wwpn--w-------. 1 root root 4096 Apr 28 18:19 port_remove--w-------. 1 root root 4096 Apr 28 18:19 port_rescandrwxr-xr-x. 2 root root 0 Apr 28 18:19 power-r--r--r--. 1 root root 4096 Apr 28 18:19 statuslrwxrwxrwx. 1 root root 0 Apr 28 18:17 subsystem -> ../../../../bus/ccw-rw-r--r--. 1 root root 4096 Apr 28 18:17 uevent Activate the FCP LUN by adding it to the port (WWPN) through which you would like to access the LUN: # echo 0x4020400100000000 > /sys/bus/ccw/drivers/zfcp/0.0.fc00/0x50050763050b073d/unit_add
Find out the assigned SCSI device name: # lszfcp -DV/sys/devices/css0/0.0.0015/0.0.fc00/0x50050763050b073d/0x4020400100000000/sys/bus/ccw/drivers/zfcp/0.0.fc00/host0/rport-0:0-21/target0:0:21/0:0:21:1089355792
For more information, refer to the chapter on SCSI-over-Fibre Channel in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6. 25.2.2. Persistently activating FCP LUNsThe above instructions described how to activate FCP LUNs dynamically in a running system. However, such changes are not persistent and do not survive a reboot. How you make the changes to the FCP configuration persistent in your Linux system depends on whether the FCP LUNs belong to the root file system. Those required for the root file system need to be activated very early during the boot process by the initramfs to be able to mount the root file system. cio_ignore is handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually. 25.2.2.1. FCP LUNs that are part of the root file systemThe only file you have to modify for adding FCP LUNs that are part of the root file system is /etc/zipl.conf followed by a run of the zipl boot loader tool. There is no more need to recreate the initramfs. Red Hat Enterprise Linux provides a parameter to activate FCP LUNs early in the boot process: rd_ZFCP=. The value is a comma-separated list containing the device bus ID, the WWPN as 16 digit hexadecimal number prefixed with 0x, and the FCP LUN prefixed with 0x and padded with zeroes to the right to have 16 hexadecimal digits. The following example zipl.conf is for a system that uses physical volumes on partitions of two FCP LUNs for an LVM volume group vg_devel1 that contains a logical volume lv_root for the root file system. For simplicity, the example shows a configuration without multipathing. [defaultboot]default=linuxtarget=/boot/[linux]image=/boot/vmlinuz-2.6.32-19.el6.s390xramdisk=/boot/initramfs-2.6.32-19.el6.s390x.imgparameters="root=/dev/mapper/vg_devel1-lv_root rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a100000000 rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009" To add another physical volume on a partition of a third FCP LUN with device bus ID 0.0.fc00, WWPN 0x5105074308c212e9 and FCP LUN 0x401040a300000000, simply add rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a300000000 to the parameters line of your boot kernel in zipl.conf, for example: [defaultboot]default=linuxtarget=/boot/[linux]image=/boot/vmlinuz-2.6.32-19.el6.s390xramdisk=/boot/initramfs-2.6.32-19.el6.s390x.imgparameters="root=/dev/mapper/vg_devel1-lv_root rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a100000000 rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a300000000rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009" Run zipl to apply the changes of /etc/zipl.conf for the next IPL: # zipl -VUsing config file '/etc/zipl.conf'Target device informationDevice..........................: 08:00Partition.......................: 08:01Device name.....................: sdaDevice driver name..............: sdType............................: disk partitionDisk layout.....................: SCSI disk layoutGeometry - start................: 2048File system block size..........: 4096Physical block size.............: 512Device size in physical blocks..: 10074112Building bootmap in '/boot/'Building menu 'rh-automatic-menu'Adding #1: IPL section 'linux' (default)kernel image......: /boot/vmlinuz-2.6.32-19.el6.s390xkernel parmline...: 'root=/dev/mapper/vg_devel1-lv_root rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a000000000 rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a100000000 rd_ZFCP=0.0.fc00,0x5105074308c212e9,0x401040a300000000 rd_LVM_LV=vg_devel1/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us cio_ignore=all,!0.0.0009'initial ramdisk...: /boot/initramfs-2.6.32-19.el6.s390x.imgcomponent address:kernel image....: 0x00010000-0x007a21ffparmline........: 0x00001000-0x000011ffinitial ramdisk.: 0x02000000-0x028f63ffinternal loader.: 0x0000a000-0x0000a3ffPreparing boot device: sda.Detected SCSI PCBIOS disk layout.Writing SCSI master boot record.Syncing disks...Done. 25.2.2.2. FCP LUNs that are not part of the root file systemFCP LUNs that are not part of the root file system, such as data disks, are persistently configured in the file /etc/zfcp.conf. It contains one FCP LUN per line. Each line contains the device bus ID of the FCP adapter, the WWPN as 16 digit hexadecimal number prefixed with 0x, and the FCP LUN prefixed with 0x and padded with zeroes to the right to have 16 hexadecimal digits, separated by a space or tab. Entries in /etc/zfcp.conf are activated and configured by udev when an FCP adapter is added to the system. At boot time, all FCP adapters visible to the system are added and trigger udev. Example content of /etc/zfcp.conf: 0.0.fc00 0x5105074308c212e9 0x401040a0000000000.0.fc00 0x5105074308c212e9 0x401040a1000000000.0.fc00 0x5105074308c212e9 0x401040a3000000000.0.fcd0 0x5105074308c2aee9 0x401040a0000000000.0.fcd0 0x5105074308c2aee9 0x401040a1000000000.0.fcd0 0x5105074308c2aee9 0x401040a300000000 Modifications of /etc/zfcp.conf only become effective after a reboot of the system or after the dynamic addition of a new FCP channel by changing the system's I/O configuration (for example, a channel is attached under z/VM). Alternatively, you can trigger the activation of a new entry in /etc/zfcp.conf for an FCP adapter which was previously not active, by executing the following commands: Use the cio_ignore command to remove the FCP adapter from the list of ignored devices and make it visible to Linux: # cio_ignore -r device_number
Replace device_number with the device number of the FCP adapter. For example: # cio_ignore -r fcfc
To trigger the uevent that activates the change, issue: echo add > /sys/bus/ccw/devices/device-bus-ID/uevent
For example: echo add > /sys/bus/ccw/devices/0.0.fcfc/uevent
25.3. Adding a Network DeviceNetwork device driver modules are loaded automatically by udev. You can add a network interface on IBM System z dynamically or persistently. Dynamically Load the device driver Remove the network devices from the list of ignored devices. Create the group device. Configure the device. Set the device online.
Persistently Create a configuration script. Activate the interface.
25.3.1. Adding a qeth DeviceThe qeth network device driver supports System z OSA-Express features in QDIO mode, HiperSockets, z/VM guest LAN, and z/VM VSWITCH. Based on the type of interface being added, the qeth device driver assigns one of the base interface names: The value n is an integer that uniquely identifies the device. n is 0 for the first device of that type, 1 for the second, and so on. 25.3.1.1. Dynamically adding a qeth deviceTo add a qeth device dynamically, follow these steps: Determine whether the qeth device driver modules are loaded. The following example shows loaded qeth modules: # lsmod | grep qethqeth_l3 127056 9qeth_l2 73008 3ipv6 492872 155ip6t_REJECT,nf_conntrack_ipv6,qeth_l3qeth 115808 2 qeth_l3,qeth_l2qdio 68240 1 qethccwgroup 12112 2 qeth If the output of the lsmod command shows that the qeth modules are not loaded, run the modprobe command to load them: # modprobe qeth
Use the cio_ignore command to remove the network channels from the list of ignored devices and make them visible to Linux: # cio_ignore -r read_device_bus_id,write_device_bus_id,data_device_bus_id
Replace read_device_bus_id,write_device_bus_id,data_device_bus_id with the three device bus IDs representing a network device. For example, if the read_device_bus_id is 0.0.f500, the write_device_bus_id is 0.0.f501, and the data_device_bus_id is 0.0.f502: # cio_ignore -r 0.0.f500,0.0.f501,0.0.f502
Use the znetconf command to sense and list candidate configurations for network devices: # znetconf -uScanning for network devices...Device IDs Type Card Type CHPID Drv. ------------------------------------------------------------0.0.f500,0.0.f501,0.0.f502 1731/01 OSA (QDIO) 00 qeth 0.0.f503,0.0.f504,0.0.f505 1731/01 OSA (QDIO) 01 qeth 0.0.0400,0.0.0401,0.0.0402 1731/05 HiperSockets 02 qeth Select the configuration you want to work with and use znetconf to apply the configuration and to bring the configured group device online as network device. # znetconf -a f500Scanning for network devices...Successfully configured device 0.0.f500 (eth1) Optionally, you can also pass arguments that are configured on the group device before it is set online: # znetconf -a f500 -o portname=mynameScanning for network devices...Successfully configured device 0.0.f500 (eth1) Now you can continue to configure the network eth1 interface.
Alternatively, you can use sysfs attributes to set the device online as follows: Create a qeth group device: # echo read_device_bus_id,write_device_bus_id,data_device_bus_id > /sys/bus/ccwgroup/drivers/qeth/group
For example: # echo 0.0.f500,0.0.f501,0.0.f502 > /sys/bus/ccwgroup/drivers/qeth/group
Next, verify that the qeth group device was created properly by looking for the read channel: # ls /sys/bus/ccwgroup/drivers/qeth/0.0.f500
You may optionally set additional parameters and features, depending on the way you are setting up your system and the features you require, such as: For information on additional parameters, refer to the chapter on the qeth device driver in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6. Bring the device online by writing 1 to the online sysfs attribute: # echo 1 > /sys/bus/ccwgroup/drivers/qeth/0.0.f500/online
Then verify the state of the device: # cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/online1
A return value of 1 indicates that the device is online, while a return value 0 indicates that the device is offline. Find the interface name that was assigned to the device: # cat /sys/bus/ccwgroup/drivers/qeth/0.0.f500/if_nameeth1
Now you can continue to configure the network eth1 interface. The following command from the s390utils package shows the most important settings of your qeth device: # lsqeth eth1Device name : eth1 --------------------------------------------- card_type : OSD_1000 cdev0 : 0.0.f500 cdev1 : 0.0.f501 cdev2 : 0.0.f502 chpid : 76 online : 1 portname : OSAPORT portno : 0 state : UP (LAN ONLINE) priority_queueing : always queue 0 buffer_count : 16 layer2 : 1 isolation : none
25.3.1.2. Dynamically removing a qeth deviceTo remove a qeth device, use the znetconf tool. For example: Use the znetconf command to show you all configured network devices: znetconf -cDevice IDs Type Card Type CHPID Drv. Name State --------------------------------------------------------------------------------0.0.8036,0.0.8037,0.0.8038 1731/05 HiperSockets FB qeth hsi1 online 0.0.f5f0,0.0.f5f1,0.0.f5f2 1731/01 OSD_1000 76 qeth eth0 online 0.0.f500,0.0.f501,0.0.f502 1731/01 GuestLAN QDIO 00 qeth eth1 online Select the network device to be removed and trigger znetconf to set the device offline and ungroup the ccw group device. # znetconf -r f500Remove network device 0.0.f500 (0.0.f500,0.0.f501,0.0.f502)?Warning: this may affect network connectivity!Do you want to continue (y/n)?ySuccessfully removed device 0.0.f500 (eth1) Verify the success of the removal: znetconf -cDevice IDs Type Card Type CHPID Drv. Name State --------------------------------------------------------------------------------0.0.8036,0.0.8037,0.0.8038 1731/05 HiperSockets FB qeth hsi1 online 0.0.f5f0,0.0.f5f1,0.0.f5f2 1731/01 OSD_1000 76 qeth eth0 online
25.3.1.3. Persistently adding a qeth deviceTo make your new qeth device persistent you need to create the configuration file for your new interface. The network interface configuration files are placed in /etc/sysconfig/network-scripts/. The network configuration files use the naming convention ifcfg-device, where device is the value found in the if_name file in the qeth group device that was created earlier. In this example it is eth1. cio_ignore is handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually. If a configuration file for another device of the same type already exists, the simplest solution is to copy it to the new name. # cd /etc/sysconfig/network-scripts# cp ifcfg-eth0 ifcfg-eth1 If you do not have a similar device defined you must create one. Use this example of ifcfg-eth0 as a template: /etc/sysconfig/network-scripts/ifcfg-eth0
# IBM QETHDEVICE=eth0BOOTPROTO=staticIPADDR=10.12.20.136NETMASK=255.255.255.0ONBOOT=yesNETTYPE=qethSUBCHANNELS=0.0.09a0,0.0.09a1,0.0.09a2PORTNAME=OSAPORTOPTIONS='layer2=1 portno=0'MACADDR=02:00:00:23:65:1aTYPE=Ethernet Edit the new ifcfg-eth1 file as follows: Modify the DEVICE statement to reflect the contents of the if_name file from your ccwgroup. Modify the IPADDR statement to reflect the IP address of your new interface. Modify the NETMASK statement as needed. If the new interface is to be activated at boot time, then make sure ONBOOT is set to yes. Make sure the SUBCHANNELS statement matches the hardware addresses for your qeth device. Modify the PORTNAME statement or leave it out if it is not necessary in your environment. You may add any valid sysfs attribute and its value to the OPTIONS parameter. The Red Hat Enterprise Linux installer currently uses this to configure the layer mode (layer2) and the relative port number (portno) of qeth devices. The qeth device driver default for OSA devices is now layer 2 mode. To continue using old ifcfg definitions that rely on the previous default of layer 3 mode, add layer2=0 to the OPTIONS parameter.
/etc/sysconfig/network-scripts/ifcfg-eth1
# IBM QETHDEVICE=eth1BOOTPROTO=staticIPADDR=192.168.70.87NETMASK=255.255.255.0ONBOOT=yesNETTYPE=qethSUBCHANNELS=0.0.0600,0.0.0601,0.0.0602PORTNAME=OSAPORTOPTIONS='layer2=1 portno=0'MACADDR=02:00:00:b3:84:efTYPE=Ethernet Changes to an ifcfg file only become effective after rebooting the system or after the dynamic addition of new network device channels by changing the system's I/O configuration (for example, attaching under z/VM). Alternatively, you can trigger the activation of a ifcfg file for network channels which were previously not active yet, by executing the following commands: Use the cio_ignore command to remove the network channels from the list of ignored devices and make them visible to Linux: # cio_ignore -r read_device_bus_id,write_device_bus_id,data_device_bus_id
Replace read_device_bus_id,write_device_bus_id,data_device_bus_id with the three device bus IDs representing a network device. For example, if the read_device_bus_id is 0.0.0600, the write_device_bus_id is 0.0.0601, and the data_device_bus_id is 0.0.0602: # cio_ignore -r 0.0.0600,0.0.0601,0.0.0602
To trigger the uevent that activates the change, issue: echo add > /sys/bus/ccw/devices/read-channel/uevent
For example: echo add > /sys/bus/ccw/devices/0.0.0600/uevent
Check the status of the network device: # lsqeth
Now start the new interface: # ifup eth1
Check the status of the interface: # ifconfig eth1eth1 Link encap:Ethernet HWaddr 02:00:00:00:00:01 inet addr:192.168.70.87 Bcast:192.168.70.255 Mask:255.255.255.0 inet6 addr: fe80::ff:fe00:1/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:23 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:644 (644.0 b) TX bytes:264 (264.0 b) Check the routing for the new interface: # routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface192.168.70.0 * 255.255.255.0 U 0 0 0 eth110.1.20.0 * 255.255.255.0 U 0 0 0 eth0default 10.1.20.1 0.0.0.0 UG 0 0 0 eth0 Verify your changes by using the ping command to ping the gateway or another host on the subnet of the new device: # ping -c 1 192.168.70.8PING 192.168.70.8 (192.168.70.8) 56(84) bytes of data.64 bytes from 192.168.70.8: icmp_seq=0 ttl=63 time=8.07 ms If the default route information has changed, you must also update /etc/sysconfig/network accordingly.
25.3.2. Adding an LCS DeviceThe LAN channel station (LCS) device driver supports 1000Base-T Ethernet on the OSA-Express2 and OSA-Express 3 features. Based on the type of interface being added, the LCS driver assigns one base interface name: n is 0 for the first device of that type, 1 for the second, and so on.
25.3.2.1. Dynamically adding an LCS deviceLoad the device driver: # modprobe lcs
Use the cio_ignore command to remove the network channels from the list of ignored devices and make them visible to Linux: # cio_ignore -r read_device_bus_id,write_device_bus_id
Replace read_device_bus_id and write_device_bus_id with the two device bus IDs representing a network device. For example: # cio_ignore -r 0.0.09a0,0.0.09a1
Create the group device: # echo read_device_bus_id,write_device_bus_id > /sys/bus/ccwgroup/drivers/lcs/group
Configure the device. OSA cards can provide up to 16 ports for a single CHPID. By default, the LCS group device uses port 0. To use a different port, issue a command similar to the following: # echo portno > /sys/bus/ccwgroup/drivers/lcs/device_bus_id/portno
Replace portno with the port number you want to use. For more information about configuration of the LCS driver, refer to the chapter on LCS in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6. Set the device online: # echo 1 > /sys/bus/ccwgroup/drivers/lcs/read_device_bus_id/online
To find out what network device name has been assigned, enter the command: # ls -l /sys/bus/ccwgroup/drivers/lcs/read_device_bus_ID/net/drwxr-xr-x 4 root root 0 2010-04-22 16:54 eth1
25.3.2.2. Persistently adding an LCS devicecio_ignore is handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually.
To add an LCS device persistently, follow these steps: Create a configuration script as file in /etc/sysconfig/network-scripts/ with a name like ifcfg-ethn where n is an integer starting with 0. The file should look similar to the following: /etc/sysconfig/network-scripts/ifcfg-eth0# IBM LCSDEVICE=eth0BOOTPROTO=staticIPADDR=10.12.20.136NETMASK=255.255.255.0ONBOOT=yesNETTYPE=lcsSUBCHANNELS=0.0.09a0,0.0.09a1PORTNAME=0OPTIONS=''TYPE=Ethernet Set the DEVICE parameter as follows: DEVICE=ethn Issue an ifup command to activate the device: # ifup ethn
Changes to an ifcfg file only become effective after rebooting the system. You can trigger the activation of a ifcfg file for network channels by executing the following commands: Use the cio_ignore command to remove the LCS device adapter from the list of ignored devices and make it visible to Linux: # cio_ignore -r read_device_bus_id,write_device_bus_id
Replace read_device_bus_id and write_device_bus_id with the device bus IDs of the LCS device. For example: # cio_ignore -r 0.0.09a0,0.0.09a1
To trigger the uevent that activates the change, issue: echo add > /sys/bus/ccw/devices/read-channel/uevent
For example: echo add > /sys/bus/ccw/devices/0.0.09a0/uevent
25.3.3. Mapping subchannels and network device namesThe DEVICE= option in the ifcfg file does not determine the mapping of subchannels to network device names. Instead, the udev rules file /etc/udev/rules.d/70-persistent-net.rules determines which network device channel gets which network device name. When configuring a new network device on System z, the system automatically adds a new rule to that file and assigns the next unused device name. You can then edit the values assigned to the NAME= variable for each device. Example content of /etc/udev/rules.d/70-persistent-net.rules: # This file was automatically generated by the /lib/udev/write_net_rules # program run by the persistent-net-generator.rules rules file. # # You can modify it,as long as you keep each rule on a single line. # S/390 qeth device at 0.0.f5f0 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.f5f0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # S/390 ctcm device at 0.0.1000 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ctcm", KERNELS=="0.0.1000", ATTR{type}=="256", KERNEL=="ctc*", NAME="ctc0" # S/390 qeth device at 0.0.8024 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8024", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi0" # S/390 qeth device at 0.0.8124 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8124", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi1" # S/390 qeth device at 0.0.1017 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1017", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" # S/390 qeth device at 0.0.8324 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8324", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi3" # S/390 qeth device at 0.0.8224 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8224", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi2" # S/390 qeth device at 0.0.1010 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1010", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" # S/390 lcs device at 0.0.1240SUBSYSTEM=="net", ACTION=="add", DRIVERS=="lcs", KERNELS=="0.0.1240", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # S/390 qeth device at 0.0.1013 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1013", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi4"25.3.4. Configuring a System z Network Device for Network Root File SystemTo add a network device that is required to access the root file system, you only have to change the boot options. The boot options can be in a parameter file (refer to Chapter 26, Parameter and Configuration Files) or part of a zipl.conf on a DASD or FCP-attached SCSI LUN prepared with the zipl boot loader. There is no need to recreate the initramfs. Dracut (the mkinitrd successor that provides the functionality in the initramfs that in turn replaces initrd) provides a boot parameter to activate network devices on System z early in the boot process: rd_ZNET=. As input, this parameter takes a comma-separated list of the NETTYPE (qeth, lcs, ctc), two (lcs, ctc) or three (qeth) device bus IDs, and optional additional parameters consisting of key-value pairs corresponding to network device sysfs attributes. This parameter configures and activates the System z network hardware. The configuration of IP addresses and other network specifics works the same as for other platforms. Refer to the dracut documentation for more details. cio_ignore for the network channels is handled transparently on boot. Example boot options for a root file system accessed over the network through NFS: root=10.16.105.196:/nfs/nfs_root cio_ignore=all,!0.0.0009 rd_ZNET=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=OSAPORT ip=10.16.105.197:10.16.105.196:10.16.111.254:255.255.248.0:nfs‑server.subdomain.domain:eth0:none rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us |
| |
