These release notes cover the following areas:
This release of SUSE Linux Enterprise Server ships with Novell AppArmor. The AppArmor intrusion prevention framework builds a firewall around your applications by limiting the access to files, directories, and POSIX capabilities to the minimum required for normal operation. AppArmor protection can be enabled via the AppArmor control panel, located in YaST under Novell AppArmor. For detailed information about using Novell AppArmor, see the documentation in /usr/share/doc/packages/apparmor-docs.
The AppArmor profiles included with SUSE Linux have been developed with our best efforts to reproduce how most users use their software. The profiles provided work unmodified for many users, but some users find our profiles too restrictive for their environments.
If you discover that some of your applications do not function as you expected, you may need to use the AppArmor Update Profile Wizard in YaST (or use the aa-logprof(8) command line utility) to update your AppArmor profiles. Place all your profiles into learning mode with the following: aa-complain /etc/apparmor.d/*
When a program generates many complaints, the system's performance is degraded. To mitigate this, we recommend periodically running the Update Profile Wizard (or aa-logprof(8)) to update your profiles even if you choose to leave them in learning mode. This reduces the number of learning events logged to disk, which improves the performance of the system.
SuSEfirewall2 is enabled by default. That means that by default you cannot log in from remote systems. It also interferes with network browsing and multicast applications, such as SLP, Samba ("Network Neighborhood"), and some games. You can fine-tune the firewall settings using YaST.
Starting with SUSE Linux Enterprise 10, vsftpd can be configured independently or over the xinetd. The default is stand-alone. In previous versions, the default was xinetd.
To run it over xinetd, make sure that the service is enabled in the xinetd configuration (/etc/xinetd.d/vsftpd) and set the following line in /etc/vsftpd.conf:
listen=NO
If you cannot access https://update.novell.com directly but via a mandatory proxy server, proceed as explained in the Technical Information Document (TID) at http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3377050&sliceId=SAL_Public
By default, IPv6 support is not enabled for KDE. You can enable it using the /etc/sysconfig editor of YaST. This feature is disabled because IPv6 addresses are not properly supported by all Internet service providers and, as a consequence, would lead to error messages while browsing the Web and delays while displaying Web pages.
When running real-time applications on larger systems, lower maximum latencies can be achieved by employing the new disable_buffer_lru kernel command-line option. This disables the per-CPU LRU in the buffer cache, and may thus decrease overall filesystem performance.
Heartbeat 2 documentation in addition to that provided in the SLES 10 Administration Guide can be found at http://www.novell.com/documentation/sles10/hb2/data/hb2_config.html.
The "sapinit" RPM package has been updated to version 2.0.1. This version fixes a long standing problem of not being able to adequately setting various kernel parameters for an SAP system.
With this new version, it is now possible easily to set various important kernel parameters by usage of the configuration parameters found in the file "/etc/sysconfig/SAPinit", either using YaST or by directly editing this file, although this usually should not be necessary, while the various parameters are now also assigned reasonable default values taken from the relevant SAP notes.
The configuration file "/etc/sysctl.conf" as well as "/etc/fstab" is now automatically updated by the "/usr/sbin/SAPinit" script (which is run at each restart of the system, or manually from the command line by the user), to reflect the defined values used for the various kernel parameters as defined in "/etc/sysconfig/SAPinit".
For further informations, refer to "/etc/sysconfig/SAPinit", "/usr/share/doc/packages/sapinit/README", and "/usr/sbin/SAPinit".
Updates from SLES 9 to SLES 10 are supported starting from one of the following bases:
Update a system by starting the SLES 10 installation system and choosing Update instead of New installation. To verify whether one of the above variants is installed, you can use the tool SPident -vv. This shows the current level of your system.
SUSE Linux Enterprise 10 products offer various migration paths for updating the system to Service Pack 1. We recommend to pay extra attention if you plan to migrate your system that has an Add-on product or Kernel Module Packages (e.g 3rd party drivers from ATI/nVidia) installed.
Updating the system via PatchCD is only possible if no further installation source (e.g. SDK) was registered previously. In case you depend on this update path the workaround is to provide the PatchCD via FTP/NFS/HTTP as installation source.
Please find further information at http://developer.novell.com/wiki/index.php/Migration_to_SP1_with_Add-on_and_kmps
Under SLES 9, when extracting a directory from a tar archive that already existed as a symbolic link in the target directory, tar would overwrite the symlink with an actual directory. Under SLES 10, tar leaves the symlink and places the contents of the archive within it.
To enforce the old behavior please use the option --no-overwrite-dir when extracting an archive.
As of the Linux 2.6.10 kernel, serial devices on ia64 are named based on the order of ACPI and PCI enumeration. The first device in the ACPI namespace (if any) becomes /dev/ttyS0, the second becomes /dev/ttyS1, etc., and PCI devices are named sequentially starting after the ACPI devices.
On HP systems you must re-configure the EFI console then you can drop the console parameter from kernel boot command. As a workaround, you can try to use console=ttyS1... as a boot parameter instead of console=ttyS0... etc.
Find details in /usr/src/linux/Documentation/ia64/serial.txt, which is part of the kernel-source software package.
MIT Kerberos is now used instead of heimdal. Converting an existing Heimdal configuration automatically is not always possible. During a system update, backup copies of configuration files are created in /etc with the suffix .heimdal. YaST-generated configuration settings in /etc/krb5.conf are converted, but check whether the results match your expectations.
Before starting the update, you should decrypt an existing Heimdal database into a human-readable file with the command kadmin -l dump -d heimdal-db.txt. This way, you can create a list of available principals that you can restore one-by-one using kdc from MIT Kerberos. Find more information about setting up a KDC in the documentation in the "krb5-doc" package.
To configure a Kerberos client, start the YaST Kerberos Client module and enter your values for "Standard Domain", "Standard Realm", and "KDC Server Address".
Do not set the LD_ASSUME_KERNEL environment variable any longer. In the past, it was possible to use it to enforce LinuxThreads support, which was dropped. If you set LD_ASSUME_KERNEL to a kernel version lower than 2.6.5, everything breaks because ld.so looks for libraries in a version that does not exist anymore.
SUSE Linux Enterprise Server 9 set up the user environment with an unlimited stack size resource limit to work around restrictions in stack handling of multithreaded applications. With SUSE Linux Enterprise Server 10, this is no longer necessary and has been removed. The login environment now defaults to the kernel default stack size limit. To restore the old behavior, add "ulimit -Ss unlimited" to /etc/profile.local. If you want an automatic configuration of your resource limits suited to protect desktop systems, you may want to install the "ulimit" package.
During the upgrade from SLES9 to SLES10 also MySQL is upgraded from 4.x to 5.x. To complete this migration you have also to upgrade your data as described in the MySQL documentation.
Although most existing PHP 4 code should work without changes, there are a few backwards-incompatible changes. Find a list of these changes at:
http://www.zend.com/manual/migration5.incompatible.php
To use iSCSI disks during installation it is necessary to add the following parameter to the kernel parameter line:
withiscsi=1During installation, an additional screen appears that provides the possibility to attach iSCSI disks to the system and use them in the installation process.
SLES10 SP1 supports booting from an iSCSI server on i386, x86_64 and ppc, when an iSCSI enabled firmware is used.
On ppc, a single bootfile (zImage.initrd) instead of yaboot is used.
iSCSI devices cannot be used for Linux Software RAID. Using MD devices on top of iSCSI triggers a cyclic dependency that leads to a crash.
QLogic iSCSI Expansion Card for IBM BladeCenter provides both Ethernet and iSCSI functions. Some parts on the card are shared by both functions. The current qla3xxx and qla4xxx drivers support Ethernet and iSCSI function individually. They do not support using both functions at the same time. Using both Ethernet and iSCSI functions at the same time may hang the device and cause data lost and filesystem corruptions on iSCSI devices or network disruptions on Ethernet.
The qla3xxx (ethernet) and qla4xxx (iSCSI) drivers work good individually. However, when both drivers are active at the same time, one of the driver would hang or lost connection. The consiquences are network disruption and iSCSI target filesystem corruption.
Do not use the /dev/mapper device path for the root= kernel parameter. /dev/mapper is an internal name of the LVM2 system. Instead use the proper LVM notation /dev/VG/LV, as in /dev/system/root for the logical volume root on volume group system.
Installation from physical CD media to disks connected via QLogic Fibre Channel cards will fail after the first reboot. Please use DVD media or network installation sources instead.
On systems with an LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS where an integrated-mirroring volume was created and removed the installation on the disks may create the "system error code: -1007".
If a disk containing a GPT disk label is enlarged (e.g. by changing BIOS settings from RAID to non-RAID setup), this leads to a disk size that is larger than the area managed by the GPT data structures on disk. This fact may confuse YaST2 partitioner and might result into an error number -1007 during creation of disk partitions.
The partitioning tool parted is able to fix this problem of one calls parted on the command line for the affected disk (e.g. after booting into rescue mode from installation media). Simply start parted with the affacted disk name as parameter (e.g. "parted /dev/sda"). If parted encounters a disk with GPT size smaller than disk size it will ask the following question to the user:
Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 274566 blocks) or continue with the current setting?
Simply answer "yes" to this question and parted will adapt GPT data structures to new disk size. Afterwards installation using YaST2 should work without any problems.
When using certain ATI Mach64-based graphics solutions, X can be started, but fails to produce visible output.
To avoid problems during installation, it is recommended to use remote installations procedures (as described in Chapter 4 of 'docu/en/sles-admin.pdf').
This can be worked around by specifying a replacement driver to SaX2, e.g. with
sax2 -m 0=atiwcpiofrom runlevel 3 -- i.e. after installation.
If you want to use EDD information (/sys/firmware/edd/<device>) to identify your storage devices, change the installer default settings using an additional kernel parameter.
Requirements:
Procedure:
If you have installed and configured an iSCSI SAN and have created and configured EVMS Disks or Volumes on that iSCSI SAN, your EVMS volumes might not be visible or accessible. This problem is caused by EVMS starting before the iSCSI service. iSCSI must be started and running before any disks or volumes on the iSCSI SAN can be accessed.
To resolve this problem, enter either chkconfig evms on or chkconfig boot.evms on at the Linux server console of every server that is part of your iSCSI SAN. This ensures that EVMS and iSCSI start in the proper order each time your servers reboot.
If you plan to add additional storage devices to your system after the OS installation, we strongly recommend to use persistent device names for all storage devices during installation. The installer by default uses the kernel device names.
How to proceed:
During installation, enter the partitioner. For each partition, select "Edit" and go to the "FStab Options" dialog. Any mount option except "Device name" provide you persistent devicenames.
To switch an already installed system to using persistent device names, proceed as described above for all existing partitions. In addition, rerun the boot loader module in YaST to switch the bootloader to using the persistent device name also. Just start the module and select "Finish" to write the new proposed configuration to disk. This needs to be done before adding new storage devices.
For forther information please look at http://en.opensuse.org/Persistant_Storage_Device_Names.
With SUSE Linux Enterprise Server 10, we switched to "cryptoloop" as the default encryption module. SUSE Linux Enterprise Server 9 used twofish256 using loop_fish2 with 256 bits. Now we are using twofish256 using cryptoloop with 256 bits. The old twofish256 is available as twofishSL92.
When the way the root device is mounted (by UUID or by label) is changed in YaST, the boot loader configuration needs to be saved again to make the change effective for the boot loader.
The "mount by" setting displayed in the YaST2 boot loader module is the setting that will be in effect after saving the configuration.
To load unsupported kernel drivers automatically during boot, set the sysconfig variable LOAD_UNSUPPORTED_MODULES_AUTOMATICALLY in /etc/sysconfig/hardware/config to "yes".
Hotplug events are now completely handled by the udev daemon (udevd). We do not use the event multiplexer system in /etc/hotplug.d and /etc/dev.d anymore. Instead udevd calls all hotplug helper tools directly, according to its rules. udev rules and helper tools are provided by udev and various other packages.
Users of the XFS filesystem may see degraded performance when upgrading from SLES10 to SLES10-SP1. Typical symptoms will be slow file creation, removal and attribute manipulation. The degraded performance may be seen on LVM, device mapper or MD/RAID1 based filesystems and are a result of barriers being incorrectly enabled on these devices. Performance can be restored by applying the "nobarrier" mount option in /etc/fstab.
By default, calling su to become root does not set the PATH for root. Either call su - to start a login shell with the complete environment for root or set ALWAYS_SET_PATH to yes in /etc/default/su if you want to change the default behavior of su.
The shell script sux was removed. The functionality of forwarding xauth keys between users is now handled by the pam_xauth module and su.
By default, the kernel tries to keep threads on the local CPU (and local node on NUMA machines). Depending on the application, this may not deliver the best performance, especially applications with a large working set for each thread tend to perform better when being scheduled to different nodes because they can then use caches of multiple nodes.
With the following sysctl, this behavior is changed. By setting the sysctl variable kernel.affinity_load_balancing to 1, the scheduler no longer tries to keep thread local to a CPU.
Using this sysctl on the wrong application scenario may degrade system performance.
cardmgr no longer manages PC cards. Instead, as with Cardbus cards and other subsystems, a kernel module manages them. All necessary actions are executed by hotplug. The pcmcia start script has been removed and cardctl is replaced by pccardctl. For more information, see /usr/share/doc/packages/pcmciautils/README.SUSE.
Java packages are changed to follow the JPackage Standard (http://www.jpackage.org/). Read the documentation in /usr/share/doc/packages/jpackage-utils/ for information.
If you are not satisfied with locale system defaults, change the settings in ~/.i18n. Entries in ~/.i18n override system defaults from /etc/sysconfig/language. Use the same variable names but without the RC_ namespace prefixes, for example, use LANG instead of RC_LANG. For information about locales in general, see "Language and Country-Specific Settings" in the Reference Manual.
Many applications now rely on D-BUS for interprocess communication (IPC). Calling dbus-launch starts dbus-daemon. The systemwide /etc/X11/xinit/xinitrc uses dbus-launch to start the window manager.
If you have a local ~/.xinitrc file, you must change it accordingly. Otherwise applications might fail. Save your old ~/.xinitrc. Then copy the new template file into your home directory with:
cp /etc/skel/.xinitrc.template ~/.xinitrc
Finally, add your customizations from the saved .xinitrc.
For reasons of compatibility with LSB (Linux Standard Base), most configuration files and the init script were renamed from xntp to ntp. The new filenames are:
/etc/slp.reg.d/ntp.reg
/etc/init.d/ntp
/etc/logrotate.d/ntp
/usr/sbin/rcntp
/etc/sysconfig/ntp
Entering KDB code breakpoints on multiple CPUs in parallel can lead to deadlocks.
For reasons of compatibility with SLES 9, the mapped-base functionality is present in SLES 10. This functionality is used by 32-Bit applications that need a larger dynamic data space (such as database management systems).
With SLES 10, a similar functionality called flexmap is available. Because this is now the preferred way, mapped-base is deprecated and will vanish in future releases.
SLES 10 provides different I/O schedulers. The scheduler can be set per disk. The general default is CFQ. This default may be modified by the device driver or by the user with
echo keyword > /sys/block/dasda/queue/schedulerwhere keyword is one of the following:
noop anticipatory [deadline] cfqChanging the scheduler may seriously impact the system performance.
The default (by the kernel or the device driver) has been shown to be the best selection. There may be setups where this is not true.
The libhugetlbfs project shipped with SLES 10 is a preview of application provision with transparent access to system huge pages. While the library provides an application with easy access to huge pages when sufficient huge pages have been previously allocated on the system, additional development and testing is required to provide a stable transition to normal pages in a production environment.
The default mdadm.conf (and lvm.conf) do not work properly with multipathed devices. By default, both md and LVM2 scan physical devices only and ignore any symlinks or device-mapper devices.
This does not work for multipathed devices as there we have to omit all physical devices and scan devices in /dev/disk/by-name only (as these are the correct multipathed devices).
If there was a previous MD installation you'll have either modify mdadm.conf to handle the devices correctly (by using the line 'DEVICES /dev/disk/by-name/*') or clear the md superblock altogether.
A root partition on multipath is only supported if the /boot partition is on a separate, nonmultipathed partition. Otherwise no bootloader is written.
During boot, there may be drivers loaded that are not needed at runtime. To prevent this load at boot time, insert the following line into /etc/modprobe.conf.local:
install driver-name /bin/true Replace driver-name with the actual name of the module.WARNING
Be very careful. Inserting the wrong module name may lead to an unusable system.
With SLES 10 running on a HP MSA1000 SAN, whenever a disk fails or faults, MSA1000 SAN requires the failed or faulted disk to be removed from the disk array and re-created. By re-creating the disk, the disk array reshuffles the order of the disks in the SAN. The re-created disk will be pushed to the last device in the array.
An iSCSI shared device should never be mounted directly on the local machine. In an OCFS2 environment, doing so cause all hardware to hard hang.
Kernel Module Packages (KMP) can now update a system's PCI ID database to add support for new hardware components.
To update a system's PCI ID database a KMP installs a file containing updated PCI ID information in the /usr/share/pci.id.d/ directory. This file contains PCI ID information formatted using the standard pci.ids file syntax (see http://pciids.sourceforge.net/pci.ids)
To merge the updated PCI ID information into the system's PCI ID database a KMP's %post section of its spec file must include the following:
if [ -x /usr/bin/merge-pciids -a -x /usr/bin/perl ]; then /usr/bin/merge-pciids else echo "ERROR: merge-pciids or perl not found" fi
On the top level of the first CD, find a very detailed ChangeLog. Also read the READMEs on the CD.
If you encounter a bug, please report it through your support contact.
Your SUSE Linux Enterprise Team
Tue Oct 27 16:21:38 UTC 2009