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.

For legacy reasons, /etc/ssl/certs may only contain CA certificates in PEM format. Because this format does not transport usage information /etc/ssl/certs may only contain CA certificates that are intended for server authentication.

OpenSSL understands a different format that transports the usage information, therefore OpenSSL internally uses a different location, which contains certificates of all kinds of usage type ( /var/lib/ca-certificates/openssl ). If you put a certificate in plain PEM format in /etc/pki/trust/anchors/ and call update-ca-certificates it should end up in both /var/lib/ca-certificates/pem (i.e., /etc/ssl/certs ) and /var/lib/ca-certificates/openssl [as well as other locations like the cert bundle or the Java keyring].

The unaccelerated fbdev driver is used as a fallback in UEFI secure boot mode with the AST KMS driver, EFI VGA, and other currently unknown framebuffer drivers.

Our kernel is compiled with support for Linux Filesystem Capabilities. Since SLE 12, it is enabled by default.

Disable it by adding file_caps=0 as a kernel boot option.

dmesg was providing all kinds of system internal information to any users. It includes kernel addresses, crashes of services, and similar things that could be used by local attackers.

The use of dmesg is now restricted to the root user.

Use udisks2 to restrict access to removable media. For more information, see the Security and Hardening Guide.

By default, you use the YaST Network Settings dialog (yast2 network) to activate or deactivate NetworkManager. For manual configuration without YaST, proceed as follows.

In the past, the NETWORKMANAGER sysconfig variable in /etc/sysconfig/network/config was used to activate and deactivate NetworkManager. This variable is gone and replaced with a proper systemd network.service alias link, which points to the currently enabled network service.

The alias link will be created by the

systemctl enable NetworkManager.service

or

systemctl enable wicked.service

commands.

Further, the /etc/init.d/network script has been removed in favor of native systemd services. The rcnetwork shortcut executes action of network.service.

The command

systemctl -p Id show network.service

allows to query the currently selected network service, the

systemctl status network.service

shows the user readable details about currently used network service.

Procedure to enable NetworkManager manually:

1) First, stop the running network (wicked) service to get a clean state (configuration may differ):

systemctl     is-active network.service && systemctl     stop      network.service

2) Then, stop the wicked-daemon services as well:

systemctl     is-active wickedd.service && \
systemctl     stop      wickedd.service

3) Disable wicked, enable NetworkManager.service (creates alias link):

systemctl disable wicked.service
systemctl --force enable NetworkManager.service

4) Start the NetworkManager service via the alias link:

systemctl     start     network.service

or directly:

systemctl start NetworkManager.service

Procedure to disable NetworkManager and switch to wicked.service manually:

1) Stop the running NetworkManager.service:

systemctl     is-active NetworkManager.service && \
systemctl --kill-who=all kill NetworkManager.service

Note: The normal NetworkManager.service stop action stops NetworkManager, but leaves processes such as dhcp clients running to not break network connectivity when it is restarted on update or there is a remote fs mounted while shutdown. The --kill-who=all kill action ensures to stop them too as they conflict with the wicked service using a different implementation.

2) Disable NetworkManager, enable wicked.service (creates alias link):

systemctl disable NetworkManager.service
systemctl --force enable wicked.service

3) Start the new network.service, which now is wicked.service:

systemctl start wicked.service

or via the alias link:

systemctl start network.service

The wickedd daemon service are started automatically via dependencies.

To query the currently selected service, use:

systemctl -p Id show     network.service

It returns "Id=NetworkManager.service" if the NetworkManager service is enabled, otherwise "Id=wicked.service" and wicked is acting as the network service.

Depending on your XDMCP client, the following configurations are supported:

For a nested Xserver, Xephyr is the preferred choice over Xnest.

Within the wicked family of tools, the nanny daemon is a policy engine that is responsible for asynchronous or unsolicited scenarios such as hotplugging devices.

The nanny framework is not enabled by default in SUSE Linux Enterprise 12. To enable it either specify "nanny=1" in the installer (linuxrc) as a boot parameter or activate after the installation it in /etc/wicked/common.xml:

<config>
...
<use-nanny>true</use-nanny>
<config>

After a change at runtime, restart the network:

systemctl restart wickedd.service
wicked ifup all

For more information, see the SUSE Linux Enterprise Admin Guide, Section The wicked Network Configuration.

With NETCONFIG_DNS_RESOLVER_OPTIONS in /etc/sysconfig/network/config you can specify arbitrary options that netconfig will write to /etc/resolv.conf.

For more information about available options, see the resolv.conf man page.

Pixz (pronounced 'pixie') is a parallel, indexing version of XZ. It takes advantage of running LZMA compression of multiple parts of an input file on multiple cores simultaneously. The resulting file contains an index of the data blocks, which enables random access to the data

Linux Cloud Video Transcode is an Intel GEN based hardware solution to support high quality and performance video transcoding on a server. With enabling VEBOX on Haswell for some video pre and post process features like DN/ADI SUSE Linux Enterprise features improved transcode quality.

Some partners need to still run 32-bit applications in a 32-bit runtime environment on SUSE Linux Enterprise 12.

SUSE does not support 32-bit development on SLE 12. 32-bit runtime environments are available with SLE 12. If there is a need to develop 32-bit applications to run in the SLE 12 32-bit runtime environment then use the SLE 11 32-bit development tools to create these applications.

Due to limitations in the legacy x86_64 BIOS implementations, booting from devices larger than 2 TiB is technically not possible using legacy partition tables (DOS MBR).

Since SUSE Linux Enterprise Server 11 SP1 we support installation and boot using uEFI on the x86_64 architecture and certified hardware.

For the last 20 years, hard disk with 512 byte sectors have been in use. Since some years there are drives providing a 4KiB sector size internally, but showing 512 byte sectors externally as a backward compatibility layer (512 byte emulation / 512e). These devices are fully supported in SUSE Linux Enterprise.

The installation on native 4KiB sector drives (4kn) in x86_64 systems with UEFI is supported, as is the use of 4 KiB sector drives as non-boot disks. Legacy (non UEFI) installations on x86_64 systems are not supported on 4KiB drives for technical reasons.

The YaST GTK front-end has been removed from the product.

Libreoffice language tools, which is a collection of grammar and common errors for a number of languages, is no longer provided as part of SLED. Those tools are still available from Libreoffice.org Web site, as extensions. Spellcheckers for a number of languages are still part of SLED.

scsirastools was designed to work with now obsolete SCSI parallel enclosure. This package is not more available in SLE12.

Adobe has discontinued support for Adobe Reader 9 on Linux (http://www.adobe.com/support/products/enterprise/eol/eol_matrix.html#863) and is no longer providing security updates.

In order to not loose functionality Adobe Acrobat Reader will be kept on released products, but to avoid security issues with accessing PDFs online the PDF viewer browser plugin will however be removed. In order to maintain functionality the latest Firefox ESR releases include a feature to display PDF documents, which receives maintenance and security updates via Firefox updates.

As announced on SLE 11, LPRng is discontinued with SLE 12.

The following unsupported kernel modules have been dropped from the kernel-extra package:

The kernel-extra package is only available for SUSE Linux Enterprise Desktop and SLE Workstation Extension, but not for SUSE Linux Enterprise Server.

The following X11 drivers are no longer provided in SLE 12:

Starting with SLE 12, the Mono platform and Mono based programs are no longer supported.

These are the replacement applications:

YaST ( yast2-network ) no longer offers modem configuration dialogs.

It is still possible to configure modems manually.

YaST ( yast2-network ) no longer supports configuring ISDN devices. If needed, NetworkManager supports such devices.

YaST ( yast2-network ) no longer supports configuring DSL devices. If needed, NetworkManager supports such devices (e.g., DSL cable modems).

SLE 12 features the Qt4 toolkit. Qt4 will be supported at least until the release of SLE 12 Service Pack 3. Hence it is recommended to migrate applications to Qt5 and start new projects using Qt5.

Starting with SLE 12, /etc/SuSE-release file is deprecated. It should not be used to identify a SUSE Linux Enterprise system. This file will be removed in a future Service Pack or release.

The file /etc/os-release now is decisive. This file is a cross-distribution standard to identify a Linux system. For more information about the syntax, see the os-release man page ( man os-release ).