Red Hat Linux 7.1 for zSeries Release Notes =========================================== Feedback is always appreciated and can be provided both via: - Bugzilla Defect Tracking System https://bugzilla.redhat.com/bugzilla/ - Mailing List https://listman.redhat.com/mailman/listinfo/redhat-s390-list General Notes ============= - This release runs on zSeries (64-bit, z800 and z900) hardware in 64-bit mode. - Fully supported network interfaces include LCS, CTC, Escon and IUCV. - QETH Ethernet, Token Ring and HiperSockets networking is available with IBM's OCO modules. See the section "IBM's OCO Modules" in the README file for information. - ext2 and ext3 filesystems are supported both with and without Software RAID. - There are multiple ways to install Red Hat Linux 7.1 for zSeries. See the README file for information on the various installer options and methods for installing. Both the Anaconda "loader" installer and the "rhsetup" installer are included. - Since Red Hat do not have access to an unlimited number of network interfaces and cannot test all possible combinations of installation choices, feedback about any problems encountered during installation or any incorrect configuration files created during installation is appreciated. - The x3270-text package offers a text-based 3270 emulator called c3270. "Ctrl-a c" or "Ctrl-c" can be used to clear the screen in c3270. ("Alt-c" clears the screen in x3270.) - Some S/390 and zSeries VM systems may not support the issuing of CP commands with "#cp " from the 3270 console whilst Linux is running. In this case, use of the ATTN/attention key may place the 3270 terminal into CP READ mode (Alt-A in x3270). - If you are using z/VM, ensure you have applied the following APARs, otherwise you may have problems with PFAULT: - UM30216 - z/VM 3.1.0 - UM30219 - z/VM 4.1.0 - UM30218 - z/VM 4.2.0 - If using 3390-3 DASDs, it may be necessary to use more than one DASD for an installation. Red Hat recommends "/usr/share" as a mount point to consider, to balance DASD use between two DASDs. - Software RAID is also included to effectively remove the size limitations imposed by DASD model sizes. Anaconda supports creation of RAID0 devices that span multiple partitions on multiple DASDs. - Firewall Configuration -- If you are using Anaconda to install, you can configure a firewall as part of your system installation for additional security. You can choose from two levels of security, as well as choosing which common system services should be allowed or disallowed by default. Please note that both "medium" and "high" firewall settings will cause RPC-based services (such as NIS or NFS) to be blocked and fail to initialize. - If you boot the first time after the installation has finished, you can only log in over the network using ssh, since the telnet daemon is not enabled by default. Also, remember that if you choose a "medium" or "high" firewall setting you MUST enable inbound SSH access; otherwise, SSH will also be unavailable. - The following packages/features are deprecated, and may be removed in a future Red Hat Linux release: - Enlightenment window manager - Linuxconf - Ncpfs Anaconda/rhsetup Installer Notes ================================ Boot loader ---------- - z/IPL is the standard boot loader used. Zilo is outdated and is no longer supported. - z/IPL does not support the selection of a specific kernel during IPL. The only way to switch between different kernel versions is to install different boot loaders on different DASDs, and IPL the corresponding DASD. - To boot into single-user mode from VM, create a parameter file with the parameter "single", and boot the kernel using the installation scripts rather than IPLing directly from the DASD. - To boot an LPAR in single user mode, simply add the parameter "single" when loading the LPAR. Partitioning with Anaconda / "loader" ------------------------------------- - The EXT3 journaling file system is now available. - To create swap partitions, select the ext2/ext3 box and scroll down, the swap entry is hidden there. - Pre-existing file systems may be selected for reformatting during the installation. - Pre-existing ext2 file systems may be migrated to ext3 during installs and upgrades. This process does not affect the data on the file system. - Additional sanity checks have been made against user-created mount points; this should avoid most common problems (such as a "/" mount point of only 5 MB). - Up to three partitions are supported per DASD (e.g. dasda1, dasda2, dasda3). - Only the z/OS Compatible Disk Layout (CDL) is supported. Linux Disk Layout (LDL) is not supported. - New partitions can only be created using the fdasd method. Partitioning with "rhsetup" --------------------------- - The rhsetup installation program does not support multiple partitions on one DASD, while Anaconda does. If you select a DASD to initialize, it will format with CDL and automatically create a single partition. - Swap must be configured from the parameter file. You cannot set up swap from the installation program. - Linux Disk Layout (LDL) can be used, however Compatible Disk Layout (CDL) is recommended. rhsetup can convert DASDs from LDL to CDL. Kickstart --------- - Kickstart is currently not supported on zSeries. An (almost) non-interactive installation is possible with the rhsetup installation program when all necessary parameters are given in the .prm file. Miscellaneous ------------- - The individual package selection screen of Anaconda now supports a flat view of all packages. - For FTP-based Anaconda installation, it is now possible to loopback mount the Red Hat Linux ISO images on an FTP server. The ISO images should be loopback mounted as /disc1, /disc2, and so on -- in the same directory. This directory should then be specified when an FTP-based installation is started. - If you already have an working Linux system on your mainframe, you can install from loopback mounted CD images on a local DASD. - In order to maximize space in the install image, the BusyBox program now provides support for many commonly-used commands. Kernel Notes ============ - The QETH and QDIO modules are proprietary OCO (Object Code Only) drivers. Consequently it means that they cannot be supported by Red Hat, and they also cannot be included as a part of the standard Red Hat Linux 7.1 for zSeries distribution. Visit the IBM DeveloperWorks site, or contact IBM for modules which correspond to the version of the kernel you are using. See the section "IBM's OCO Modules" in the README file for information on the steps required to add QETH/QDIO networking into the Red Hat Linux installer environment and subsequent installed system. - The kernel now includes the ext3 journalling file system. This file system has three modes of operation: - 'ordered' - 'journal' - 'writeback' The default is 'ordered', which will make sure that after a crash you should always see valid data in recently-written files. The 'writeback' mode can be faster in some cases, but it does not force data to disk so rigorously; therefore, after a crash you may see corruption in recently-written files. The 'journal' mode copies all data to the journal, and can result in great speed boosts if you are performing lots of synchronous data writes (for example, on mail spools or synchronous NFS servers). However, in normal use 'journal' mode is usually significantly slower. The mode is set by using the 'data=' mount option in /etc/fstab or as 'mount -o data=' on the mount command line. Normally, an ext2 file system is checked automatically once either a certain period of time or a given number of mounts have passed since the file system was last checked. At these times, a full 'fsck' (file system check) of the file system will be forced at system boot time in order to check the integrity of the file system. When the installation program creates an ext3 file system or upgrades an ext2 file system to ext3, it disables these automatic checks. Use 'tune2fs' with the '-c' and/or '-i' options to re-enable them, or to disable them on ext3 file systems that you create manually. Note that these cleanup fsck scans have nothing to do with the file system's behavior when an error is discovered on disk, or when a crash occurs. If a file system consistency error is found on disk, then on subsequent reboot a fsck will always be forced, both for ext2 and ext3 file systems. If a crash occurs on an otherwise intact file system, ext2 will always force a fsck, and ext3 will always perform its file system recovery step; these cleanups are not affected by the 'tune2fs' forced-check interval settings. Please keep in mind that even a journaling file system can be damaged by power loss. When a system loses power, that system's behavior is undefined. For example, memory contents can decay (become randomly corrupt) as the contents are copied to a hard drive running on the last bit of power. This is a fundamentally different situation from the more defined sequence of events caused by pressing the system's "reset" button while the system is running. Therefore, after a system crash, you will be offered a chance to choose to check the integrity of your file systems. The file /.autofsck is the "crash flag" used to provide this functionality. You will be given five seconds to type "y" to check your file systems during a boot after your system has crashed for any reason. Directory Sizes After a Complete "Everything" Installation ========================================================== Directory Size in MB /usr 2300 /usr/bin 300 /usr/lib 950 /usr/share 1100 /usr/X11R6 150 /var 90 Some Known Issues To Consider ============================= - If you are using Shark DASD (2105) you should be careful not to define an IPL volume on any device that has designated as a PAV volume. This is not supported and will prevent the system from IPLing. - Heavy stress testing of IBM Java SDK 1.3.1 running under 31-bit compatibility has revealed a segmentation violation in the java process - under certain conditions. This issue will be addressed as more information becomes available. - Emacs is currently not working in X11 mode. Please use either XEmacs or 'emacs -nw' - If NFS is performing poorly, or is resulting in errors appearing in /var/log/messages, e.g.: kernel: nfs: task can't get a request slot kernel: nfs: server not responding, still trying you should specify the following options when mounting the NFS share: rsize=1024,wsize=1024,hard - Software RAID1 is not supported in the installer due to an observed issue with synchronization. This issue being investigated further. - Due to some outstanding problems with the compilation of the Mozilla source code for the s390x architecture, Mozilla is not available in this release. This means that Galeon and Nautilus also cannot render web pages, thus Galeon is also not included. Netscape Communicator 4.x is not released for this architecutre, so for web browsing purposes, you may use Konqueror, lynx or links. - Relating to the above Mozilla issue, Help is unavailable inside the graphical printconf-gui tool. Alternatively, printconf-gui help is available if you open a web browser and browse the documentation at /usr/share/doc/printconf-gui/ or file:///usr/share/doc/printconf-gui/ - We got one bug report that KDM doesn't work in combination with Exceed. If you encounter a similar problem, consider using either gdm or xdm. - GnoRPM - a problem exists wherein "--allmatches --nodeps" is used, by default, when removing packages. This is an issue if, for example, one installs a new kernel with "rpm -ivh" but then decides to remove the old kernel with GnoRPM. Red Hat recommends against using GnoRPM to remove any important packages from the system, including the kernel packages. - mcserv appears not to allow remote connections from other mc clients. Starting the mcserv service (with "service mcserv start") appears to work, however when an mc client tries to connect the error returned is "MCFS invalid password". This problem is not specific to the S/390 or zSeries architecture. - If using an OpenSSH ssh client to connect to the installer environment is unsuccessful, then you may consider forcing the use of version 1 of the SSH protocol with: ssh -o "Protocol 1" root@ or ssh -1 root@ - If you receive an "Unknown terminal" error when attempting to run "loader" or "rhsetup", you may need to set the TERM environment variable. You can force the specification of a particular terminal type in the installer environment before starting the installer with: export TERM= (where term-type may for example be "linux", "vt100" or "xterm") - Ensure that you do provide a FQDN rather than a simple hostname when prompted (FQDN = fully qualified domain name). This is of particular importance if performing a network installation via FTP. - If you are performing an installation of Red Hat Linux onto a new DASD that has never previously been initialized with either CDL or LDL, you may encounter a situation where even though initialization (with dasdfmt) and partitioning (with fdasd) is successful, Anaconda cannot detect the device to allow mount points to be assigned and partitions to be formatted. In this event, simply re-IPL the installer environment (e.g. with #cp i 00c) and Anaconda should now successfully detect the new DASD device and allow full use of that DASD. - Sometimes DASD devices may be marked "active", but are not completely formatted. In this event, DASD error messages and file system error messages will be output from the Linux kernel to the console during installation. In this case, use "dasdfmt" to completely re-format and re-initialize the DASD, and then partition it with "fdasd". - During installation over CTC devices the MTU is automatically lowered to 4096 instead of the default 32760 as we observed network hangs for the default MTU size. After installation the MTU size is not modified as we haven't seen this behaviour in post installation. If you should encounter network hangs after installation try lowering the MTU size of your CTC device like this: ifconfig ctc0 mtu 4096 (where ctc0 is your CTC device - change if necessary) To make this change permanent across IPLs, add the line: MTU=4096 to the file /etc/sysconfig/network-scripts/ifcfg-ctc0 . ----- RHL 7.1 s390x