Release Notes #

For those, who need SELinux and Desktop functionality, we suggest to use SUSE Linux Enterprise Server 12 and the SUSE Linux Enterprise Workstation Extension.

As part of SUSE Linux Enterprise Desktop, LibreOffice (office suite), Evolution (email client), and OpenJDK are fully maintained and supported up to support level 2 calls.

Ext4 has some features that are under development and still experimental. Thus, using these features poses a significant risk to data. To clearly indicate such features, the Ext4 driver in SUSE Linux Enterprise 12 refuses to mount (or mount read-write) file systems with such features. To mount such file systems set the allow_unsupported module parameter (either when loading the module or via /sys/module/ext4/parameters/allow_unsupported ). However setting this option will render your kernel, and thus your system unsupported.

Features which are treated this way are: bigalloc, metadata checksumming, and journal checksumming.

Kernel 3.12 no longer provides the /proc/acpi/event virtual file.

This file has only been used by the acpid daemon in SLE 11. SLE 12 does not ship this package anymore.

[All architectures] CONFIG_COMPAT_BRK has been disabled to allow randomization of the start address of the userspace heap. This can break old binaries based on libc5. To revert to the old behavior, set the kernel.randomize_va_space sysctl to 2.

[x86_64 only] CONFIG_COMPAT_VDSO has been disabled to enforce randomization of the VDSO address of 32bit binaries on x86_64. This can break 32bit binaries using glibc older than 2.3.3. To revert to the old behavior, specify vdso=2 on the kernel command line.

Due to a missing backport, the SLE 11 SP3 kernel is displaying the microcode revision in /proc/cpuinfo as a decimal number.

The SLE 12 kernel changed the format to a hexadecimal number. Now it is compatible with the mainline kernel.

By default, the initrd file is now compressed with:

xz -0 --check=crc32 --memlimit-compress=50%

Previously, it was compressed with gzip.

If iTCO_wdt driver is enabled, the sensor driver shows that the service processor is reporting a constant temperature in spite of heavy CPU load or the CPU fan is stopped.

To disable the Intel watchdog functionality, we blacklist the iTCO_wdt driver for SLES, SLED, and SLEPOS installations.

Linux Kernel version 3.3 started supporting SD/SDIO version 3.0 that provides faster read/write speed and enhanced security.

A SDIO (Secure Digital Input Output) card is an extension of the SD specification to cover I/O functions.

Host devices that support SDIO can use the SD slot to support Wi-Fi, Bluetooth, Ethernet, IrDA, etc.

SDIO 3.0 cards and hosts add support for UHS-I bus speed mode, which can be as fast as 104MB/s.

Nvidia graphical chipsets can use two different drivers on SLED 12:

Installing the proprietary Nvidia driver will disable the nouveau driver.

While fixing issues in the operating system, you might need to install a Problem Temporary Fix (PTF) into a production system. Those packages provided by SUSE are signed with a special PTF key. In contrast to SUSE Linux Enterprise 11, this key is not imported by default on SLE 12 systems.

To manually import the key, use the following command:

rpm --import /usr/share/doc/packages/suse-build-key/suse_ptf_key.asc

After importing the key, you can install PTF packages on SLE 12.

libzypp-14.39.0 will per default check a downloaded rpm packages signature, if the corresponding repositories metadata are not gpg signed or the signature was not verified.

Customers using unsigned repositories may experience that zypper/yast now ask whether to accept a package whose signature can not be checked because the signing key is not known [4-Signatures public key is not available]:

(1/1) zypper-1.12.3-3.2.x86_64(myrepo) .....................<100%>[|]
zypper-1.12.3-3.2.x86_64.rpm:
    Header V3 DSA/SHA1 Signature, key ID f3ef3328: NOKEY
    V3 DSA/SHA1 Signature, key ID f3ef3328: NOKEY

zypper-1.12.3-3.2.x86_64(myrepo): Signature verification failed [4-Signatures public key is not available]
Abort, retry, ignore? [a/r/i] (a):

Ignoring the error will install the package despite the failed signature verification. It's not recommended to chose this option unless it's known, that the gpgkey (with key ID <as displayed>) which was used to sign the package is trusted (but it was not imported into the rpm database).

The message can be avoided by manually importing the missing trusted key into the rpm database (using 'rpmkeys --import' PUBKEY ).

Other signature verification errors than [4-Signatures public key is not available] should not be ignored.

Customers using only signed repositories should experience no difference.

The default of checking either the repo metadata signature or the rpm packages signatures can be tuned globally (in /etc/zypp.conf ) or per repo (editing the corresponding .repo file in /etc/zypp/repos.d ). Explicitly setting repo_gpgcheck or pkg_gpgcheck will overwrite the defaults.

[zypp.conf]
## Signature checking (repodata and rpm packages)
##
##   boolean    gpgcheck        (default: on)
##   boolean    repo_gpgcheck   (default: unset -> according to gpgcheck)
##   boolean    pkg_gpgcheck    (default: unset -> according to gpgcheck)
##
## If 'gpgcheck' is 'on' we will either check the signature of repo metadata
## (packages are secured via checksum in the metadata), or the signature of
## a rpm package to install if it's repo metadata are not signed or not
## checked.
##
## The default behavior can be altered by explicitly setting 'repo_gpgcheck' and/or
## 'pkg_gpgcheck' to perform those checks always (if 'on') or never (if 'off').
##
## Explicitly setting 'gpgcheck', 'repo_gpgcheck' 'pkg_gpgcheck' in a
## repositories .repo file will overwrite the defaults here.
##
##   DISABLING GPG CHECKS IS NOT RECOMMENDED.
##   Signing data enables the recipient to verify that no modifications
##   occurred after the data were signed. Accepting data with no, wrong
##   or unknown signature can lead to a corrupted system and in extreme
##   cases even to a system compromise.
##
# repo_gpgcheck = unset -> according to gpgcheck
# pkg_gpgcheck =  unset -> according to gpgcheck

vino (VNC server integrated in GNOME desktop environment) is using by default a encrypted connection (TLS), which might not be supported by all VNC clients on all platforms.

You can disable encryption on vino by running the following command as a regular user

gsettings set org.gnome.Vino require-encryption false

or by using the dconf-editor graphical tool, available from GNOME Control Center.

Known VNC clients with support for TLS encryption are "vinagre" (GNOME VNC client), virt-viewer (libvirt VM client, available for Windows from http://virt-manager.org/download/ (http://virt-manager.org/download/) ).

SUSE Linux Enterprise 12 supports the new on-disk format (v5) of the XFS file system. XFS file systems created by YaST will use this new format. The main advantages of this format are automatic checksumming of all XFS metadata, file type support, and support for a larger number of access control lists for a file.

Caveat: Pre SLE 12 kernels, xfsprogs before version 3.2.0, and the grub2 bootloader before the one released in SLE 12 do not understand the new file system format and thus refuse to work with it. This can be problematic if the file system should also be used from older or other distribution.

If you require interoperability of the XFS file system with older or other distributions, format the filesystem manually using the mkfs.xfs command. That will create a filesystem in the old format unless you use the "-m crc=1" option.

SLE12 has moved to Systemd, a new way of managing services. For more information, see the SUSE Linux Enterprise Admin Guide, Section The Systemd Daemon.

Because virtio numbers are not stable, by-path links for virtio disks are no longer available. These names are not persistent.

Btrfs is a copy-on-write (CoW) general purpose file system. Based on the CoW functionality, Btrfs provides snapshotting. Beyond that data and metadata checksums improve the reliability of the file system. Btrfs is highly scalable, but also supports online shrinking to adopt to real-life environments. On appropriate storage devices Btrfs also supports the TRIM command.

Support

With SUSE Linux Enterprise 12, Btrfs is the default file system for the operating system, xfs is the default for all other use cases. We also continue to support the Ext-family of file systems, Reiserfs and ocfs2. Each file system offers distinct advantages. Customers are advised to use the YaST partitioner (or AutoYaST) to build their systems: YaST will prepare the Btrfs file system for use with subvolumes and snapshots. Snapshots will be automatically enabled for the root file system using SUSE's snapper infrastructure. For more information about snapper, its integration into ZYpp and YaST, and the YaST snapper module, see the SUSE Linux Enterprise documentation.

Migration from "Ext" and Reiserfs File Systems to Btrfs

Migration from existing "Ext" file systems (Ext2, Ext3, ext4) and Reiserfs is supported "offline" and "in place", if the original filesystem has been created with a 4k block size (this is the case for most file systems on the x86-64 and System z architectures). Calling "btrfs-convert <device>" will convert the file system. This is an offline process, which needs at least 15% free space on the device, but is applied in place. Roll back: calling "btrfs-convert -r <device>" will roll back. Caveat: when rolling back, all data will be lost that has been added after the conversion into Btrfs; in other words: the roll back is complete, not partial.

RAID

Btrfs is supported on top of MD (multiple devices) and DM (device mapper) configurations. Use the YaST partitioner to achieve a proper setup. Multivolume Btrfs is supported in RAID0, RAID1, and RAID10 profiles in SUSE Linux Enterprise 12, higher RAID levels are not yet supported, but might be enabled with a future service pack.

SWAP files

Using swap files on top of Btrfs is not supported. In general, we are advising to use partitions for swapping, and not swap files on top of any file system for performance reasons.

Future Plans

Filesystem Maintenance, Online Check, and Repair Functionality

Check and repair functionality ("scrub") is available as part of the Btrfs command line tools. "Scrub" is aimed to verify data and metadata assuming the tree structures are fine. "Scrub" can (and should) be run periodically on a mounted file system: it runs as a background process during normal operation.

We recommend to apply regular "maintenance" to the Btrfs file system to optimize performance and disk usage. Specifically we recommend to "balance" and "defrag" the file system on a regular basis. Check the "btrfs-maintenance" package and see the SUSE Linux Enterprise documentation for more information.

Capacity Planning

If you are planning to use Btrfs with its snapshot capability, it is advisable to reserve twice as much disk space than the standard storage proposal. This is automatically done by the YaST2 partitioner for the root file system.

Backward compatibility - Hard Link Limitation

Previous products had a limitation on low hard link count per file in a directory. This has been fixed and is 65535 now. It requires a file system created with "-O extref", which is done by default. Caveat: Such a file system might not be mountable on older products.

Backward compatibility - Enhanced metadata

The file systems are by default created with a more space efficient format of metadata, the feature is called "skinny-metadata" for mkfs. Caveat: Such a file system will not be mountable on previous products.

Backward compatibility - metadata block size is 16k

The default metadata block size has changed to 16 kilobytes, reducing metadata fragmentation. Caveat: Such a file system will not be mountable on older products.

Other Limitations

At the moment, Btrfs is not supported as a seed device.

For More Information

For more information about Btrfs, see the SUSE Linux Enterprise documentation.

With SUSE Linux Enterprise 12, the default file system in new installations was changed from Ext3 to Btrfs for the root system partition. XFS is the default file system for the /home partition and other data partitions.

In the expert partitioner, the default file system is Btrfs. The user can change it if another file system is more suitable to accomplish the intended workload.

POWER Architecture

On POWER, the pagesize is 64K. Due to the assumption made by Btrfs regarding data blocksize (i.e. data blocksize being equal to the page size), a Btrfs installation on POWER will use a blocksize of 64K. This means that a Btrfs created on x86 will not be mountable and readable via Btrfs on POWER, and vice versa.

If data sharing in mixed architecture environments is a major concern, make sure to use XFS on POWER for data partitions.