Chapter 5. Issues to be aware of for jessie

There are some packages where Debian cannot promise to provide minimal backports for security issues. These are covered in the following subsections.

Note that the package debian-security-support, introduced in Jessie, helps to track security support status of installed packages.

In an attempt to harden the default setup, the openssh-server configuration will now default to "PermitRootLogin without-password". If you rely on password authentication for the root user, you may be affected by this change.

The openssh-server will attempt to detect such cases and increase the priority of its debconf prompt.

If you want to keep password authentication for the root user, you can also preseed this question by using:

# The "false" value is in fact correct despite being confusing.
$ echo 'openssh-server openssh-server/permit-root-login boolean false' | debconf-set-selections

If you are using Puppet, please be aware that Puppet 3.7 is not backwards compatible with Puppet 2.7. Among other things, the scoping rules have changed and many deprecated constructs have been removed. See the Puppet 3.x release notes for some of the changes, although be aware that there are further changes in 3.7.

Checking the log files of your current puppetmaster for deprecation warnings and resolving all of those warnings before proceeding with the upgrade will make it much easier to complete the upgrade. Alternatively, or additionally, testing the manifests with a tool like Puppet catalog test may also find potential issues prior to the upgrade.

When upgrading a Puppet managed system from Wheezy to Jessie, you must ensure that the corresponding puppetmaster runs at least Puppet version 3.7. If the master is running Wheezy's puppetmaster, the managed Jessie system will not be able to connect to it.

For more information on incompatability changes, please have a look at Telly upgrade issues and "The Angry Guide to Puppet 3".

The upgrade to Jessie includes an upgrade of PHP from 5.4 to 5.6. This may affect any local PHP scripts and you are advised to check those scripts before upgrading. Below are a selected subset of these issues:

For more information or the full list of potential issues, please have a look at upstream's list of backwards incompatible changes for PHP 5.5 and 5.6.

	Note
	This section only applies to systems which have installed an Apache HTTPD server and configured it manually.

There have been a number of changes to the configuration of the Apache HTTPD server in version 2.4. On the upstream side, the syntax has changed. Notably, the access control directives have changed considerably and will need manual migration to the new directives.

The mod_access_compat module is mentioned in the upstream upgrade guide as a possible alternative to immediate migration. However, the reports suggest it may not always work.

The managing of configuration files has also been changed in the Debian packaging. In particular, all configuration files and sites must now end with ".conf" to be parsed by default. This change also replaces the existing use of /etc/apache2/conf.d/.

	Note
	During the upgrade, you may also see warnings about configuration files placed in /etc/apache2/conf.d/, which are provided by packages from Debian. This warning is unavoidable but harmless as the affected packages will move their configuration once their upgrade completes (which will generally happen after the Apache HTTPD emits its warning).

For more information and the full list of changes, please refer to:

Jessie ships with systemd-sysv as default init system. This package is installed automatically on upgrades.

If you have a preference for another init such as sysvinit-core or upstart, it is recommended to set up APT pinning prior to the upgrade. This may also be required if you are upgrading LXC containers before the host. In this case, please refer to Section 5.8.1, “Upgrading LXC guests running on Wheezy hosts”.

As an example, to prevent systemd-sysv from being installed during the upgrade, you can create a file called /etc/apt/preferences.d/local-pin-init with the following contents:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1

	Caution
	Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system.

Please note that the upgrade may install packages containing "systemd" in their name even with APT pinning. These alone do not change your init system. To use systemd as your init system, the systemd-sysv package must be installed first.

If APT or aptitude has issues computing an upgrade path with the pin in place, you may be able to help it by manually installing both sysvinit-core and systemd-shim.

5.6.3. Locally modified init-scripts may need to be ported to systemd

	Note
	This section only applies to systems where Debian-provided init scripts have been modified locally.

If you have modified some of the init scripts provided by Debian, please be aware that these may now have been superseded by a systemd unit file or by systemd itself. If you have debsums installed, you can check for locally modified init scripts by using the following shell command.

debsums -c -e | grep ^/etc/init.d

Alternatively, the following can be used in the absence of debsums.

dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
  grep /etc/init.d | awk 'NF,OFS="  " {print $2, $1}' | \
  md5sum --quiet -c

If either command flags any files and their corresponding packages or the systemd now provides an systemd unit file for that service, the systemd unit file will take precedence to your locally modified init script. Depending on the nature of the change, there are different way to perform the migration.

If necessary, it is possible to override the systemd unit file to have it start the sysvinit script. For more information on systemd unit files, please have a look at the following resources.

• How Do I Convert A SysV Init Script Into A systemd Service File?

• systemd.special — Special systemd units

• My Service Can't Get Realtime! (also contains a very short mention on invoking init scripts from unit files)

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab

5.6.7. systemd: issues SIGKILL too early [fixed in 8.1]

	Note
	This issue was fixed in the 8.1 Jessie point release.

A regression was reported in systemd after the Jessie release. The bug occurs during shutdown or reboot, where systemd does not give any reasonable delay before issuing SIGKILL to processes. This can lead to data loss in processes that have not saved all data at the time of the reboot (e.g. running databases).

This issue is tracked in the Debian bug #784720

	Note
	This section is only for people who compile their own kernel. If you use the kernels compiled by Debian, you can disregard this section.

The following kernel configuration options are now either required or recommended for Jessie (in addition to existing ones from previous releases):

# Required for udev
CONFIG_DEVTMPFS=y
# Required for *some* systemd services
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Required by "bluez" (GNOME)
CONFIG_BT=y
# Required for cups + systemd.
CONFIG_PPDEV=y

The systemd services which require CONFIG_DEVPTS_MULTIPLE_INSTANCES=y will typically contain at least one of the following directives:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes

If you do not use systemd, or can assert that none of the systemd services will use the above directives, the config option might not be required for your particular system.

For more information about the requirements, please refer to the section called "REQUIREMENTS" in the README file for the package systemd.

	Note
	This section only applies to systems that have LXC containers and hosts. Normal end user systems usually do not have these.

The upgrade from Wheezy to Jessie will migrate your system to the systemd init system by default (see Section 5.6, “Upgrading installs the new default init system for Jessie”).

When upgrading an LXC container or an LXC virtual machine, this will have different consequences depending on whether the host system has already been upgraded to Jessie or not.

lxc.autodev = 1
lxc.kmsg = 0

	Note
	This section is only for people who have set up LUKS encrypted disks themselves using the whirlpool hash. The debian-installer has never supported creating such disks.

If you have manually set up an encrypted disk with LUKS whirlpool, you will need to migrate it manually to a stronger hash. You can check if your disk is using whirlpool by using the following command:

# /sbin/cryptsetup luksDump <disk-device> | grep -i whirlpool

For more information on migrating, please see item "8.3 Gcrypt 1.6.x and later break Whirlpool" of the cryptsetup FAQ.

	Caution
	If you have such a disk, cryptsetup will refuse to decrypt it by default. If your rootdisk or other system disks (e.g. /usr) are encrypted with whirlpool, you should migrate them prior to the first reboot after upgrading cryptsetup.

The GNOME 3.14 desktop in Jessie no longer has fallback support for machines without basic 3D graphics. To run properly, it needs either a recent enough PC (any PC built in the last 10 years should have the required SSE2 support) or, for architectures other than i386 and amd64, a 3D-accelerated graphics adapter with EGL drivers.

Unlike other OpenGL drivers, the AMD FGLRX driver for Radeon adapters does not support the EGL interface. As such, several GNOME applications, including the core of the GNOME desktop, will not start at all when this driver is in use.

It is recommended to use the free radeon driver, which is the default in jessie, instead.

The default keyboard shortcuts in the GNOME desktop have changed in order to match more closely those of some other operating systems.

Shortcut settings previously modified by the user will be preserved upon upgrade. These settings can still be configured from the GNOME control center, accessible from the top right menu by clicking on the "settings" icon.

The upgrade of the base-passwd package will reset the shell of some system users to the "nologin" shell. This includes the following users:

If your local setup requires that any of these users have a shell, you should say no to migrating, or migrate and then change the shell of the corresponding users. Notable examples include local backups done via the "backup" user with "ssh-key" authentication.

	Caution
	The migration will happen automatically if your debconf question priority is "high" or above.

If you know you want to keep the current shell of a given user, you can preseed the questions by using the following:

echo 'base-passwd base-passwd/system/username/shell/current-shell-mangled/_usr_sbin_nologin boolean false' | debconf-set-selections

Where username is the name of the user in question and current-shell-mangled is the mangled name of the shell. The mangling is done by replacing all characters other than alphanumerics, dashes, and underscores with underscores. E.g. /bin/bash becomes _bin_bash.

The Kontact Personal Information Management system has received a major upgrade. The new version makes much greater use of metadata indexing and each user's data must be migrated into these new indices.

E-mail, calendar events, and addressbook contacts are automatically migrated when the user logs in and the relevant component is started. Some advanced settings such as e-mail filters and custom templates require manual intervention. Further details and troubleshooting suggestions are collected on the Debian Wiki.

	Note
	This issue is currently reported as fixed in Jessie. Should you still be able to reproduce it, then please follow up to Debian Bug#766462. Note that you may have to unarchive the issue first (please refer to the Debian BTS control server documentation on how to unarchive bugs).

If you have multiple desktop environments installed, you may experience that none of the "virtual consoles" show a login prompt.

This issue seems to occur when plymouth, systemd, and GNOME are all installed. This issue is reported as Debian Bug#766462.

It has been reported that removing the "splash" argument from the kernel command-line may work around the issue. Please see /etc/default/grub and remember to run update-grub after updating the file.

There is a compatibility issue in grub-pc with older graphics cards (e.g. the "ATI Rage 128 Pro Ultra TR") that can cause it to show a blank screen during boot. The display may issue a "VGA signal out of range" message (or something similar).

A simple work around is to set GRUB_TERMINAL=console in /etc/default/grub.

The crontab program is now more strict and may refuse to save a changed cron file if it is invalid. If you experience issues with crontab -e, please review your crontab for existing mistakes.

From version 5.18 (and 5.20, which is included in Jessie), Perl will exit with a fatal error if it encounters unreadable module paths in @INC. The previous behavior was to skip such entries. It is recommended to check the contents of @INC in your environment for directories which are not world-readable, and take appropriate action.

You can see the default @INC for Perl by running perl -V.

If a client requests that a file should be "opened for execution", Samba4 will require the executable bit to be set on the file in addition to the regular read permissions. This also causes "netlogon" scripts to be silently ignored if they lack this executable bit.

	Note
	This section only applies to people that have manually changed their /etc/initramfs-tools/initramfs.conf to not use busybox.

If you have both busybox and cryptsetup installed plus configured initramfs to not use busybox, then it may render your system unbootable.

Please check the value of your BUSYBOX setting in /etc/initramfs-tools/initramfs.conf if you have both of these packages installed. At this time, known work arounds are uninstalling busybox or setting BUSYBOX=y in /etc/initramfs-tools/initramfs.conf.

	Warning
	If you had to make any changes, please remember to run update-initramfs -u to update your initramfs. Otherwise, you may still end up with a broken boot.

Please see Debian Bug#783297 for more information.

	Note
	This section only applies to people that have installed the squid webproxy.

The configuration of squid has changed in an incompatible way. Notably some of the squid "helpers" have changed their name. If your configuration relies on old features no longer present or on the old names for the helpers, your squid service may fail to start after the upgrade.

Please see the upstream release notes for more information. These are: