From Fedora Project Wiki
No edit summary
(correction orthographique)
 
(7 intermediate revisions by the same user not shown)
Line 8: Line 8:
== Notes de version ==
== Notes de version ==
Lisez  [[F27_release_announcement|l’annonce de libération de Fedora 27]] et les [http://docs.fedoraproject.org/en-US/Fedora/27/html/Release_Notes/ notes de version de Fedora 27] pour des informations spécifiques sur les changements apportés par Fedora 27 et pour d’autres informations plus générales.  
Lisez  [[F27_release_announcement|l’annonce de libération de Fedora 27]] et les [http://docs.fedoraproject.org/en-US/Fedora/27/html/Release_Notes/ notes de version de Fedora 27] pour des informations spécifiques sur les changements apportés par Fedora 27 et pour d’autres informations plus générales.  
{{Common_bugs_header_shared}}
{{Common_bugs_header_shared/fr}}
 
 


== Problèmes d’installation ==
== Problèmes d’installation ==


{{Common bugs issue|anaconda-lang-switch|Switching keyboard layout with key combo does not work in Wayland|1389959}}
{{Common bugs issue|anaconda-lang-switch|Le changement d’arrangement de clavier à partir des combinaisons de touches ne fonctionne pas dans  Wayland|1389959}}


Si vous utilisez le média Live d’installation de Workstation et que vous configurez plusieurs langues dans l’installateur, il ne vous sera pas possible de passer de l’une à l’autre à partir des raccourcis systèmes standard (typiquement {{key press|Win|Espace}} or {{key press|Alt|Maj}}). Cependant, vous pouvez toujours cliquer sur l’indicateur de langues dans l’installateur pour cela.  
Si vous utilisez le média Live d’installation de Workstation et que vous configurez plusieurs langues dans l’installateur, il ne vous sera pas possible de passer de l’une à l’autre à partir des raccourcis systèmes standard (typiquement {{key press|Win|Espace}} or {{key press|Alt|Maj}}). Cependant, vous pouvez toujours cliquer sur l’indicateur de langues dans l’installateur pour cela.  


Cela n'affecte pas les autres médias d’installation (KDE Live, DVD et les images netinst).
Cela n’affecte pas les autres médias d’installation (KDE Live, DVD et les images netinst).


{{Common bugs issue|grub-macos-broken|macOS can't be booted from grub|893179}}
{{Common bugs issue|grub-macos-broken|On ne peut démarrer macOS depuis Grub|893179}}


If you install Fedora into dual-boot on a Mac, Fedora creates several "Mac OS X" menu items in grub that should allow you to boot macOS. These menu items are broken, however, and macOS can't be booted from grub. The available workaround is to press and hold down the {{key press|Opt}} (or right {{key press|Alt}}) key when starting the computer, which will show you UEFI boot menu, and select macOS partition to boot from there.
Si vous installez Fedora en double démarrage sur Mac, Fedora crée plusieurs entrées de menu « Mac OS X » dans Grub qui devraient vous permettre de démarrer macOS. Ces entrées de menu sont néanmoins cassées et macOS ne peut être démarré depuis Grub. La solution de contournement est de presser et de maintenir la touche {{key press|Opt}} (ou la touche {{key press|Alt}} de droite) au démarrage de l’ordinateur, pour entrer dans le menu de démarrage UEFI et sélectionner la partition macOS de laquelle démarrer.


{{Common bugs issue|anaconda-iscsi-live|Installer on several live images does not offer iSCSI support|1395620|1429132}}
{{Common bugs issue|anaconda-iscsi-live|L’installateur de plusieurs images live ne prend pas en charge iSCSI|1395620|1429132}}


On many or all Fedora Live images, the installer will not offer iSCSI functionality (the "Add iSCSI target" button will not appear in the 'Specialized & Network Disks' screen). You can avoid the problem by running {{command|sudo dnf install storaged-iscsi}} from a console before starting the install process, or by installing from a dedicated installer image rather than a live image.
Sur de nombreuses, ou sur toutes les images live de Fedora, l’installateur n’offre pas la fonctionnalité iSCSI (le bouton « AJouter une cible iSCSI » n’apparaît pas dans l’écran « Disques spécialisés et réseaux »). Vous pouvez éviter le problème en exécutant  {{command|sudo dnf install storaged-iscsi}} depuis une console avant de lancer le processus d’installation, ou en installant à partir d’une image dédiée plutôt qu’à partir d’une image live.  


== Upgrade issues ==
== Problèmes de mise à jour ==


{{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}}
{{Common bugs issue|wayland-frozen-login-after-upgrade|Écran gris gelé au moment de la connexion après  mise à jour|1394755}}


This happens if you have [https://extensions.gnome.org/extension/690/easyscreencast/ EasyScreenCast] extension installed and upgrade. It is the same bug as [[#screen-recording-freezes-gnome]], see that entry for a full description and a workaround.
Ceci se produit si vous avez installé l’extension [https://extensions.gnome.org/extension/690/easyscreencast/ EasyScreenCast] et mis à jour. C’est la même anomalie que [[#screen-recording-freezes-gnome]], reportez-vous à cette entrée pour une description complète et une solution de contournement.


{{Common bugs issue|every-second-login-fails|Every second login attempt fails in certain configurations}}
{{Common bugs issue|every-second-login-fails|Chaque deuxième tentative de connexion échoue dans certaines configurations}}
- [https://bugzilla.gnome.org/show_bug.cgi?id=775463 GNOME bug #775463]
– [https://bugzilla.gnome.org/show_bug.cgi?id=775463 GNOME bug #775463]


If you've upgraded your system, you might see an issue where every second login attempt fails and you're returned to the login screen (without any visible error). This happens for Wayland sessions, but not for X11 sessions. Currently it seems this might be caused by <code>org.gnome.SessionManager auto-save-session</code> gsettings value being <code>true</code> instead of default <code>false</code>. You can see your current value like this:
Si vous avez mis à jour votre système, vous pouvez tomber sur une anomalie dans laquelle chaque deuxième tentative de connexion échoue pour vous renvoyer sur l’écran de connexion (sans erreur visible). Cela se produit avec les sessions Wayland, mais pas avec les sessions X11. Au stade actuel, il semble que cela puisse être dû à  une valeur <code>org.gnome.SessionManager auto-save-session</code> faisant partie des gsettings égale à <code>true</code> au lieu de la valeur par défaut <code>false</code>. Vous pouvez lire votre valeur courante comme ceci :
<pre>$ gsettings get org.gnome.SessionManager auto-save-session</pre>
<pre>$ gsettings get org.gnome.SessionManager auto-save-session</pre>
and change it like this:
et la changer comme ceci :
<pre>$ gsettings set org.gnome.SessionManager auto-save-session false</pre>
<pre>$ gsettings set org.gnome.SessionManager auto-save-session false</pre>


If you encounter this bug, you may see a crash notification that traces back to bug #[[rhbug:1384508|1384508]]. This crash, and the bug report, actually cover a crash in the "Oh no!" screen which GNOME attempts to show when a core component crashes: the report doesn't actually cover the initial crash of the gnome-session component. This has caused some confusion, because the same "Oh no!" screen crash can be encountered in several other ways, and so several people with quite different bugs are all following the #[[rhbug:1384508|1384508]] bug report. See [[#gnome-ohno-crash|the entry for that crash]] for more details. [https://bugzilla.gnome.org/show_bug.cgi?id=775463 GNOME bug #775463] is the bug report for this specific {{code|auto-save-session}} crash case.
Si vous rencontrez cette anomalie, il est possible que vous voyiez une notification de plantage qui retrace l’anomalie #[[rhbug:1384508|1384508]]. Ce plantage, et le rapport d’anomalie, en réalité font référence à un plantage dans l’écran « Oh no! » que GNOME essaye de présenter lorsqu'un composant central se plante : le rapport ne couvre pas réellement le plantage initial du composant de la session gnome. Cela est à l’origine d’une certaine confusion parce que le même écran « Oh no! » peut se rencontrer dans plusieurs autres cas, c’est pourquoi plusieurs personnes rencontrant des anomalies tout à fait différentes  se fient au rapport d’anomalie #[[rhbug:1384508|1384508]]. Reportez-vous à [[#gnome-ohno-crash|l’entrée pour ce plantage]] pour plus de détails. [https://bugzilla.gnome.org/show_bug.cgi?id=775463 GNOME bug #775463] est le rapport d’anomalie spécifique pour le cas de plantage {{code|auto-save-session}}.


{{Common bugs issue|grub-fail-xfs|GRUB update might fail if /boot is on XFS|1227736}}
{{Common bugs issue|grub-fail-xfs|la mise à jour de GRUB pourrait échouer si  /boot est sur XFS|1227736}}


If you use XFS filesystem on <code>/boot</code> and upgrade your system, you might end up in a GRUB minimal prompt (just a command prompt, no kernel to choose from interactively) after the upgrade is complete. The problem is in the system rebooting while XFS is in dirty state and not all changes being saved to the filesystem yet.
Si vous utilisez le système de fichiers XFS sur <code>/boot</code> et mettez votre système à jour, vous pouvez vous retrouver avec une invite de commande minimale de GRUB (juste une invite de commande, aucun noyau à choisir de manière interactive) après que la mise à jour a été effectuée. Le problème est dû au redémarrage de système alors que XFS est dans un état « dirty » (sale) et que tous les changements n’ont pas encore été sauvegardés sur le système de fichiers.


In order to prevent this issue, you might try to disable plymouth (by removing <code>rhgb</code> kernel boot option) during the upgrade or uninstall it prior the upgrade (these workarounds were not tested).
Afin d’éviter ce problème, vous pourriez tenter de désactiver plymouth (en retirant l’option de démarrage <code>rhgb</code>) durant la mise à jour ou le désinstaller avec la mise à jour (ces solutions de contournement n’ont pas été testées).  


If this already occurred to you, you should be able to fix the problem by booting a Live or rescue image, mounting the filesystem in question (which should replay the journal), perhaps running <code>xfs_repair</code> to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.
Si cela c’est déjà produit pour vous, vous devriez être en mesure de régler le problème en démarrant une image live ou une image de sauvetage, en montant le système de fichiers en question (qui devrait rejouer le journal), peut-être en exécutant <code>xfs_repair</code> pour être sûr qu’il n’y a pas d’autre problème. Dans le pire des cas, vous devrez également réinstaller GRUB totalement.  


== Core system issues ==
== Problèmes du système central ==


{{Common bugs issue|pulseaudio-start-delay|Pulseaudio fails to start if user logs out and back in again very quickly|1510301}}
{{Common bugs issue|pulseaudio-start-delay|Le démarrage de Pulseaudio échoue si l’utilisateur quitte la session et y revient très rapidement|1510301}}


It has been reported that Pulseaudio (the default sound server for Fedora) sometimes fails to start correctly when a user logs out from a graphical session and logs back in immediately. The result of this is that sound playback and capture do not work as expected.
On a rapporté que Pulseaudia (le serveur de son par défaut de Fedora) ne démarre parfois pas correctement lorsqu’un utilisateur quitte une session graphique et y revient immédiatement. Le résultat est que le playback et la capture du son ne fonctionnent pas comme attendu.


This problem can be worked around by waiting a short time (about 30 seconds) between logins. It has also been suggested that changing the {{code|exit-idle-time}} setting in {{filename|/etc/pulse/daemon.conf}} to a lower value (e.g. 0) may prevent this problem occurring.
Une solution de contournement est d’attendre environ 30 secondes entre connexions. Il a aussi été suggéré que le changement du paramètre {{code|exit-idle-time}} dans {{filename|/etc/pulse/daemon.conf}} à une valeur plus basse (p. ex. 0) pourrait empêcher ce problème d’apparaître.


{{Common bugs issue|selinux-non-ascii|''Non-ASCII characters found'' error messages appear during package update etc.|1502009}}
{{Common bugs issue|selinux-non-ascii|Des messages ''Non-ASCII characters found'' apparaissent durant la mise à jour de paquets, etc.|1502009}}


While using Fedora 27, you may notice error messages like {{code|/etc/selinux/targeted/contexts/files/file_contexts.bin:  line 1 error due to: Non-ASCII characters found}} during package updates, system boot or in other situations. These errors do not indicate any serious problem and can safely be ignored. The SELinux maintainers are aware of the cause of this problem and intend to fix it with a future update to the {{package|selinux-policy}} packages.
Lors de l’utilisation de Fedora 27, vous pourriez remarquer des messages d’erreur comme  {{code|/etc/selinux/targeted/contexts/files/file_contexts.bin:  line 1 error due to: Non-ASCII characters found}} lors de la mise à jour de paquets, lors du redémarrage du système ou dans d’autres situations. Ces erreurs n’indiquent pas un problème sérieux et peuvent être ignorées  sans risque. Les mainteneurs de SELinux sont conscients des causes de ce problème et ont l’intention d’y apporter une solution lors d’une prochaine mise à jour des paquets de la {{package|politique selinux}}.


{{Common bugs issue|27-update-bash|Shell behavior changes (prompt etc.) on update from some Fedora 27 pre-release installs|1193590}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
{{Common bugs issue|27-update-bash|Changement de comportement de l’interprète de commandes (invite de commande, etc.) après mise à jour à partir de certaines installations de pré-version de  Fedora 27 |1193590}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


Some people who installed Fedora 27 between the Beta and Final release, and subsequently updated to the Final package set, may notice undesired changes in shell behavior. The most obvious symptom is that the prompt no longer looks as it usually does in Fedora, but shows the upstream default prompt (something like {{code|bash-4.4$}}). However, the problem actually runs deeper: when this happens, the shell is not sourcing {{filename|/etc/bashrc}} as it usually would, meaning everything that is usually implemented via {{filename|/etc/bashrc}} does not happen (including loading of all profile scripts in {{filename|/etc/profile.d}}, which has many consequences including default aliases not being set up).
Certaines personnes qui ont installé Fedora 27 entre les libérations Béta et finale, et ont par la suite mis à jour avec le jeu de paquets Final, ont pu noter des changements non désirés dans le comportement de l’interprète de commandes. Le symptôme le plus évident est que l’invite de commandes ne ressemble plus à ce qu’elle est ordinairement dans Fedora, mais à l’invite par défaut de l’amont (quelque chose comme {{code|bash-4.4$}}). Cependant, le problème est réellement plus profond : lorsque cela se produit, l’interprète de commandes ne source plus {{filename|/etc/bashrc}} comme il devrait normalement le faire. Cela veut dire que tout ce qui est normalement mis en œuvre via {{filename|/etc/bashrc}} ne l’est plus (y compris le chargement des scripts de profil dans  {{filename|/etc/profile.d}}, ce qui a des conséquences nombreuses comme la non définition des alias pas défaut).


This will only happen to user accounts created with version 4.4.12-11 of the {{package|bash}} package, when the system is updated to version 4.4.12-12. That version was in the updates-testing repository for Fedora 27 between 2017-09-11 and 2017-09-30, and was pushed to the stable repository on 2017-09-30. 4.4.12-12 was pushed to updates-testing on 2017-10-31 and to stable on 2017-11-08. So if you installed Fedora 27, or created user accounts on an installed Fedora 27 system, between 2017-09-11 and 2017-11-08, you ''may'' be affected by this issue (it will depend on factors including the install image you used, what repositories were enabled, and so on).
Cela arrive seulement aux comptes utilisateurs créés avec la version 4.4.12-11 du paquet {{package|bash}}, lorsque le système est mis à jour à la version 4.4.12-12. Cette version était dans le dépôt updates-testing pour Fedora 27 entre les  11 et 30 septembre 2017, et a été poussé sur le dépôt stable le 30 septembre 2017. 4.4.12-12 a été poussé sur le dépôt updates-testing le 31 octobre 2017 et sur le dépôt stable le 8 novembre 2017. C’est pourquoi, si vous avez installé Fedora 27, ou créé des comptes utilisateurs sur un système Fedora 27 installé, entre le 11 septembre 2017 et le 8 novembre 2017, vous « pouvez » être concerné par ce problème (cela dépend de facteurs incluant l’image d’installation que vous avez utilisée, quels dépôts étaient activés, etc.).  


'''No fresh install of Fedora 27 Final or upgrade to Fedora 27 performed after 2017-11-08 should be affected by this issue'''.
'''Aucune nouvelle installation de Fedora 27 final ou mise à jour vers Fedora 27 effectuée après le 8 novembre 2017 ne devrait être concernée par ce problème.'''


If you are affected by this issue, you can resolve it simply by adding this text to the top of the {{filename|~/.bashrc}} for all affected user accounts (including root):
Si vous ce problème vous affecte, vous pouvez le résoudre en ajoutant ce texte en tête de {{filename|~/.bashrc}} pour tous les comptes utilisateurs affectés (y compris le compte de root) :


  # Source global definitions
  # Source global definitions
Line 77: Line 79:
  fi
  fi


It usually appears between the lines {{code|# .bashrc}} and {{code|# User specific aliases and functions}}. This should fully resolve the problem.
Cela apparaît ordinairement entre les lignes  {{code|# .bashrc}} et {{code|# User specific aliases and functions}}. Cela devrait résoudre complètement le problème.


For the record, this issue was caused by a change to {{filename|/etc/bashrc}} sourcing which was not fully thought through. Prior to 4.4.12-11, the template for {{filename|~/.bashrc}} in Fedora included the lines above, causing bash shells launched by any user to source {{filename|/etc/bashrc}} via {{filename|~/.bashrc}}. 4.4.12-11 changed bash to source {{filename|/etc/bashrc}} directly on every startup, and changed the template for user {{filename|~/.bashrc}} files to not include the above lines. However, this change turned out to have several problematic consequences which were not understood before it was made, and which could not be fixed in time for the Fedora 27 release.
Pour mémoire, ce problème était dû à un changement dans le sourcing de  {{filename|/etc/bashrc}} pas assez réfléchi. Avant 4.4.12-11, le modèle pour  {{filename|~/.bashrc}} dans Fedora incluait les lignes présentées ci-dessus, amenant les interprètes de commandes lancés par n’importe quel utilisateur à sourcer  {{filename|/etc/bashrc}} via {{filename|~/.bashrc}}. 4.4.12-11 a modifié bash pour qu’il source {{filename|/etc/bashrc}} directement à chaque démarrage, et a changé le modèle pour les fichiers utilisateurs  {{filename|~/.bashrc}} pour ne pas inclure les lignes ci-dessus. Cependant, ce changement s’est avéré responsable de plusieurs conséquences problématiques qui n’ont pas été comprises avant que le changement ne soit fait, et qui n’ont pu être solutionnées à temps pour la libération Fedora 27.  


We felt the only viable response was to revert the change, and this is what 4.4.12-12 does. However, since 4.4.12-11 changed the {{filename|~/.bashrc}} template, all user accounts created with that version of bash do not have those lines, and so with bash 4.4.12-12, nothing causes {{filename|/etc/bashrc}} to be sourced by bash shells run by those accounts. Fedora package scripts by policy may never touch files in a user's home directory, so it would be against our policies for the bash package to attempt to "fix" affected user accounts on update; even ignoring the policy, trying to do this would be a very bad idea as any such attempt could contain bugs which caused more severe problems, or could add the stanza to user accounts from which it had been intentionally removed for some reason.
Nous pensions que la seule réponse viable était de revenir en arrière sur le changement, et c’est ce que 4.4.12-12 fait. Cependant, comme 4.4.12-11 modifiait le modèle {{filename|~/.bashrc}}, tous les comptes utilisateur créés avec cette version de bash ne comprennent pas ces lignes, et ainsi, avec bash 4.4.12-12, rien ne fait que  {{filename|/etc/bashrc}} soit sourcé par des interprètes de commande bash exécutés depuis ces comptes. La politique est que les scripts des paquets de Fedora ne puissent jamais créer des fichiers dans le dossier home d’un utilisateur, c’est pourquoi ce serait contraire à notre politique  que le paquet bash tente de « réparer » les comptes utilisateurs sur mise à jour ; même en ignorant la politique, essayer de faire cela serait une bien mauvaise idée car n’importe quelle tentative de ce genre pourrait contenir des bogues susceptibles de créer des problèmes encore plus sévères, ou pourrait ajouter cette strophe à des comptes utilisateurs desquels elle a été intentionnellement retirée pour quelque raison.  


We do apologize to users affected by this issue for the inconvenience, and for being unable to come up with a better course of action.
Nous nous excusons sincèrement auprès des utilisateurs affectés par ce problème pour les inconvénients et pour ne pas être en mesure d’adopter une meilleure solution.


== GNOME issues ==
== Problèmes GNOME ==


{{Common bugs issue|wayland-issues|Wayland issues}}
{{Common bugs issue|wayland-issues|Problèmes Wayland}}


[https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 Wayland] is the replacement for the legacy [https://en.wikipedia.org/wiki/X_Window_System X11] display stack. Although development has been rapid and Wayland is usable in most situations, some bugs remain. Please see the following link to learn the details:
[https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 Wayland] a remplacé la traditionnelle pile d’affichage [https://en.wikipedia.org/wiki/X_Window_System X11]. Bien que le développement ait été rapide et que Wayland soit utilisable  dans la plupart des situations, il reste quelques anomalies. Suivez ce lien pour en savoir plus :  
* [[Wayland_features|Wayland features status]]
* [[Wayland_features|État des fonctionnalités de Wayland]]
* '''[[How_to_debug_Wayland_problems#known_issues|Known issues in Wayland]]'''
* '''[[How_to_debug_Wayland_problems#known_issues|Problèmes connus avec Wayland]]'''
* [[How_to_debug_Wayland_problems#Looking_for_similar_reports|Bug reports related to Wayland]]
* [[How_to_debug_Wayland_problems#Looking_for_similar_reports|Rapport d’anomalie en relation avec Wayland]]


Please check the list for your issue before you file a new bug, although if you're not sure, filing a new bug is the right thing to do.
Merci de vérifier que votre problème n’est pas dans la liste avec de remplir un nouveau rapport d’anomalie, bien que, dans le doute, remplir un rapport d’anomalie soit la bonne chose à faire.  


Wayland is currently enabled by default only in GNOME. If you want to disable it, select ''GNOME on Xorg'' as session type when logging in (you only see this screen if your user has a password defined):
Wayland est présentement activé par défaut dans GNOME. Si vous désirez le désactiver, sélectionnez « GNOME on Xorg » en tant que session au moment de vous connecter (vous ne rencontrez cet écran que si votre utilisateur dispose d’un mot de passe) :


[[File:gdm-pick-x11.png|500px]]
[[File:gdm-pick-x11.png|500px]]


{{Common bugs issue|shell-crash-wayland|User session dies if GNOME Shell crashes on Wayland|1494586|1469129}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
{{Common bugs issue|shell-crash-wayland|La session utilisateur meurt si l’interface graphique plante dans Wayland|1494586|1469129}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


One difference between GNOME on X.org and GNOME on Wayland lies in what happens if GNOME Shell itself crashes. When running GNOME on X.org, a Shell crash usually does not end the session; the Shell will be automatically restarted and the session will continue. For a one-off crash, all you (the user) will usually see is the panel and perhaps window titles suddenly disappear and reappear shortly afterwards, and a crash notification appear. This behaviour is possible because X.org is the display server, with GNOME Shell just an X application running on top of it.
Une différence entre GNOME sur X.org et GNOME sur Wayland réside dans ce qui se produit si l’interface graphique se plante. En exécutant GNOME sur X.org, un tel plantage ne met généralement pas fin à la session ; l’interface graphique est automatiquement redémarrée et la session se poursuit. Pour un plantage unique, tout ce que l’utilisateur voit est le tableau de bord et peut-être les titres des fenêtres disparaître soudainement pour ré-apparaître peu de temps après, tandis qu’une notification de plantage est affichée. Ce comportement est rendu possible parce que X.org est le serveur d’affichage, avec l’interface graphique de GNOME s’exécutant comme une simple application au-dessus de lui.


However, when running GNOME on Wayland, the Shell itself is effectively the display server. Thus, if it crashes, the entire user session is usually taken down with it. This can result in the loss of unsaved data, and so on.
Cependant, lorsqu’on exécute GNOME sur Wayland, l’interface graphique est en réalité le serveur d’affichage. Par conséquent, si elle se plante, la session entière est généralement arrêtée avec elle. Cela peut conduire à une perte de données non encore sauvegardées et ainsi de suite.  


Efforts are afoot upstream to somehow separate the display server / compositor role from the rest of the Shell and make it as minimal and reliable as possible. Until this is complete, there is nothing really that Fedora can do about this limitation.
Des efforts sont en cours en amont pour séparer le serveur d’affichage / rôle de composeur du reste de l’interface et pour le rendre aussi petit et fiable que possible. Avant que cela ne soit achevé, il n’y a rien que Fedora puisse faire à ce sujet.  


During Fedora 27 testing, several GNOME Shell crasher bugs were reported by multiple users, including #[[rhbug:1494586|1494586]] and #[[rhbug:1469129|1469129]]. We cannot be entirely sure if Shell in Fedora 27 is significantly more crash-prone than in previous recent releases, but it appears at least possible that for some users and some configurations, this may be the case. Obviously, if you are affected by recurring Shell crashes, the consequence of losing the entire user session can be frustrating.
Lors des tests de Fedora 27, plusieurs anomalies sur le plantage de l’interface graphique de GNOME ont été rapportées par de multiples utilisateurs, y compris les anomalies #[[rhbug:1494586|1494586]] et #[[rhbug:1469129|1469129]]. Nous ne sommes pas tout à fait certains que l’interface graphique dans Fedora 27 soit significativement plus encline au plantage que dans les versions précédentes, mais il apparaît comme possible que, pour certains utilisateurs et dans certaines configurations, ce soit le cas. Bien évidemment, si vous êtes affectés par des plantages récurrents de l’interface graphique, les conséquences de la perte totale de la session peuvent être très frustrantes.  


We advise folks suffering from Shell crashes taking down their user session to first try disabling any extensions they have enabled, one by one, to see if one is the cause; Shell crashes can quite often be caused by misbehaving extensions. If you can avoid the crashes by disabling an extension, this may suffice (please report the issue to the extension author if you can isolate it to a specific extension). Otherwise, we advise that you may wish to consider using the GNOME on Xorg session (see above) rather than the default Wayland session; this should at least prevent the crashes from ending your GNOME session when they occur. We do apologize for any inconvenience and/or lost data caused by such Shell crashes.
Nous conseillons à ceux qui souffrent de plantage de l’interface graphique entraînant la perte de session, de commencer par désactiver une par une toutes les extensions qu’ils ont activées, pour voir si l’une d’elle en est la cause ; les plantages de l’interface graphique peuvent être assez souvent causés par des extensions au mauvais comportement. Si vous êtes en mesure d’éviter les plantages en désactivant une extension, cela peut suffire (merci de rapporter le problème à l’auteur de l’extension si vous êtes capable d’en isoler une). Autrement, nous vous invitons à considérer d’utiliser la session GNOME sur Xorg (voir ci-dessus) plutôt que la session Wayland par défaut ; cela pourrait au moins empêcher les plantages de mettre fin à votre session lorsqu’ils se produisent. Nous vous présentons nos excuses pour ces inconvénients et/ou pour ces pertes de données consécutives à des plantages de l’interface graphique.


{{Common bugs issue|wayland-root-apps|Running graphical apps with root privileges (e.g. gparted) does not work on Wayland|1274451}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
{{Common bugs issue|wayland-root-apps|Exécuter des applications graphiques avec les privilèges root (p. ex. gparted) ne fonctionne pas sur Wayland|1274451}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


Running graphical applications with root privileges does not work on Wayland. This is not exactly a bug, but an intentional design, at least at present: it is part of a general plan to make Wayland safer than X (which is very vulnerable to exploitation by malicious applications). It is generally intended that apps which need root privileges to perform some operations should be designed such that the application itself does not need root privileges, but uses a mechanism like PolicyKit to have privileges granted to a restricted subset of itself which only handles the operations that actually need elevated privileges.
Running graphical applications with root privileges does not work on Wayland. This is not exactly a bug, but an intentional design, at least at present: it is part of a general plan to make Wayland safer than X (which is very vulnerable to exploitation by malicious applications). It is generally intended that apps which need root privileges to perform some operations should be designed such that the application itself does not need root privileges, but uses a mechanism like PolicyKit to have privileges granted to a restricted subset of itself which only handles the operations that actually need elevated privileges.

Latest revision as of 17:28, 26 April 2018

Cette page fournit de l’information sur les anomalies courantes de Fedora 27, et, si elles sont disponibles, les solutions à ces problèmes. Si vous trouvez votre anomalie sur cette page, « ne faites pas de rapport d’anomalie sur Bugzilla », sauf si des instructions vous sont données pour cela. Quand cela est approprié, une référence à l’anomalie courante dans Bugzilla est fournie.

Notes de version

Lisez l’annonce de libération de Fedora 27 et les notes de version de Fedora 27 pour des informations spécifiques sur les changements apportés par Fedora 27 et pour d’autres informations plus générales.


Mon anomalie n’apparaît pas

Toutes les anomalies ne sont pas listées dans cette page, mais Bugzilla devrait être une base de données complète sur les anomalies connues. Cette page est un échantillon des anomalies les plus communément discutées sur nos listes de diffusion et sur les forums.

Pour savoir si votre anomalie a déjà été rapportée, vous pouvez rechercher dans Bugzilla. Si elle n’a pas encore été rapportée, nous vous encourageons à le faire afin d’aider Fedora dans votre intérêt et dans celui des autres. Un guide sur les anomalies et demandes de fonctionnalités a été créé pour vous aider.

Si vous pensez qu'une anomalie déjà rapportée devrait être ajoutée à « cette » page parce qu'elle est fréquemment rencontrée, vous pouvez :

  • l'ajouter vous-même, si vous avez un accès à ce wiki. Common_bugs_instructions vous guide sur la manière d’ajouter une entrée à la page correctement, mais la chose la plus importante est de vous assurer que l’anomalie est listée — ne vous inquiétez pas trop si vous n’obtenez pas le bon format d’emblée, nous pouvons améliorer la chose ultérieurement.
  • Ou, ajouter le mot clé « CommonBugs » au rapport d’anomalie. Quelqu’un de l’équipe QA inspectera l’anomalie pour savoir s’il faut l’ajouter en tant qu’anomalie commune. Pour envoyer votre requête, ajoutez un commentaire à l’anomalie qui comprend
    1. un résumé de l’anomalie
    2. tout moyen de contournement connu
    3. une évaluation de l’impact sur les utilisateurs de Fedora.

Pour référence, vous pouvez interroger Bugzilla pour les anomalies marquées « CommonBugs » :

  • CommonBugs? (anomalies avec le mot clé CommonBugs, mais qui n’a pas encore  de lien vers cette page)
  • CommonBugs+(anomalies avec le mot clé CommonBugs et contenant un lien vers cette page)


Problèmes d’installation

Le changement d’arrangement de clavier à partir des combinaisons de touches ne fonctionne pas dans Wayland

link to this item - Bugzilla: #1389959

Si vous utilisez le média Live d’installation de Workstation et que vous configurez plusieurs langues dans l’installateur, il ne vous sera pas possible de passer de l’une à l’autre à partir des raccourcis systèmes standard (typiquement Win+Espace or Alt+Maj). Cependant, vous pouvez toujours cliquer sur l’indicateur de langues dans l’installateur pour cela.

Cela n’affecte pas les autres médias d’installation (KDE Live, DVD et les images netinst).

On ne peut démarrer macOS depuis Grub

link to this item - Bugzilla: #893179

Si vous installez Fedora en double démarrage sur Mac, Fedora crée plusieurs entrées de menu « Mac OS X » dans Grub qui devraient vous permettre de démarrer macOS. Ces entrées de menu sont néanmoins cassées et macOS ne peut être démarré depuis Grub. La solution de contournement est de presser et de maintenir la touche Opt (ou la touche Alt de droite) au démarrage de l’ordinateur, pour entrer dans le menu de démarrage UEFI et sélectionner la partition macOS de laquelle démarrer.

L’installateur de plusieurs images live ne prend pas en charge iSCSI

link to this item - Bugzilla: #1395620 - Bugzilla: #1429132

Sur de nombreuses, ou sur toutes les images live de Fedora, l’installateur n’offre pas la fonctionnalité iSCSI (le bouton « AJouter une cible iSCSI » n’apparaît pas dans l’écran « Disques spécialisés et réseaux »). Vous pouvez éviter le problème en exécutant sudo dnf install storaged-iscsi depuis une console avant de lancer le processus d’installation, ou en installant à partir d’une image dédiée plutôt qu’à partir d’une image live.

Problèmes de mise à jour

Écran gris gelé au moment de la connexion après mise à jour

link to this item - Bugzilla: #1394755

Ceci se produit si vous avez installé l’extension EasyScreenCast et mis à jour. C’est la même anomalie que #screen-recording-freezes-gnome, reportez-vous à cette entrée pour une description complète et une solution de contournement.

Chaque deuxième tentative de connexion échoue dans certaines configurations

link to this item – GNOME bug #775463

Si vous avez mis à jour votre système, vous pouvez tomber sur une anomalie dans laquelle chaque deuxième tentative de connexion échoue pour vous renvoyer sur l’écran de connexion (sans erreur visible). Cela se produit avec les sessions Wayland, mais pas avec les sessions X11. Au stade actuel, il semble que cela puisse être dû à une valeur org.gnome.SessionManager auto-save-session faisant partie des gsettings égale à true au lieu de la valeur par défaut false. Vous pouvez lire votre valeur courante comme ceci :

$ gsettings get org.gnome.SessionManager auto-save-session

et la changer comme ceci :

$ gsettings set org.gnome.SessionManager auto-save-session false

Si vous rencontrez cette anomalie, il est possible que vous voyiez une notification de plantage qui retrace l’anomalie #1384508. Ce plantage, et le rapport d’anomalie, en réalité font référence à un plantage dans l’écran « Oh no! » que GNOME essaye de présenter lorsqu'un composant central se plante : le rapport ne couvre pas réellement le plantage initial du composant de la session gnome. Cela est à l’origine d’une certaine confusion parce que le même écran « Oh no! » peut se rencontrer dans plusieurs autres cas, c’est pourquoi plusieurs personnes rencontrant des anomalies tout à fait différentes se fient au rapport d’anomalie #1384508. Reportez-vous à l’entrée pour ce plantage pour plus de détails. GNOME bug #775463 est le rapport d’anomalie spécifique pour le cas de plantage auto-save-session.

la mise à jour de GRUB pourrait échouer si /boot est sur XFS

link to this item - Bugzilla: #1227736

Si vous utilisez le système de fichiers XFS sur /boot et mettez votre système à jour, vous pouvez vous retrouver avec une invite de commande minimale de GRUB (juste une invite de commande, aucun noyau à choisir de manière interactive) après que la mise à jour a été effectuée. Le problème est dû au redémarrage de système alors que XFS est dans un état « dirty » (sale) et que tous les changements n’ont pas encore été sauvegardés sur le système de fichiers.

Afin d’éviter ce problème, vous pourriez tenter de désactiver plymouth (en retirant l’option de démarrage rhgb) durant la mise à jour ou le désinstaller avec la mise à jour (ces solutions de contournement n’ont pas été testées).

Si cela c’est déjà produit pour vous, vous devriez être en mesure de régler le problème en démarrant une image live ou une image de sauvetage, en montant le système de fichiers en question (qui devrait rejouer le journal), peut-être en exécutant xfs_repair pour être sûr qu’il n’y a pas d’autre problème. Dans le pire des cas, vous devrez également réinstaller GRUB totalement.

Problèmes du système central

Le démarrage de Pulseaudio échoue si l’utilisateur quitte la session et y revient très rapidement

link to this item - Bugzilla: #1510301

On a rapporté que Pulseaudia (le serveur de son par défaut de Fedora) ne démarre parfois pas correctement lorsqu’un utilisateur quitte une session graphique et y revient immédiatement. Le résultat est que le playback et la capture du son ne fonctionnent pas comme attendu.

Une solution de contournement est d’attendre environ 30 secondes entre connexions. Il a aussi été suggéré que le changement du paramètre exit-idle-time dans /etc/pulse/daemon.conf à une valeur plus basse (p. ex. 0) pourrait empêcher ce problème d’apparaître.

Des messages Non-ASCII characters found apparaissent durant la mise à jour de paquets, etc.

link to this item - Bugzilla: #1502009

Lors de l’utilisation de Fedora 27, vous pourriez remarquer des messages d’erreur comme /etc/selinux/targeted/contexts/files/file_contexts.bin: line 1 error due to: Non-ASCII characters found lors de la mise à jour de paquets, lors du redémarrage du système ou dans d’autres situations. Ces erreurs n’indiquent pas un problème sérieux et peuvent être ignorées sans risque. Les mainteneurs de SELinux sont conscients des causes de ce problème et ont l’intention d’y apporter une solution lors d’une prochaine mise à jour des paquets de la selinux politique selinux.

Changement de comportement de l’interprète de commandes (invite de commande, etc.) après mise à jour à partir de certaines installations de pré-version de Fedora 27

link to this item - Bugzilla: #1193590

Certaines personnes qui ont installé Fedora 27 entre les libérations Béta et finale, et ont par la suite mis à jour avec le jeu de paquets Final, ont pu noter des changements non désirés dans le comportement de l’interprète de commandes. Le symptôme le plus évident est que l’invite de commandes ne ressemble plus à ce qu’elle est ordinairement dans Fedora, mais à l’invite par défaut de l’amont (quelque chose comme bash-4.4$). Cependant, le problème est réellement plus profond : lorsque cela se produit, l’interprète de commandes ne source plus /etc/bashrc comme il devrait normalement le faire. Cela veut dire que tout ce qui est normalement mis en œuvre via /etc/bashrc ne l’est plus (y compris le chargement des scripts de profil dans /etc/profile.d, ce qui a des conséquences nombreuses comme la non définition des alias pas défaut).

Cela arrive seulement aux comptes utilisateurs créés avec la version 4.4.12-11 du paquet bash, lorsque le système est mis à jour à la version 4.4.12-12. Cette version était dans le dépôt updates-testing pour Fedora 27 entre les 11 et 30 septembre 2017, et a été poussé sur le dépôt stable le 30 septembre 2017. 4.4.12-12 a été poussé sur le dépôt updates-testing le 31 octobre 2017 et sur le dépôt stable le 8 novembre 2017. C’est pourquoi, si vous avez installé Fedora 27, ou créé des comptes utilisateurs sur un système Fedora 27 installé, entre le 11 septembre 2017 et le 8 novembre 2017, vous « pouvez » être concerné par ce problème (cela dépend de facteurs incluant l’image d’installation que vous avez utilisée, quels dépôts étaient activés, etc.).

Aucune nouvelle installation de Fedora 27 final ou mise à jour vers Fedora 27 effectuée après le 8 novembre 2017 ne devrait être concernée par ce problème.

Si vous ce problème vous affecte, vous pouvez le résoudre en ajoutant ce texte en tête de ~/.bashrc pour tous les comptes utilisateurs affectés (y compris le compte de root) :

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

Cela apparaît ordinairement entre les lignes # .bashrc et # User specific aliases and functions. Cela devrait résoudre complètement le problème.

Pour mémoire, ce problème était dû à un changement dans le sourcing de /etc/bashrc pas assez réfléchi. Avant 4.4.12-11, le modèle pour ~/.bashrc dans Fedora incluait les lignes présentées ci-dessus, amenant les interprètes de commandes lancés par n’importe quel utilisateur à sourcer /etc/bashrc via ~/.bashrc. 4.4.12-11 a modifié bash pour qu’il source /etc/bashrc directement à chaque démarrage, et a changé le modèle pour les fichiers utilisateurs ~/.bashrc pour ne pas inclure les lignes ci-dessus. Cependant, ce changement s’est avéré responsable de plusieurs conséquences problématiques qui n’ont pas été comprises avant que le changement ne soit fait, et qui n’ont pu être solutionnées à temps pour la libération Fedora 27.

Nous pensions que la seule réponse viable était de revenir en arrière sur le changement, et c’est ce que 4.4.12-12 fait. Cependant, comme 4.4.12-11 modifiait le modèle ~/.bashrc, tous les comptes utilisateur créés avec cette version de bash ne comprennent pas ces lignes, et ainsi, avec bash 4.4.12-12, rien ne fait que /etc/bashrc soit sourcé par des interprètes de commande bash exécutés depuis ces comptes. La politique est que les scripts des paquets de Fedora ne puissent jamais créer des fichiers dans le dossier home d’un utilisateur, c’est pourquoi ce serait contraire à notre politique que le paquet bash tente de « réparer » les comptes utilisateurs sur mise à jour ; même en ignorant la politique, essayer de faire cela serait une bien mauvaise idée car n’importe quelle tentative de ce genre pourrait contenir des bogues susceptibles de créer des problèmes encore plus sévères, ou pourrait ajouter cette strophe à des comptes utilisateurs desquels elle a été intentionnellement retirée pour quelque raison.

Nous nous excusons sincèrement auprès des utilisateurs affectés par ce problème pour les inconvénients et pour ne pas être en mesure d’adopter une meilleure solution.

Problèmes GNOME

Problèmes Wayland

link to this item

Wayland a remplacé la traditionnelle pile d’affichage X11. Bien que le développement ait été rapide et que Wayland soit utilisable dans la plupart des situations, il reste quelques anomalies. Suivez ce lien pour en savoir plus :

Merci de vérifier que votre problème n’est pas dans la liste avec de remplir un nouveau rapport d’anomalie, bien que, dans le doute, remplir un rapport d’anomalie soit la bonne chose à faire.

Wayland est présentement activé par défaut dans GNOME. Si vous désirez le désactiver, sélectionnez « GNOME on Xorg » en tant que session au moment de vous connecter (vous ne rencontrez cet écran que si votre utilisateur dispose d’un mot de passe) :

La session utilisateur meurt si l’interface graphique plante dans Wayland

link to this item - Bugzilla: #1494586 - Bugzilla: #1469129

Une différence entre GNOME sur X.org et GNOME sur Wayland réside dans ce qui se produit si l’interface graphique se plante. En exécutant GNOME sur X.org, un tel plantage ne met généralement pas fin à la session ; l’interface graphique est automatiquement redémarrée et la session se poursuit. Pour un plantage unique, tout ce que l’utilisateur voit est le tableau de bord et peut-être les titres des fenêtres disparaître soudainement pour ré-apparaître peu de temps après, tandis qu’une notification de plantage est affichée. Ce comportement est rendu possible parce que X.org est le serveur d’affichage, avec l’interface graphique de GNOME s’exécutant comme une simple application au-dessus de lui.

Cependant, lorsqu’on exécute GNOME sur Wayland, l’interface graphique est en réalité le serveur d’affichage. Par conséquent, si elle se plante, la session entière est généralement arrêtée avec elle. Cela peut conduire à une perte de données non encore sauvegardées et ainsi de suite.

Des efforts sont en cours en amont pour séparer le serveur d’affichage / rôle de composeur du reste de l’interface et pour le rendre aussi petit et fiable que possible. Avant que cela ne soit achevé, il n’y a rien que Fedora puisse faire à ce sujet.

Lors des tests de Fedora 27, plusieurs anomalies sur le plantage de l’interface graphique de GNOME ont été rapportées par de multiples utilisateurs, y compris les anomalies #1494586 et #1469129. Nous ne sommes pas tout à fait certains que l’interface graphique dans Fedora 27 soit significativement plus encline au plantage que dans les versions précédentes, mais il apparaît comme possible que, pour certains utilisateurs et dans certaines configurations, ce soit le cas. Bien évidemment, si vous êtes affectés par des plantages récurrents de l’interface graphique, les conséquences de la perte totale de la session peuvent être très frustrantes.

Nous conseillons à ceux qui souffrent de plantage de l’interface graphique entraînant la perte de session, de commencer par désactiver une par une toutes les extensions qu’ils ont activées, pour voir si l’une d’elle en est la cause ; les plantages de l’interface graphique peuvent être assez souvent causés par des extensions au mauvais comportement. Si vous êtes en mesure d’éviter les plantages en désactivant une extension, cela peut suffire (merci de rapporter le problème à l’auteur de l’extension si vous êtes capable d’en isoler une). Autrement, nous vous invitons à considérer d’utiliser la session GNOME sur Xorg (voir ci-dessus) plutôt que la session Wayland par défaut ; cela pourrait au moins empêcher les plantages de mettre fin à votre session lorsqu’ils se produisent. Nous vous présentons nos excuses pour ces inconvénients et/ou pour ces pertes de données consécutives à des plantages de l’interface graphique.

Exécuter des applications graphiques avec les privilèges root (p. ex. gparted) ne fonctionne pas sur Wayland

link to this item - Bugzilla: #1274451

Running graphical applications with root privileges does not work on Wayland. This is not exactly a bug, but an intentional design, at least at present: it is part of a general plan to make Wayland safer than X (which is very vulnerable to exploitation by malicious applications). It is generally intended that apps which need root privileges to perform some operations should be designed such that the application itself does not need root privileges, but uses a mechanism like PolicyKit to have privileges granted to a restricted subset of itself which only handles the operations that actually need elevated privileges.

This means you cannot run, for example, sudo gedit /etc/someconfigfile.conf or sudo gvim /etc/someconfigfile.conf to edit a file which requires root privileges to save. It also stops gparted working by default at all, as it is designed to run with root privileges by default. There are various ways to work around different elements of this problem.

For applications which use the GTK+ Gvfs file access layer, there is an admin:/// resource indicator available. So you can, for example, run gedit admin:///etc/someconfigfile.conf to edit a file requiring root privileges to save. In future, this mechanism will be better integrated into applications so you do not have to manually invoke it. This will not work for applications which do not use Gvfs, though, like gvim.

In other cases, you may be able to use an alternative application. For instance, you may find the Disks application (gnome-disks from a console) can do what you wanted to do with gparted.

There is a workaround you can use to allow non-Wayland-native apps to run as root if you absolutely must: from a console as the regular user, run xhost +si:localuser:root. This will not work for Wayland-native applications, however, only apps which run via XWayland.

Finally, if none of these options is workable for you, you can switch back to using X.org instead of Wayland, as documented above.

Totem fails to play media on Wayland in virtual machines

link to this item - Bugzilla: #1467368

Totem (Videos) will fail to play media when using a Wayland session in virtual machines (applies to default libvirt VMs, but not VirtualBox). The audio will play, but neither video nor a totem window will appear. If you need to play media in this environment, please either use X11 session, or a different media player.

Vino server (remote desktop server) crashes on login under Wayland

link to this item - Bugzilla: #1394599

If you have configured a remote desktop server using vino-server (available e.g. in GNOME settings), you'll see a crash each time you log in into a Wayland session. Remote desktop functionality is not yet supported under Wayland. Either disable the remote desktop server (Settings -> Sharing -> Screen sharing) to avoid seeing the crash notifications or use Xorg session instead (if you require remote desktop functionality).

Screen recording freezes GNOME in certain conditions

link to this item - Bugzilla: #1394755

If you start screen recording in GNOME (Ctrl+Alt+Shift+R) your session might freeze hard (you can only get out of it using SysRq or ssh in and kill your session). This is related to gstreamer registry cache file (~/.cache/gstreamer-1.0/registry.x86_64.bin) - when it is changed (might happen during a plugin update, or if you remove the file), this bug occurs. It is not only triggered by the integrated GNOME recorder, but also by extensions/tools like EasyScreenCast - in that case, the freeze occurs immediately during login.

The existing workaround is to select Xorg session in the session picker (see #Wayland issues) and log in at least once. That fixes the cache file and then it should be possible to log in even to Wayland session. It also helps to remove EasyScreenCast extension (if you have it installed), and remove clutter-gst2 package (but some of your apps might depend on it). If none of that helps for you, please continue using the Xorg session instead of the default Wayland session, until this bug is fixed.

Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland

link to this item - Bugzilla: #1386602

Under Wayland, sending scroll events into a virtual machine works well when using the mouse, but doesn't work when using touchpad or trackpoint. As a workaround, switch to Xorg session on your host.

Workstation login screen (GDM) does not show newly-installed desktops until system is rebooted or shut down

link to this item - Bugzilla: #1398770

If you install an additional desktop environment after installing Fedora Workstation, it will not appear on the session chooser in the login screen (GDM) if you simply log out from a user session and log in again. This is because gdm keeps running after logging you into your user session, and there is no signal to tell it that a new desktop has been installed; it will not notice until it is restarted. It is possible to restart GDM without restarting the system, but in practice rebooting or shutting down and starting up again is usually the easiest thing to do.

Some text views (gedit...) not properly scaled when Large Text or a text scaling factor set

link to this item

Due to an issue with some specific text view widgets, when a 'text scaling factor' is set in GNOME, this scaling is not properly applied in a few specific cases. This makes text appear tiny. Setting the Large Text option in Universal Access sets a text scaling factor; it is also possible to set one manually in the gnome-tweak-tool application, so if you have set either of those options, you will likely see this bug.

This issue is known to affect gedit (the text in the document being edited, not the user interface), anjuta, and latexila.

To work around this issue in gedit you can just set a custom font in Preferences and make its point size larger than normal. A similar workaround may be available for other affected apps.

Arrangement of multiple displays unreliable with more than two displays

link to this item - Bugzilla: #1511638

Update available for testing
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command: sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2017-6d66333885

The GNOME tool for configuring and arranging multiple displays (Displays) has been reported by several users to be unreliable on systems with more than two displays. This appears to be the case even when only two of the displays are active - a common affected configuration is a laptop with two external displays and the laptop screen closed. The symptoms are that when attempting to move the displays around in the tool, they simply fail to move, or immediately jump back to their original positions.

Reporters have said that it's usually possible to achieve the desired result after trying several times, and sometimes moving the displays around in different directions. It has also been reported that clicking and releasing shortly (not dragging) one of the displays will make it jump out of the way, allowing movement of the others.

Pointer invisible in GDM in virtual machines

link to this item - Bugzilla: #1507931

When booting Fedora 27 Workstation (or any other Fedora 27 install which uses GDM as the login manager) on a virtual machine using the QXL virtual video adapter (which is the default for virt-manager and GNOME Boxes in most cases), the mouse pointer will not appear in the login manager (GDM). Once you log in, the pointer will show up in the logged-in desktop session. Note the pointer is in fact present and active - if you can figure out where it is, you can click on things - it's just not visible.

It is quite easy to complete GDM using only the keyboard (to log in with the default user, you only have to hit 'enter', type their password, and hit 'enter' again). You can also work around this issue by switching to a different adapter in the virtual machine configuration, e.g. 'virtio'.

Content of VPN entry in GNOME status menu sometimes does not appear

link to this item - Bugzilla: #1497897

Some users of Fedora 27 have reported that, sometimes, the icon and text of the VPN entry in the GNOME status menu (the one that appears when you click the top-right of the screen) does not appear. Usually it will show a lock icon and the text 'VPN Off' (or information on any active VPN connection), but it appears that occasionally the icon and text do not appear; the menu just appears to contain an entirely empty row. The entry does function as intended.

No fix for this issue is yet known, but it has no functional impact - you can still use the 'empty' menu item.

Plasma (KDE) issues

Logging out second user kills first user's session on KDE in a virtual machine (QXL driver)

link to this item - Bugzilla: #1382001

When you live switch users, logging out the second user kills the first user's session. This only happens with QXL driver which is used in virtual machines by default (GNOME Boxes, virt-manager).

Network issues

Hardware issues

Fedora 27 images may fail to boot on Surface Book

link to this item - Bugzilla: #1501362

Two users have reported that Fedora 27 images fail to boot on the Microsoft Surface Book (model uncertain), with some suggestion that this is due to an issue with processor microcode updating. If you are trying to boot or install Fedora 27 on a Surface Book and it is failing, you may try installing Fedora 26 and then upgrading to Fedora 27 as a workaround. You may also try a network installation of Fedora 27, or using one of the unofficial post-release live respin images.

Application issues

Kerberos might be broken in certain cases

link to this item - Bugzilla: #1494843

Kerberos doesn't work in certain configurations on Fedora 27, probably on some upgraded systems and when sssd-kcm is installed. You'll see errors like Internal credentials cache error while getting default ccache. If you're affected, removing /var/lib/sss/secrets/secrets.ldb file and rebooting seems to help.

ARM issues

Network configuration file from image creation on AArch64 disk images

link to this item - Bugzilla: #1507676

A network configuration file from the disk image creation process is still present on the aarch64 disk images and can be safely removed to prevent any conflicts.

rm /etc/sysconfig/network-scripts/ifcfg-enp1s0

Unable to log in on the KDE disk image after completing Initial-Setup

link to this item - Bugzilla: #1507926

After completing the Initial-Setup utility on the armhfp KDE disk image you will need to install additional packages in order to log in to the desktop. Connect to tty2 and log in as root or ssh to the system from another computer and install 'KDE plasma desktop'.

dnf install plasma-desktop

Root password listed as 'set' in Initial-Setup TUI on AArch64 disk images

link to this item - Bugzilla: #1507940

For security, the root account is 'locked' during the aarch64 disk image creation. As a result, the initial-setup configuration utility incorrectly lists the password for the root account as 'set'. Users should take care to either set the root password or to create a user account with Administrator privileges.

There is no network on the Pine 64 with AArch64 disk images

link to this item

When booting the AArch64 disk images on the Pine 64 you will not have a network connection. To correct this issue create a symlink named 'dtb' pointing to the installed kernel dtb directory (dtb-4.13.9-300.fc27.aarch64) and reboot the system.

cd /boot; ln -sf dtb-4.13.9-300.fc27.aarch64 dtb

Fedora Server issues

Fedora Cloud issues

Fedora Atomic issues

Soas

Red Hat Bugzilla – Bug 1519042 soas starts in journal:

This can be confusing for users

Fix by hitting f1 key then f3 key to get to main menu


Other issues

Hibernation doesn't work from a standard install

link to this item - Bugzilla: #1206936

The systemd-hibernate generator used to handle resume from hibernate functionality expects a resume=/path/to/swap in the kernel args. Anaconda does not add this into /etc/default/grub and the dracut cmdline generator doesn't act in a way the systemd hibernate generator can locate the swap with the resume image.

To work around this, check the devmapper path to the swap via swapon -s command and add it to the GRUB_CMDLINE_LINUX entry in /etc/default/grub, then regenerate the grub.cfg file used:

  • Via grub2-mkconfig:
    • For BIOS systems:
      sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    • For EFI systems:
      sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
  • Via grubby:
    sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)

Booting other UEFI Linux distributions might not work from Fedora bootloader

link to this item - Bugzilla: #1353026

Certain people who have multiple Linux distributions installed (in UEFI mode on GPT disks) report they're not able to boot non-Fedora systems from Fedora bootloader. If this happens to you, please tell us in RHBZ #1353026. The workaround should be to use your UEFI firmware to display a one-time boot menu (often displayed with F8, F10, F11, F12 or Esc) and pick the system you want to boot. That will boot the system directly, without going through Fedora bootloader. If this is not available for you, you can try to select the OS you want to boot in the Fedora bootloader, hit e to edit the boot menu, and replace linux and initrd keywords with linuxefi and initrdefi, then press Ctrl+x or F10 to boot it.

livemedia-creator cannot create images from kickstarts using metalink repositories (including official kickstarts)

link to this item - Bugzilla: #1464843

If you try to use the official livemedia-creator tool to create a live image using a kickstart based on one of the official Fedora kickstarts (from the fedora-kickstarts repository, or the fedora-kickstarts package), you may find that it fails due to anaconda being unable to correctly set up the software source.

This is because the livemedia-creator+anaconda combination does not currently correctly handle kickstarts that specify repositories using metalink URLs. If you're wondering "in that case, how were the official images built?", the answer is that the repository definitions from the kickstart files are actually modified on-the-fly by the Fedora compose system before the images are built (in order to use a local disk repository that's produced as part of the compose process).

To work around this problem for now, modify the repository definition in your flattened kickstart to use a direct URL or a mirrorlist URL before starting your compose.