Release Notes for SUSE Linux Enterprise Server 9 Service Pack 1 ===================================================================== 0. Overview: ------------ 1. Important general info 1.1 Purpose 2. Enhancements 2.1 Installation / YaST2 2.2 Platforms / Hardware / Drivers 2.3 Standards 2.4 Availability 2.5 Serviceability 2.6 Scalability 2.7 Performance 2.8 Security 2.9 Applications and Tools 2.10 New packages introduced with SP1 3. Maintenance fixes 3.1 Bug fixes 3.2 Security fixes 4. Updating from SLES 9 to SP1 4.1 Using the CD autorun mechanism 4.2 Calling YaST2 manually or remotely 4.3 Update selecting functional patches 4.4 Register the Service Pack as additional installation source 4.5 Update of individual packages 4.6 Update everything using "System Update" 5. Fresh installation using SP1 5.1 When is it needed? 5.2 Using the bootable SP CD 5.3 Setting up an installation server 5.3.1 Integrating the Service Pack into an installation server 5.4 Install-time support to create and install a bootable software RAID 6. Known problems 7. More info and feedback 1. Important general info ------------------------- These release notes are generic for all SLES 9 based products, so some parts may not apply to a particular architecture/product. In cases where this is not obvious the respective architectures are explicitly listed. 1.1 Purpose ----------- This SUSE Linux Enterprise Server Service Pack serves multiple purposes: o Contains enhancements to the SLES code base (see chapter 2). o Contains all maintenance fixes (see chapter 3), which were released since GA of SLES 9. o Provides an easy update (see chapter 4) of your system or individual packages to the latest Service Pack level. This is especially useful if you can not use online update mechanisms. o Provides improvements for an easy fresh install (see chapter 5) using the latest kernel, drivers and updates to the installer. o Include PTFs (special fixes for customers) which were folded back into the common code base making them maintained. o Contains useful additional information and documentation (see chapter 7). Through joint testing and maximum care we try hard not to break any ISV certification with a Service Pack, but we recommend that you check with your ISV about the certification status of your application. We also strive to minimize the need for IHV/HW recertification due to a clone concept for driver updates, introduced with SLES 9 Service Pack 1 (see chapter 2.2). 2. Enhancements --------------- 2.1 Installation / YaST2 ------------------------ o Updated sax2 monitor database o Added support in YaST partitioner for disks with size > 2 TB o Added 'netwait=N' option to wait N seconds after network setup o Added kernel parameter "ide=noraid" to prevent IDE drivers which are compiled into the kernel to initialize IDE RAID devices. You have to use this option to enable the modular LSI MegaIDE controller to work. o Added YaST Initial System Configuration (yast2-firstboot) The YaST firstboot utility allows to run the initial system configuration after installation. This is useful for OEM or preloaded or imaged versions of SLES 9 to roll back some steps like showing the EULA for confirmation again or allowing to set the timezone on the first boot. o Added command line support for samba-server BackendHandler o Added hooks for installing Novell Open Enterprise Server o Made sure that configs stored in LDAP will also work with Novell eDirectory o Fixed YOU module to handle username/password correctly in FTP mode o Fixed inst-server module to work with Service Pack CDs and SUSE Linux 9.1 o Provided docu for setting up the network installation server o Fixed uml module o Fixed cd-creator module o Fixed DDNS handling in dns-server module o In addition the following YaST modules have seen smaller bugfixes: yast2-bootloader yast2-ca-management yast2-country yast2-ipsec yast2-ldap-server yast2-nis-server yast2-storage o Fixed several problems with Asian font support o Improved support for Asian input methods (ami, scim) o Several bugfixes to RPM including relocations and database locking o Added installation support and translations for traditional Chinese o Added support to cache an installation source This helps to e.g. insert CDs only once during installation as all needed RPMs from this source will be copied into an installation source cache. o Added dialog to allow assigning PCI IDs to drivers This enables us to teach a driver about additional PCI IDs it is able to handle as well, because often an existing driver works well with new hardware released later but does not know it because the PCI IDs are unknown to the driver. This information will then be used during installation but also persist in the installed system. 2.2 Platforms / Hardware / Drivers --------------------------------- o Introduce concept of "cloned" drivers to minimize impact on HW certifications We have been discussing a lot how to best solve the dilemma of extending the hardware support with driver updates during the maintenance of a product while at the same time minimizing the effort for new or re-certifications of hardware. The best compromise we found was the following: - In case only very few HW certifications are affected default to update the driver in case it provides significant additional hardware support or value - In case many HW certifications would be affected keep the old driver untouched and add a "clone" -new using the latest version but only serving the new PCI IDs. This is achieved by removing the PCI IDs which exist in from the -new in order for them to be disjunct, which will automatically ensure the right driver gets loaded. Furthermore, we have introduced a new YaST dialog which will allow to "map" additional PCI IDs to a driver. This both allows teaching any driver about new PCI IDs, and forcing the use of the new driver for the old PCI IDs. o Support many new hardware components via driver and PCI ID updates: - cloned tg3-new with version 3.10 to support Broadcom 5721 and 5751 - cloned bcm-new with version 7.3.5 to support Broadcom 5721 - updated e1000-new with version 5.3.19 to support one new PCI ID - updated ixgb to version 1.0.82 to support 10 GB Ethernet - updated ipr to version 2.0.10.1 to support new RAID types - updated IBM ServeRAID driver ips to 7.10.18 to fix bugs - updated s2io driver to version 1.7.5.1 - updated qlogic to version 8.00.00 to use official release which is better and binary compatible to version 8.00.00b14 which was used in SLES 9 GA. - updated megaide to version 5.07r to support LSI controllers - updated megaraid_mbox to version 2.20.4.2/2.20.2.4 for new hardware support - updated cciss driver to version 2.6.4 to support SAS - updated gdth to version 3.04 for new hardware support - updated Emulex lpfc driver to version 2.10g for bugfixes - added driver jsm version 1.1 to support Digi Neo PCI serial cards - updated avm_fcdsl driver to support Fritz!Card DSL USB analog driver and Fritz!Card DSL USB 2.0 driver - updated avmfritzcapi to support new Eumex devices - included support for Intel i915 chipset (hwinfo, sax2, xf86) - enhanced driver update dialog to also support USB disks/sticks - fixed 4-port SATA support in the ICH6 driver - updated MPT fusion driver to version 3.01.14.23 - fixed aic7?xx driver probe info - added Altix system controller communication driver - cloned aic79xx-new with version 2.0.12 to support AIC7901 and 39320 - added Qlogic iSCSI support (qla4xxx) - added patches to Infiniband Gen1 code - backported dpt_i2o from 2.6.8 - updated aacraid driver to version 1.1.2-lk2 from 2.6.9 - added TIO support for SGI Altix o On IBM pSeries and IBM POWER i5/p5 systems, the bootloader installation to drives attached to Emulex adapters is now supported o On IBM JS20 blade systems, the bootloader installation to drives attached to Qlogic FibreChannel adapters is now supported o Included support for Novell nss filesystem (km_nss) o Fixed files > 2 GB in isofs o Merged new Lustre hooks o Updated XFS filesystem and tools to latest CVS snapshot o Updated CIFS to 1.22 o Updated OpenIPMI to 1.3.11 o Updated CKRM to E16 o Improved iSCSI and SAN/NAS support with patches from EMC, NetAPP and others o Backported several NFS bugfixes from upstream/mainline kernel o Backported epoll fixes from 2.6.9 o Integrated numerous other bugfixes from upstream/mainline kernel o Several backports from upstream/mainline kernel: - unmap_mapping_range() from 2.6.6 - generic_file_direct_write() and generic_file_buffered_write() from 2.6.9-rc4 - backport mapping_mapped() - export sync_page_range o Support official variable name INSTALL_MOD_DIR in addition to our MOD_DIR o Fixed hooks to enable CA o Added kernel support for POSIX message queue o Integrated patches to allow enabling ext3 reservation code o Integrated bugfix to SHPC PCI hotplug driver o Added CPU controller to CKRM 2.3 Standards ------------- o Updated openhpi to version 1.0.2 to comply with the SA Forum HPI A.1.1 spec o Added POSIX message queue support to glibc on x86 (CGL 2.0 spec Prio 1 req) POSIX messages queues where added to glibc after the development was stopped for librtkaio. glibc librt contains a full implementation for POSIX message queues on all architectures. librtkaio does not contain any support for POSIX message queues. Adding POSIX message queues to librtkaio is possible for x86 only. Other architectures are not possible due a change in the glibc syscall handling. 2.4 Availability ---------------- o Updated heartbeat to version 1.2.3 final o Updated drbd to version 0.7.5 + some fixes for 32/64bit interoperability o Updated multipath-tools to 0.3.6 o Updated device-mapper to 1.00.19 - multipath enhancements - added support for message passing ioctl o Added multipath fixes for barrier handling o With SP1 we now disabled by default the multipathing failover support in the QLogic driver as it caused many problems. We print a warning that it is depreciated and how one can still turn it on if needed using ql2xfailover=1 o Added patches for OES to EVMS o Provide code to enable recovery from PCI EEH errors o Added CPU hotplug support for S/390 o Fixed lvm2 to cope with minor device number larger than 255 o Fixed lvm2 to prevent hang on resizing a LV containing an active root fs 2.5 Serviceability ------------------ o Updated kdb to version 4.4 o Updated Linux kernel crash dump (lkcd) and lkcdutils o Added powernow K8 cpufreq support for CG stepping K8 o Updated iprutils to version 2.0.13 o Added SGI Altix hardware performance monitoring API o Exported some symbols needed by ES7000 Service Processor o Added tg3 ethtool stats o Updated OpenWBEM to version 3.1.0 o Updated CIM provider package novell-life to version 1.0.0 o Updated sysfsutils in udev package to version 1.2.0 o Added cpufreq support for SMP systems o Added modular kdb support for x86_64 o Added clustered APIC support for x86_64 2.6 Scalability --------------- o Improved RCU scalability o Fixed scalability problem in dnotify_parent o Assorted scalability improovement for large machines o Support SGI Altix and 512 CPUs with Linux kernel crash dump (LKCD) o Added CPUSET support for IPF o Added scalability enhancements for big IPF machines o Added PAGG support on IPF o Added support for systems with many IRQ resources 2.7 Performance --------------- o Default readahead to 512KB (instead of 128KB) o Updated schedutils to version 1.4.0 to add cpu list support o Updated Performance CoPilot to version 2.4.0 2.8 Security ------------ o Added amtu package in preparation for CC-EAL4 certification o Included all security fixes (see 3.1 below) 2.9 Applications and Tools -------------------------- o Updated ypbind to version 1.18 which adds a -ping option so that the system administrator can specify the ping interval of ypbind o Added linuxthreads patch to glibc to make old JVM 1.3.1 work o Backport all NPTL fixes to glibc to solve deadlock problems o Provided POSIX message queue support for x86 with glibc which can be used by apps now. See Chapter 2.3 for more details. o Made usage of MDNS configurable via /etc/host.conf (see manpage) o Changed the AIO glibc interface from librtkaio to librt For completeness we want to clarify that there are two different AIO interfaces: One separate from glibc, provided via the package "libaio", and one via "librt" from glibc. The libaio is really just a wrapper for the kernel AIO syscalls. These functions all start with io_*(). This is what most database vendors are using. This interface is not POSIX compatible, but is e.g. used by Oracle. It is contained in the package "libaio" on SLES 9. This has nothing to do with glibc and will not change for SP1. Then we have librt provided by glibc, which contains a set of aio_*() functions defined by POSIX. There are two different implementations of this library: One fully implemented in userland (librt from glibc) and one, which tries to use the Kernel AIO interface (called librtkaio). Both libraries install as "librt" and are binary compatible. The interface expects a file descriptor, so it should be usable with everything which could be opened by open(). The librt aio_* functionality is not really implementable in userland, this is the reason why the glibc librt does not work for most users. To solve this, there was the try to implement this functions with help of the Kernel AIO. But the kernel interface was not designed for this (kernel developers implemented it for the need of database vendors, not for POSIX nor glibc usage), as result, it does not work as expected, too, and needs much more CPU usage than the glibc librt. We know from bug reports from IBM, that both librt implementations (librt and librtkaio) do not work for them. Both implementations also don't pass 100% any test suite. Since librtkaio is worse by wasting a lot of CPU power, we will switch back to the standard glibc librt implementation with SP1. This in an internal implementation change of librt but is binary compatible to what we had in SLES 9 GA version. o Fixed blocking in gethostbyaddr with corrupted UDP packets o Added gcc_old on i386 to support linking of old apps o Fixed several Heimdal problems: - correctly handle RESPONSE_TOO_BIG response from Windows kdc - fixed crash with certain versions of winbind of Samba - fixed crash in telnet used with w2k kdc o Added large file support (LFS) to wget and rsh o Updated parted to version 1.6.15 - fixed two problems - added support for ATA over Ethernet - added support for partitioning device-mapper devices (for dmraid) o Added bugfixes to apache - mod_ssl returned invalid method on TLS upgraded connections - upgraded mod_auth_ldap and util_ldap to 2.0.53 level because of many bugfixes in these modules. They are still declared experimental by the authors. The update causes a minor binary incompatibility in the API exposed by the util_ldap module. Only third-party software built directly on top of util_ldap is affected by this incompatibility. There is *no* incompatible change in the functionality provided by the two modules or in their configuration. o Added fixes for iManager to Mozilla 1.6 o Backported bdb backend from stable OpenLDAP release o Added certificate revocation list (CRL) support for OpenLDAP o Increased limits in quota package to match the fact that the kernel can support more than 256 mounts o Integrated client side of ZLM 6.6 + fixes on fresh default install o Included menu entry to easily start ZMD/ZLM o Added novell-ldapext package containing LDAP extensions o Updated Samba to version 3.0.9 - Added eDirectory patch from Vince Brimhall - Added alias migration code from Volker Lendecke - more detailed info on changes/fixes comes with the samba-doc package in /usr/share/doc/packages/samba/WHATSNEW.txt - Included security fix from 3.0.10 2.10 New packages introduced with SP1 ------------------------------------- The following new packages have been introduced with Service Pack 1: o gcc_old o amtu o km_nss o novell-openwbem-authenticator o novell-ldapext (x86 only) Important Note: --------------- These packages are provided on the Service Pack 1 CDs but depending on the installation method you use these may not get automatically installed. Please use "rpm -U " to install any of these packages. 3. Maintenance fixes -------------------- 3.1 Bugfixes ------------ Service Pack 1 contains all bugfixes released via the maintenance Web since the GA version. See chapter 4.3 how to install these and chapter 7 where to find detailed documentation for each patch. 3.2 Security fixes ------------------ Service Pack 1 contains all security fixes released via the maintenance Web since the GA version. See chapter 4.3 how to install these and chapter 7 where to find detailed documentation for each patch. 4. Updating from SLES 9 to SP1 ------------------------------ Important Note: --------------- After completion of any form of update, look at the contents of the file /var/adm/rpmconfigcheck. This file contains a list of configuration files that could not be updated automatically. Usually this means the installed version was modified. These files must be checked and the configurations adjusted manually. 4.1 Using the CD autorun mechanism ---------------------------------- The most convenient way to update your system to SP1 is to use the CD autorun feature. Log into KDE and insert SLES 9 SP1 CD1. After some seconds a window will pop up, ask you for the root password (in case you are logged in as a regular user) and offer you to install the patches from this CD. You can either install all recommended updates (this is the default) or select individual updates you are interested in. Basically you will find yourself in the update method described in 4.3, so continue to read there for more details. Don't forget to reboot at the end. 4.2 Calling YaST2 manually or remotely -------------------------------------- The autorun of chapter 4.1 might not be an option if you have to update machines remotely or even without a CD-ROM drive. In this case you have to call YaST manually as the superuser root with the command "yast2". Then call the respective YaST module as mentioned in any chapter below. So a YaST2 reference like "Software -> Patch CD Update" means that you shall select "Software" on the left side and then the "Patch CD Update" icon on the right side. In case you want to use YaST remotely you can login via ssh with ssh -X root@ and then call "yast2". See also chapter 7 for references to our manuals and documentation, including sophisticated other methods to call and use yast, like via VNC or a serial line. 4.3 Update selecting functional patches --------------------------------------- The maintenance updates to SLES 9 are grouped into logical functional units, called "patches", which are (or will be) available via the maintenance Web, but also available on this Service Pack. This method is much more convenient and less error-prone than updating packages individually and also supports special hooks for PRE and POST scripts of a complete patch. This method can be used calling YaST -> Software -> Patch CD Update. Even though it was designed for CDs initially, it can also be used via many other sources like NFS or a local directory. There are 4 classes of patches. First there are patches to YaST itself. These are always selected and must be installed first. Second there are security patches, which should always be installed. Third there are recommended patches, which usually should be installed. Check the indications and contraindications for these. Last there are optional patches which are only needed in very special cases. You can view details on a patch by clicking the button 'Description'. If additional information or warnings are available for any packages selected for installation, YaST2 will show those in popup message windows during the installation process. Please do not ignore these messages, as they contain important information for your system. Usually the right patches for your system are automatically selected, so in most cases you can just accept the defaults. In case your were told by one of the popup screens that a reboot is necessary then reboot now. 4.4 Register the Service Pack as additional installation source --------------------------------------------------------------- In order for the YaST package manager to know about the updated packages residing on the Service Pack CD you have to register this CD as an additional installation source. You can do this by YaST -> Software -> Change Source of Installation and then "Add" and "CD" and then use the "Up" button to move SP1 to the top (highest priority). This will make sure that if a newer version of a package is found on the Service Pack CD then this version will be used. 4.5 Update of individual packages --------------------------------- You first have to register SP1 as an additional install source (see 4.4). Then you can use the "Install and Remove Software" module of YaST to update, install or remove individual packages. 4.6 Update everything using "System Update" ------------------------------------------- You first have to register SP1 as an additional install source (see 4.4). Then you can update all packages with the "System Update" module of YaST. 5. Fresh installation using SP1 ------------------------------- In case you are doing a fresh install then you can benefit from SP1 as well. Enhancements in the installer are listed in chapter 2.1 and additional platform/hardware support and driver updates in chapter 2.2. 5.1 When is it needed? ---------------------- If you have already successfully installed SLES 9 there is of course no need to do a fresh install. Just use any of the update mechanisms described in chapter 4 to get your system to SP1 level. In cases though where the SLES 9 GA version did not work for you, either because of missing hardware support or bugs in the installer you should try a fresh install with SP1 using any of the methods listed below. 5.2 Using the bootable SP CD ---------------------------- Insert the bootable Service Pack CD1 in your drive and boot your machine. The kernel will be loaded and the following dialog will appear: "Make sure that CD number 1 is in your drive." At this point insert the first product (!) CD, in our case CD1 of the SLES 9 GA ISO set. Hit "Ok" and the regular installation (with the new kernel, drivers and the new YaST) will run. Continue as usual with the installation. The benefit of this method is that you will directly install the newest version of every package in this mode, so no need to call any of the update methods listed above afterwards. If you have to install many machines we recommend to boot of the SP1 CD1 but use a network install server. Chapter 5.3 explains how to set up an installation server. 5.3 Setting up an installation server ------------------------------------- Here is a step-by-step guide to set up a SLES 9 install server. As example we are setting up an NFS install server, but the other methods like HTTP or FTP install server are very similar. o Call YaST -> Misc -> Installation Server o Select "Configure as NFS Source" and as Directory whatever you like, in our example we use "/install" o Hit then "Next" button o Leave the defaults for "Host Wild Card" and "Options" o Hit then "Next" button o With this an NFS Server serving "/install" will be set up automatically o The "Source Configuration" dialog will show up o In the "Sources to Configure" subwindow hit the "Configure" button o As "Source Name" enter what you like to name this install source. In our example we name it "sles9". This will create a subdirectory "sles9" under /install o Enable the checkbox "Announce as Installation Service with SLP" This will make this server broadcast himself as an installation server and any SUSE product will automatically find it in SLP install mode. o If you have CDs of SLES 9 and SP1 then skip the next step o In case you have ISO images instead of CDs then enable this checkbox and browse via "Select Directory" to the directory that contains all ISO images of all CDs. o Hit "Next" button o You will now be prompted to insert "CD1" o Insert "SLES 9 CD1" (which is the main product CD) and hit the "Continue" button. Now the data from CD1 will be copied to the local directory, in this example under /install/sles9 o Proceed the same way when prompted for CD2 ... CD6 o Press the "Finish" button o Now your installation server for SLES is ready. o The directory structure will look like this /install/sles9/ SUSE-CORE-Version-9/ CD1/ CD2/ CD3/ CD4/ CD5/ SUSE-SLES-Version-9/ CD1/ boot -> SUSE-SLES-Version-9/CD1/boot content -> SUSE-SLES-Version-9/CD1/content control.xml -> SUSE-SLES-Version-9/CD1/control.xml media.1 -> SUSE-SLES-Version-9/CD1/media.1 yast/ instorder order You may have noticed that the 6 CDs actually are 1 SLES CD, which is really defining the product settings, and 5 so-called CORE CDs, which contain the common code base for SUSE business products (the common code base avoids that ISVs or IHVs have to do multiple certifications). o Now you can easily install another machine via the network using the install server o Boot the machine you want to install from SLES 9 CD1 o On the initial dialog scroll one line down and chose "Installation" o In the "Boot Options" field enter "install=slp" (or change this with "F3" if this is available on your platform) o The machine will boot and then show you a selection of install options it has found via SLP In case this does not work out of the box then you are probably lacking a working DHCP and DNS server in your network. No problem. You can still use the following parameter in the Boot Options install=nfs:///install/sles9 to force the installation to use a certain install server. 5.3.1 Integrating the Service Pack into an installation server -------------------------------------------------------------- The YaST2 install server module needs some bugfixes to be able to read and integrate Service Pack CDs. Thus please make sure you have at least version 2.9.21-0.0.1 of yast2-instserver installed (you will find such a newer package on the Service Pack CD itself). Then to the following steps: o Call YaST -> Misc -> Installation Server -> Change -> Edit o Enable the checkbox "Prompt for additional CDs (Service Packs, Additional Package CDs, etc.)" o Hit "Next" button o It will say that contents already exists in this directory o Hit "Ok" button o It will prompt for CD1 o Now insert the "Service Pack CD1" and hit "Continue" o The contents of Service Pack CD1 will be copied to the local disk o Proceed the same way when prompted for CD2 5.4 Install-time support to create and install a bootable software RAID ----------------------------------------------------------------------- With SLES 9 SP1 for x86, AMD64 and EM64T it is possible to create and install a bootable software RAID (md) configuration. It is e.g. possible to use a RAID1 setup to mirror two drives and being able to boot from either drive (with the bootloader stored on both drives). Proceed as follows: During installation in the bootloader configuration: - Set the "Boot Loader Type" to "LILO" - Set the "Boot Loader Location" to /dev/md0 (select "Other" to add /dev/md0 manually) - Select to "Activate Boot Loader Partition" - Select to "Replace Code in MBR" Ignore the warning about the boot partition not being available. 6. Known problems ----------------- The following section describes known problems. x86-64 Systems with PCI-Express (PCI-E) Chipset With SLES9 and SLES9-SP1 PCI-E is not supported on the x86-64 architecture. As many of the newer EM64T systems are equipped with these chipsets we expect problems in this area. A workaround may be to disable 'mmconfig' by adding 'pci=nommconf' to the kernel command line. Please note, that the absence of PCI-E slots is no sufficient indication that the system isn't based on a PCI-E chipset. You'll have to check the 'lspci' output or refer to you system manual to be sure. Booting from SLES9 Service Pack 1 CD 1 on IBM iSeries systems To boot from SLES9 Service Pack 1 CD 1 on IBM iSeries systems, set the "IPL stream file" parameter in the Network Server Description to '/QOPT/SU90SP1.P01/ISERIES64'. The "SU90SP1.P01" part of the path is the disk label of CD 1. On IBM POWER systems, the YaST2 expert partitioner suggest to create a partition for /boot, which may lead to an unbootable system On IBM POWER systems, the YaST2 expert partitioner suggest to create a partition for /boot. This partition is not needed on POWER systems and should not be created, since it may confuse the boot loader installation process and lead to an unbootable system. Instead, a primary partition of type "PReP boot" (type 0x41) with no mount point and a recommended size of 16MB must be present. By default YaST2 will create such a partition. The bootloader installation process (the lilo script for POWER architectures) will take care of reducing the size and changing the type of this partition to meet the boot loader requirements according to the type of POWER system the installation runs on. Using the rescue system on systems with many devices The rescue system contains device nodes for a limited number of devices. If your system has more devices, please use the command udevstart on the command line. This will create the missing device nodes in /dev for all devices that are listed in /sys. Problems in one particular SLES 9 update method One of the three methods we offer to update an existing SLES 9 system might fail under the circumstances below. If you boot the installation system from Service Pack 1 and chose the option "Update system on hard disk" the installation of the new kernel may not be successfull. This was seen to fail on S/390 and zSeries. However there are two other possibilities to update an existing SLES 9 (System update and install Patch CD) which work reliably and should thus be used. 7. More info and feedback ------------------------- First you should always read the release notes for this service pack which can be found as file "Notes" on the toplevel of CD1, but even newer ones might be available next to the ISO images as file *.Notes. Please also read the READMEs on the CDs. You will find high-level information on all patches contained in this Service Pack under the directory docu. Just point your browser to file://docu/index.html You can of course always get the very detailed changelog information about a particular package from the RPMs themselves by doing rpm --changelog -qp .rpm where .rpm is the name of the rpm. The file "ChangeLog" in the toplevel of CD1 contains a chronological log of all the changes that were made for these updated packages. Please remember that you will find a lot more useful information in the directory docu of CD1 of the original SLES 9 GA (!) CDs. This includes pdf versions of the SLES 9 installation and administration manuals, which explain many other sophisticated methods to install and use SLES 9, for example using autoyast or VNC. Please visit http://www.suse.com for the latest product news from SUSE/Novell. As usual please report bugs via Bugzilla or your contact / feedback channel. Please use "Enterprise Server" as product and "9-SP1" as version for reporting bugs. Your SUSE Linux Enterprise Team