Chapitre 5. Problèmes à connaître pour Jessie

Table des matières

5.1. Limitations de la prise en charge de sécurité
5.1.1. État de sécurité des navigateurs web
5.1.2. Manque de prise en charge de sécurité pour l'écosystème autour de libv8 et Node.js
5.1.3. Limitation précoce de la prise en charge de sécurité
5.2. Le serveur OpenSSH est réglé par défaut sur « PermitRootLogin without-password »
5.3. Compatibilité de Puppet 2.7 et 3.7
5.4. La mise à niveau vers PHP 5.6 produit des modifications de son comportement
5.5. Modifications incompatible dans Apache HTTPD 2.4
5.6. La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie
5.6.1. Gestion plus stricte des échecs de montage lors du démarrage sous systemd
5.6.2. Les scripts de démarrage obsolètes devraient être purgés
5.6.3. Les scripts de démarrage modifiés localement peuvent nécessiter d'être portés vers systemd
5.6.4. Plymouth nécessaire aux invites de commandes au démarrage pour les démarrages sous systemd
5.6.5. Interaction entre logind et acpid
5.6.6. Fonctionnalités de crypttab non prises en charge sous systemd (p. ex. "keyscript=...")
5.7. Option de noyau requises pour Jessie
5.8. Considérations au sujet de la mise à niveau des hôtes et conteneurs LXC
5.8.1. Mettre à niveau des invités LXC tournant sur des hôtes sous Wheezy
5.8.2. Mettre à niveau des invités LXC tournant sur des hôtes sous Jessie
5.8.3. Informations supplémentaires
5.9. Migration manuelle de disques chiffrés avec LUKS whirlpool (configurations non standard)
5.10. Le bureau GNOME nécessite des graphismes 3D de base
5.11. Le bureau GNOME ne fonctionne pas avec le pilote AMD propriétaire FGLRX
5.12. Modifications des raccourcis clavier par défaut de GNOME
5.13. Modifications dans l'interpréteur de commande par défaut pour les utilisateurs système fournie par base-passwd.
5.14. Migration vers le nouveau logiciel KDE de courriel, calendrier et contacts (Kontact)
5.15. Consoles virtuelles (« getty ») manquantes avec plusieurs environnements de bureau
5.16. "Signal VGA hors de portée" / écran noir lors du démarrage avec grup-pc
5.17. Validation plus stricte des fichiers cron dans crontab
5.18. Modification dans la gestion des chemins de modules illisibles perl.
5.19. Considérations au sujet de la mise à niveau des grappes Ganeti
5.19.1. Problème lors de la mise à niveau de grappes Ganeti avec les instances basées sur DRBD.
5.19.2. Notes générales à propos de la mise à niveau des grappes Ganeti
5.20. Nouveaux prérequis pour l'exécution de fichier dans Samba4
5.21. Cryptsetup peut casser le démarrage avec BUSYBOX=n

Parfois, des changements ont des effets de bord que nous ne pouvons pas raisonnablement éviter sans nous exposer à des bogues à un autre endroit. Cette section documente les problèmes que nous connaissons. Veuillez également lire l'errata, la documentation des paquets concernés, les rapports de bogues et les autres sources d'informations mentionnées en Section 6.1, « Lectures pour aller plus loin ».

5.1. Limitations de la prise en charge de sécurité

Il y a certains paquets pour lesquels Debian ne peut pas garantir de rétroportages de base pour les problèmes de sécurité. Ceux-ci sont couverts dans les sous-sections suivantes.

Veuillez noter que le paquet debian-security-support, introduit dans Jessie, aide à suivre le statut de la prise en charge du suivi de sécurité des paquets installés.

5.1.1. État de sécurité des navigateurs web

Debian 8 inclut plusieurs moteurs de navigateur web qui sont affectés par un flot continu de vulnérabilités de sécurité. Ce taux élevé de vulnérabilités ainsi que le manque partiel de prise en charge amont sous la forme de branches maintenues à long terme rendent difficiles les corrections de sécurité rétroportées. De plus, les interdépendances des bibliothèques rendent impossible la mise à niveau vers une nouvelle version. Par conséquent les navigateurs basés sur les moteurs webkit, qtwebkit et khtml sont inclus dans Jessie mais ne sont pas couverts par une prise en charge complète de la sécurité. Ces navigateurs ne devraient pas être utilisés sur des sites web non fiables.

Pour un usage général de navigation web, nous recommandons Iceweasel et Chromium.

Chromium − bien qu'il soit construit sur Webkit − est un paquet sans dépendance, qui sera maintenu à jour en reconstruisant les versions actuelles de Chromium pour stable. Iceweasel et Icedove seront également maintenus à jour en reconstruisant les versions ESR actuelles pour stable.

5.1.2. Manque de prise en charge de sécurité pour l'écosystème autour de libv8 et Node.js

La plate-forme Node.js est construite sur libv8-3.14 qui souffre d'un grand nombre de problèmes de sécurité, mais le projet et l'équipe de sécurité manquent de volontaires suffisamment intéressés et souhaitant investir beaucoup de temps pour corriger ces problèmes.

Malheureusement, cela signifie que libv8-3.14, nodejs et l'écosystème de paquets node-* associé ne devraient pas être actuellement utilisés avec du contenu non sûr, par exemple des données non validées depuis Internet.

De plus, ces paquets ne recevront aucune mise à jour de sécurité lors de la durée de vie de la distribution Jessie.

5.1.3. Limitation précoce de la prise en charge de sécurité

La prise en charge en amont de la sécurité pour la version 1.19 de mediawiki prendra fin pendant le cycle de vie de Jessie. Le paquet mediawiki est inclus dans Jessie afin de satisfaire les dépendances d'autres paquets.

La prise en charge de la sécurité de mediawiki prendra fin en même temps que celle de Wheezy en avril 2016.

5.2. Le serveur OpenSSH est réglé par défaut sur « PermitRootLogin without-password »

Afin de renforcer la sécurité de l'installation par défaut, la configuration de openssh-server est maintenant réglée avec « PermitRootLogin without-password » par défaut. Si vous utilisez l'authentification par mot de passe pour l'utilisateur root, vous pourriez être affecté par ce changement.

openssh-server essaiera de détecter de tels cas et augmentera la priorité de son invite debconf.

Si vous souhaitez conserver l'authentification par mot de passe pour l'utilisateur root, vous pouvez également pré-répondre à cette question en utilisant :

$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections

5.3. Compatibilité de Puppet 2.7 et 3.7

Si vous utilisez Puppet, soyez conscient que Puppet 3.7 n'est pas rétrocompatible avec Puppet 2.7. Entre autres choses, les règles de portée (« scoping ») ont changé et beaucoup de constructions dépréciées ont été supprimées. Veuillez consulter les notes de publication de Puppet 3.x pour quelques-unes des modifications, mais gardez à l'esprit qu'il y en a davantage dans la version 3.7.

Vérifier les fichiers de journaux de votre puppetmaster actuel à la recherche d'avertissements de dépréciation et résoudre tous ces avertissements avant de procéder à la mise à niveau simplifiera grandement les choses. Autrement ou en complément, le test des manifestes avec un outil comme le test de catalogue de Puppet pourrait également trouver des problèmes potentiels avant la mise à niveau.

Lors de la mise à niveau de Wheezy vers Jessie d'un système géré par Puppet, assurez-vous que le puppetmaster correspondant utilise au moins la version 3.7. Si le maître fonctionne avec le puppetmaster de Wheezy, le système géré sous Jessie ne sera pas capable de s'y connecter.

Pour davantage d'informations sur les changements d'incompatibilité, veuillez consulter les problèmes de mise à niveau Telly et « The Angry Guide to Puppet 3 ».

5.4. La mise à niveau vers PHP 5.6 produit des modifications de son comportement

La mise à niveau vers Jessie comprend une mise à niveau de PHP de la version 5.4 vers la version 5.6. Cela pourrait affecter tous les scripts PHP locaux et il vous est recommandé de vérifier ces scripts avant de mettre à niveau. Un sous-ensemble de ces problèmes est présenté ci-dessous :

  • Pour prévenir les attaques de type « homme du milieu » sur les transferts chiffrés, les flux clients vérifient dorénavant les certificats des pairs par défaut.

    En résultat de ces changements, un code existant utilisant des enveloppes de flux ssl:// ou tls:// (par exemple file_get_contents(), fsockopen() et stream_socket_client()) pourraient ne plus réussir à se connecter sans désactiver manuellement la vérification des pairs grâce au réglage « verify_peer » du contexte de flux.

    Pour davantage d'informations sur ces problèmes particuliers, veuillez lire ce document

  • PHP modifie la gestion de l'insensibilité à la casse dans de nombreux cas :

    • Toute gestion de l'insensibilité à la casse pour les noms de classes, fonctions et constantes se fait d'après les règles ASCII. Les réglages de la locale actuelle sont ignorés.

    • Les mots-clés « self », « parent » et « static » sont dorénavant toujours insensibles à la casse.

    • La fonction json_decode() n'accepte plus les variantes non minuscules des valeurs booléennes.

  • Les fonctions de GUID logo (comme php_logo_guid()) ont été supprimées.

  • Il n'est plus possible d'écraser les clés dans les tableaux scalaires statiques. Veuillez consulter le bogue 66015 de PHP pour un exemple et plus d'informations sur ce problème.

  • Les fonctions mcrypt_encrypt(), mcrypt_decrypt() et mcrypt_{MODE}() n'acceptent plus les clés ou vecteurs d'initialisation de taille incorrecte. De plus, un vecteur d'initialisation est maintenant nécessaire si l'algorithme de bloc utilisé le nécessite.

  • Pour des raisons d'ordre légal, l'implémentation de JSON fournie avec PHP a été remplacée par la version fournie par le module PECL « jsonc ». Tout code faisant des suppositions au sujet de détails d'implémentation de l'interpréteur JSON de PHP devrait être revu.

Pour plus d'informations ou la liste complète des problèmes potentiels, veuillez consulter la liste amont des modifications qui ne sont pas rétrocompatibles pour PHP pour les versions 5.5 et 5.6.

5.5. Modifications incompatible dans Apache HTTPD 2.4

[Note]Note

Cette section ne s'applique qu'aux systèmes sur lesquels un serveur HTTPD Apache est installé et configuré manuellement.

De nombreux changements ont eu lieu dans la configuration du serveur HTTPD Apache dans sa version 2.4. Du côté amont, la syntaxe a changé. Notamment, les directives de contrôle d'accès ont considérablement changé et nécessiteront une migration manuelle vers les nouvelles directives.

Le module mod_access_compat est mentionné dans le guide amont de mise à niveau comme une alternative possible à la migration immédiate. Cependant, les rapports laissent penser que cela ne fonctionne pas toujours.

La gestion des fichiers de configuration a également changé dans le paquet Debian. En particulier, tous les fichiers de configuration et les sites doivent maintenant se terminer par « .conf » pour être interprétés par défaut. Cette modification remplace également l'usage actuel de /etc/apache2/conf.d/.

[Note]Note

Lors de la mise à niveau, vous pourriez également voir des avertissements concernant les fichiers de configuration placés dans /etc/apache2/conf.d/ qui sont fournis par des paquets de Debian. Cet avertissement est inévitable mais sans danger car les paquets affectés déplaceront leur configuration quand leur mise à niveau sera terminée (ce qui se produit généralement après l'envoi de l'avertissement par le serveur HTTP Apache).

Pour davantage d'informations et la liste complète des modifications, veuillez vous référer à :

  • Upgrading to 2.4 from 2.2 fourni par Apache pour la partie amont.

  • Le fichier /usr/share/doc/apache2/NEWS.Debian.gz fourni par le paquet apache2.

5.6. La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie

Jessie est livrée avec systemd-sysv en tant que système d'initialisation par défaut. Ce paquet est automatiquement installé lors d’une mise à niveau.

Si vous avez une préférence pour un autre système comme sysvinit-core ou upstart, il est recommandé de régler le pinning d'APT avant la mise à niveau. Cela peut également être nécessaire si vous mettez à niveau des conteneurs LXC avant leur hôte. Dans ce cas, veuillez vous référer à Section 5.8.1, « Mettre à niveau des invités LXC tournant sur des hôtes sous Wheezy ».

Par exemple, pour empêcher systemd-sysv d'être installé lors de la mise à niveau, vous pouvez créer un fichier nommé /etc/apt/preferences.d/local-pin-init ayant le contenu suivant :

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

Soyez averti que certains paquets pourraient avoir un comportement affecté ou pourraient ne pas avoir toutes leurs fonctionnalités sous un autre système d'initialisation que celui par défaut.

Veuillez noter que la mise à niveau pourrait installer des paquets contenant « systemd » dans leur nom malgré le pinning APT. Ces paquets seuls ne peuvent pas changer votre système d'initialisation. Pour utiliser systemd comme système d'initialisation, le paquet systemd-sysv doit d'abord être installé.

Si APT ou aptitude a des difficultés à calculer un chemin de mise à niveau avec le pinning mis en place, vous pouvez l'aider en installant manuellement sysvinit-core et systemd-shim.

5.6.1. Gestion plus stricte des échecs de montage lors du démarrage sous systemd

Le nouveau système d'initialisation par défaut, systemd-sysv, gère les échecs de montages « auto » de façon plus stricte que ne le fait sysvinit. S'il échoue à monter un montage « auto » (sans l'option « nofail »), systemd lancera un shell d'urgence au lieu de poursuivre le démarrage.

Nous recommandons que tous les points de montage démontables ou optionnels (« optional ») listés dans /etc/fstab, tels que les disques réseau non critiques, aient l'option « noauto » ou « nofail ».

5.6.2. Les scripts de démarrage obsolètes devraient être purgés

Si vous faites une mise à niveau depuis une distribution précédente, votre système peut contenir des scripts de démarrage fournis par des paquets (désormais) supprimés. Ces scripts pourraient avoir des métadonnées imprécises ou sans dépendance, ce qui peut mener à des cycles de dépendance dans votre configuration de démarrage.

Afin d'éviter cela, nous vous recommandons de regarder la liste des paquets se trouvant dans l'état « rc » (« supprimés, mais ayant encore des fichiers de configuration ») et de purger au moins ceux ayant des scripts de démarrage.

Veuillez consulter Section 4.8.1, « Purger les paquets supprimés » pour de plus amples détails sur la façon de trouver et purger les paquets supprimés.

5.6.3. Les scripts de démarrage modifiés localement peuvent nécessiter d'être portés vers systemd

[Note]Note

Cette section ne concerne que les systèmes dans lesquels les scripts de démarrage fournis par Debian ont été modifiés localement.

Si vous avez modifié certains de vos scripts de démarrage fournis par Debian, sachez que ceux-ci pourraient avoir été remplacés par un fichier unit de systemd ou par systemd lui-même. Si debsums est installé, vous pouvez vérifier les scripts de démarrage modifiés localement en utilisant la commande suivante :

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

Autrement, la commande suivante peut-être utilisée en l'absence de debsums.

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

Si l'une de ces commandes désigne des fichiers et leurs paquets correspondants ou que systemd fournit désormais un fichier unit pour ce service, le fichier unit de systemd aura la priorité sur votre script de démarrage modifié localement. En fonction de la nature de la modification, il existe différentes manières d'effectuer la migration.

Au besoin, il est possible de passer outre le fichier unit de systemd pour le faire lancer le script de démarrage. Pour davantage d'informations sur les fichiers unit systemd, veuillez consulter les ressources suivantes :

5.6.4. Plymouth nécessaire aux invites de commandes au démarrage pour les démarrages sous systemd

Si votre démarrage est interactif (par exemple, nécessite un mot de passe pour un disque chiffré), veuillez vous assurer d'avoir installé et configuré plymouth. Veuillez consulter /usr/share/doc/plymouth/README.Debian pour des informations concernant l'installation de plymouth.

Sans plymouth, il se pourrait que votre invite de commande au démarrage disparaisse. Les rapports suggèrent que l'invite de cryptsetup accepte toujours les entrées bien qu'elle ne soit pas visible. Si vous rencontriez ce problème, taper le bon mot de passe devrait toujours fonctionner.

5.6.5. Interaction entre logind et acpid

Les événements ACPI peuvent être gérés par logind ou acpid. Dans le cas où les deux services sont configurés pour gérer les événements de différentes manières, des résultats non désirés peuvent se produire.

Nous recommandons de migrer tout réglage n'étant pas par défaut vers logind et de désinstaller acpid. Autrement, il est également possible de configurer logind pour ignorer les événements ACPI en ajoutant :

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

au fichier /etc/systemd/logind.conf. Veuillez noter que cela pourrait modifier le comportement des environnements de bureau se basant sur logind.

5.6.6. Fonctionnalités de crypttab non prises en charge sous systemd (p. ex. "keyscript=...")

Certaines options de cryptsetup ne sont malheureusement pas prises en charge lorsque le système d'initialisation est systemd. Ces fonctionnalités sont :

  • precheck

  • check

  • checkargs

  • noearly

  • loud

  • keyscript

Si votre système dépend d'une des ces options pour démarrer, vous devrez utiliser sysvinit (sysvinit-core) comme système de démarrage. Veuillez consulter Section 5.6, « La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie » pour savoir comment éviter un système de démarrage en particulier.

Vous pouvez vérifier si une de ces options est utilisée dans votre système en lançant la commande suivante :

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

Si rien ne s'affiche en sortie de cette commande, votre système n'utilise aucune des options concernées.

5.7. Option de noyau requises pour Jessie

[Note]Note

Cette section est dédiée aux personnes qui compilent leur propre noyau. Si vous utilisez les noyaux compilés par Debian, vous pouvez ignorer cette section.

Les options suivantes de configuration du noyau sont maintenant requises ou recommandées pour Jessie (en plus des options déjà présentes dans les distributions antérieures) :

# Requis par udev
CONFIG_DEVTMPFS=y
# Requis par *certains* services systemd
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Requis par "bluez" (GNOME)
CONFIG_BT=y
# Requis par cups + systemd.
CONFIG_PPDEV=y

Les services systemd nécessitant CONFIG_DEVPTS_MULTIPLE_INSTANCES=y contiennent généralement au moins une des directives suivantes :

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

Si vous n'utilisez pas systemd ou savez qu'aucun des services de systemd n'utilise les directives mentionnées, l'option de configuration peut ne pas être nécessaire à votre système.

Pour plus d'informations au sujet des prérequis, veuillez vous référer à la section "REQUIREMENTS" du fichier README dans le paquet systemd.

5.8. Considérations au sujet de la mise à niveau des hôtes et conteneurs LXC

[Note]Note

Cette section ne concerne que les systèmes ayant des conteneurs et hôtes LXC. Les utilisateurs normaux n'en ont normalement pas.

La mise à niveau de Wheezy vers Jessie fera migrer votre système vers le système de démarrage systemd par défaut (voir Section 5.6, « La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie »).

Lors de la migration d'un conteneur ou une machine virtuelle LXC, celle-ci aura différentes conséquences selon que le système hôte a déjà été mis à niveau vers Jessie ou non.

5.8.1. Mettre à niveau des invités LXC tournant sur des hôtes sous Wheezy

Si vous mettez à niveau un conteneur invité LXC tournant sur un système hôte sous Wheezy, il vous faudra empêcher l'invité de migrer automatiquement vers systemd. Cela est faisable grâce au pinning, décrit dans Section 5.6, « La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie ».

Ceci est nécessaire car l'hôte sous Wheezy n'a pas les fonctionnalités permettant de faire démarrer un systèmes utilisant systemd.

Vous devriez être capable de passer à systemd dans un invité LXC après avoir mis à niveau le système hôte vers Jessie. Veuillez lire le paragraphe suivant pour savoir ce qui doit être adapté sur les hôtes sous Jessie.

5.8.2. Mettre à niveau des invités LXC tournant sur des hôtes sous Jessie

Afin de pouvoir démarrer des invités LXC avec systemd, vous devez adapter la configuration de votre conteneur LXC. La configuration du conteneur se trouve généralement dans /var/lib/lxc/NOM_DU_CONTENEUR/config. Vous devez ajouter les réglages suivants à la configuration :

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. Informations supplémentaires

Vous pouvez trouver de plus amples informations sur LXC dans Debian dans le wiki Debian.

5.9. Migration manuelle de disques chiffrés avec LUKS whirlpool (configurations non standard)

[Note]Note

Cette section est dédiée aux personnes ayant installé elles-mêmes des disques chiffrés avec LUKS en utilisant le hachage whirlpool. L'installateur Debian n'a jamais géré la création de tels disques.

Si vous avez configuré manuellement un disque chiffré avec LUKS whirlpool, vous aurez besoin de le migrer manuellement vers un hachage plus fort. Vous pouvez vérifier si votre disque utilise whirlpool avec la commande suivante :

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

Pour davantage d'information sur la migration, veuillez consulter l'élément « 8.3 Gcrypt 1.6.x and later break Whirlpool » de la FAQ cryptsetup.

[Attention]Attention

Si vous avez un tel disque, cryptsetup refusera de le déchiffrer par défaut. Si votre disque racine ou d'autres disques système (par exemple /usr) sont chiffrés avec whirlpool, vous devriez les migrer avant le premier redémarrage suivant la mise à niveau de cryptsetup.

5.10. Le bureau GNOME nécessite des graphismes 3D de base

Le bureau GNOME 3.14 de Jessie ne propose plus de prise en charge de secours pour les machines ne disposant pas de graphismes 3D de base. Pour fonctionner correctement, il nécessite soit un PC suffisamment récent (toute machine fabriquée ces 10 dernières années devrait avoir la prise en charge requise de SSE2) ou, pour les architectures autres qu'i386 et amd64, un adaptateur graphique 3D accéléré avec les pilotes EGL.

5.11. Le bureau GNOME ne fonctionne pas avec le pilote AMD propriétaire FGLRX

Contrairement aux autres pilotes OpenGL, le pilote AMD FGLRX pour les adaptateurs Radeon ne prend pas en charge l'interface EGL. Ainsi, plusieurs applications GNOME, dont le cœur du bureau GNOME, ne démarreront pas du tout quand ce driver sera utilisé.

Il est recommandé d'utiliser à la place le pilote libre radeon, qui est le pilote par défaut de Jessie.

5.12. Modifications des raccourcis clavier par défaut de GNOME

Les raccourcis clavier par défaut du bureau GNOME ont changé afin de mieux correspondre à ceux utilisés sur d'autres systèmes d'exploitation.

Les réglages de raccourcis clavier précédemment modifiés par l'utilisateur seront préservés lors de la mise à niveau. Ces réglages peuvent encore être configurés depuis le centre de contrôle de GNOME, accessible dans le menu en haut à droite en cliquant sur l'icône « configuration ».

5.13. Modifications dans l'interpréteur de commande par défaut pour les utilisateurs système fournie par base-passwd.

La mise à niveau du paquet base-passwd réinitialisera l'invite de commande de certains utilisateurs système à l'interpréteur de commande « nologin ». Sont concernés les utilisateurs suivants :

  • daemon

  • bin

  • sys

  • games

  • man

  • lp

  • mail

  • news

  • uucp

  • proxy

  • www-data

  • backup

  • list

  • irc

  • gnats

  • nobody

Si votre installation locale nécessite qu'un de ces utilisateurs ait un interpréteur de commande, vous devriez refuser la migration ou bien migrer puis changer l'interpréteur des utilisateurs correspondants. Des exemples notables incluent les sauvegardes locales faites avec l'utilisateur « backup » avec une authentification par « ssh-key ».

[Attention]Attention

La migration se fera automatiquement si la priorité de votre question debconf est « high » ou plus.

Si vous savez que vous souhaitez conserver l'interpréteur de commande d'un utilisateur donné, vous pouvez pré-répondre à cette question en utilisant :

echo 'base-passwd base-passwd/system/nom_utilisateur/shell/shell-actuel-modifié/_usr_sbin_nologin boolean false' | debconf-set-selections

nom_utilisateur est le nom de l'utilisateur en question et shell_actuel_modifié est le nom tronqué de l'interpréteur. La modification se fait en remplaçant tous les caractères qui ne sont pas alphanumériques, tiret ou underscore, par des underscores. Par exemple, /bin/bash devient _bin_bash.

5.14. Migration vers le nouveau logiciel KDE de courriel, calendrier et contacts (Kontact)

Le système Kontact de gestion d'informations personnelles a subi une mise à niveau majeure. La nouvelle version utilise beaucoup plus l'indexation des métadonnées et les données de chaque utilisateur doivent être migrées vers ce nouvel index.

Courriels, événements du calendrier et contacts du carnet d'adresse sont automatiquement migrés lorsque l'utilisateur se connecte et que le composant associé est lancé. Certains réglages avancés tels que les filtres de courriel et les templates personnalisés nécessitent une intervention manuelle. De plus amples détails et des suggestions de solutions aux problèmes sont réunies dans le wiki Debian.

5.15. Consoles virtuelles (« getty ») manquantes avec plusieurs environnements de bureau

Si vous avez installé plusieurs environnements de bureau, il se peut qu'aucune des « consoles virtuelles » ne montre une invite de connexion.

Ce problème semble se produire lorsque plymouth, systemd et GNOME sont tous installés. Ce problème est rapporté en tant que Bogue Debian nº 766462.

Il a été signalé que supprimer l'argument « splash » de la ligne de commande du noyau pourrait permettre de contourner le problème. Veuillez modifier /etc/default/grub et ne pas oublier de lancer update-grub après modification du fichier.

5.16. "Signal VGA hors de portée" / écran noir lors du démarrage avec grup-pc

Il existe un problème de compatibilité dans grup-pc avec des cartes graphiques anciennes (par exemple la "ATI Rage 128 Pro Ultra TR") qui peut provoquer un écran noir lors du démarrage. L'écran peut afficher un message "Signal VGA hors de portée" (ou quelque chose de similaire).

Un contournement simple est de régler GRUB_TERMINAL=console dans /etc/default/grub.

5.17. Validation plus stricte des fichiers cron dans crontab

Le programme crontab est maintenant plus strict et pourrait refuser de sauvegarder un fichier cron si celui-ci est invalide. Si vous rencontrez des problèmes avec crontab -e, veuillez verifiez votre crontab.

5.18. Modification dans la gestion des chemins de modules illisibles perl.

À partir de la version 5.18 (et 5.20, celle incluse dans Jessie), Perl s'arrêtera avec une erreur fatale lorsqu'il rencontrera des chemins de modules illisibles dans @INC. Le comportement précédent était d'ignorer de telles entrées. Il est recommandé de vérifier le contenu de @INC de votre environnement à la recherche de répertoires n'étant pas lisibles par tout le monde et de prendre les mesures appropriées.

Vous pouvez voir le @INC par défaut de Perl en exécutant la commande perl -V.

5.19. Considérations au sujet de la mise à niveau des grappes Ganeti

5.19.1. Problème lors de la mise à niveau de grappes Ganeti avec les instances basées sur DRBD.

La version de ganeti (2.12.0-3) livrée avec Jessie ne prend pas en charge les migrations depuis les installations exécutant la version 2.5 et les versions précédentes (dont celle de Wheezy) dans les cas où ce sont des instances ayant des disques DRBD. Ce problème devrait être corrigé dans une mise à jour de la distribution et il est déconseillé de mettre à niveau les grappes Ganeti affectées en attendant. Vous pouvez trouvez de plus amples informations à propos de ce problème dans le rapport de bogue nº 783186.

5.19.2. Notes générales à propos de la mise à niveau des grappes Ganeti

La procédure de mise à niveau recommandée d'une grappe Ganeti de la version de Wheezy (2.5.2-1) vers celle de Jessie (2.12.0-3) est d'arrêter toutes les instances puis de mettre à niveau et redémarrer tous les nœuds en même temps. Cela garantira que toutes les instances utilisent la version de Jessie de l'hyperviseur et que tous les nœuds utilisent les même versions de Ganeti et DRBD.

Veuillez noter que faire fonctionner une grappe mélangeant des nœuds en versions 2.5 et 2.12 n'est pas pris en charge. Veuillez également noter qu'en fonction de l'hyperviseur, les migrations à chaud pourraient ne ne pas fonctionner entre les versions d'hyperviseur de Wheezy et Jessie.

5.20. Nouveaux prérequis pour l'exécution de fichier dans Samba4

Si un client demande qu'un fichier soit « ouvert pour exécution », Samba4 demandera que le bit d'exécution soit activé sur le fichier en plus des permissions de lecture habituelles. Cela a aussi pour effet que les scripts « netlogon » sont ignorés en silence s'ils n'ont pas ce bit activé.

5.21. Cryptsetup peut casser le démarrage avec BUSYBOX=n

[Note]Note

Cette section ne s'applique qu'aux personnes ayant manuellement modifié leur fichier /etc/initramfr-tools/initramfs.conf pour ne pas utiliser busybox.

Si vous avez à la fois busybox et cryptsetup installés et configuré initramfs pour ne pas utiliser busybox, alors votre système pourrait ne pas démarrer.

Veuillez vérifier la valeur de votre réglage de BUSYBOX dans /etc/initramfs-tools/initramfs.conf si ces deux paquets sont installés. Pour le moment, les contournements connus sont de désinstaller busybox ou d'utiliser le réglage BUSYBOX=y dans /etc/initramfs-tools/initramfs.conf.

[Avertissement]Avertissement

Si vous avez dû faire une modification, n'oubliez pas de lancer update-initramfs -u pour mettre à jour votre initramfs. Autrement, vous pourriez malgré tout finir avec un démarrage cassé.

Veuillez consulter le bogue nº 783297 pour de plus amples informations.