No edit summary |
(deleted "The Raspberry Pi 3 serial console does not work with initial-setup tui" as it is now solved) |
||
| Line 173: | Line 173: | ||
== ARM issues == | == ARM issues == | ||
{{Common bugs issue|aarch64-upgrade-issue|Upgrading from previous releases on aarch64 requires EFI boot menu update|1497854}} | {{Common bugs issue|aarch64-upgrade-issue|Upgrading from previous releases on aarch64 requires EFI boot menu update|1497854}} | ||
Revision as of 09:02, 16 October 2017
This page documents common bugs in Fedora 27 and, if available, fixes or workarounds for these problems. If you find your problem on this page, please do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
Release Notes
Read the Fedora 27 release announcement and the Fedora 27 release notes for specific information about changes in Fedora 27 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Installation issues
Switching keyboard layout with key combo does not work in Wayland
link to this item - Bugzilla: #1389959
If you're running Workstation Live install media and configure multiple languages in the installer, you won't be able to switch between them using the standard system shortcut (typically ⊞ Win+Space or Alt+⇧ Shift). However, you can still click on the language indicator in the installer with the mouse and that will switch the languages.
This does not affect other install media (KDE Live, DVD and netinst images).
macOS can't be booted from grub
link to this item - Bugzilla: #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 ⌥ Opt (or right Alt) key when starting the computer, which will show you UEFI boot menu, and select macOS partition to boot from there.
Installer on several live images does not offer iSCSI support
link to this item - Bugzilla: #1395620 - Bugzilla: #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 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.
Upgrade issues
gnome-software doesn't show F25->F27 upgrade
link to this item - Bugzilla: #1494061
GNOME Software doesn't offer the upgrade from Fedora 25 to Fedora 27. Possible workarounds are either to upgrade from Fedora 25 to Fedora 26 and then to Fedora 27 or to upgrade with DNF system upgrade.
dnf system-upgrade fails with "no package matched" when using --enablerepo
link to this item - Bugzilla: #1490832
Upgrading with DNF system upgrade fails when using --enablerepo argument during package download. The workaround is to permanently enable all required repositories before starting the upgrade.
system-upgrade fails to connect to online mirrors during upgrade when caches are missing
link to this item - Bugzilla: #1492036
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-70a8618065Upgrade with dnf fails in certain conditions. After the reboot for upgrade the system tries to upgrade, fails and reboots back to Fedora 26. The system isn't changed and is working.
The problem is in missing dnf's caches for Fedora 26. You can workaround this by running
$ sudo dnf makecache
just before restarting to upgrade
$ sudo dnf system-upgrade reboot
Frozen gray screen during logging in after upgrade
link to this item - Bugzilla: #1394755
This happens if you have 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.
Every second login attempt fails in certain configurations
link to this item - 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 org.gnome.SessionManager auto-save-session gsettings value being true instead of default false. You can see your current value like this:
$ gsettings get org.gnome.SessionManager auto-save-session
and change it like this:
$ gsettings set org.gnome.SessionManager auto-save-session false
If you encounter this bug, you may see a crash notification that traces back to bug #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 #1384508 bug report. See the entry for that crash for more details. GNOME bug #775463 is the bug report for this specific auto-save-session crash case.
GRUB update might fail if /boot is on XFS
link to this item - Bugzilla: #1227736
If you use XFS filesystem on /boot 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.
In order to prevent this issue, you might try to disable plymouth (by removing rhgb kernel boot option) during the upgrade or uninstall it prior the upgrade (these workarounds were not tested).
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 xfs_repair to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.
Core system issues
systemd times out when waiting for password to unlock disks, falling to dracut shell
link to this item - Bugzilla: #1495635
System will end in a rescue shell if you have an encrypted system and don't supply the password to unlock disks in 90 seconds. If this happens to you, simply reboot and this time provide the password quicker than in 90 seconds. A fix is in progress for this.
Initramfs is not updated when /boot/<machine-id> exists
link to this item - Bugzilla: #1475565
For new Fedora 27 installations, there's a directory /boot/<machine-id> present (looking as a random sequence of numbers and letters). However, when this directory is present, any attempt to update the initramfs (i.e. when you call dracut -f manually, or when a tool calls it after updating e.g. plymouth theme or language/keymap) does not update the correct file, but instead generates a new file in a different location (which is not read on boot). New kernel installations doesn't seem to trigger this bug, or at least not always.
The current workaround is to specify the output image file on the dracut command line (if updating the image yourself), or moving the newly created image from the incorrect location /boot/<machine-id>/$(uname -r)/initrd to the correct one /boot/initramfs-$(uname -r).img (when some tool updates it). You might also fix this by removing /boot/<machine-id> directory, however it's unclear whether this is a recommended approach.
GNOME issues
Wayland issues
Wayland is the replacement for the legacy 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:
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.
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):
Printers are missing in GNOME dialogs
link to this item - Bugzilla: #1484916
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-bbb629b3aeDue to a bug in CUPS software, printers don't show up in GNOME dialogs. There's an update submitted which should fix this.
GNOME flickers heavily when running in a VM with QXL graphics driver
link to this item - Bugzilla: #1491320
When running GNOME in qemu-based virtual machines and using the QXL graphics driver, the screen flickers heavily (to black screen and back) and your mouse cursor disappears. This is a regression in kernel when dealing with QXL driver and a Wayland session.
The current workaround is to a) change graphics driver to virtio in virt-manager (in VM properties), b) use Xorg session (but the login screen will still flicker), or c) use old kernel (4.11 or early 4.12).
Running graphical apps with root privileges (e.g. gparted) does not work on 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
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
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
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.
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
Spurious events from touchpad when scrolling (using two fingers)
link to this item - Bugzilla: #1482640
On recent kernels, you might see spurious events generated by touchpad when you use two fingers simultaneously, usually when scrolling. The extra events manifest as extra middle or right button clicks, often in a very rapid succession. That often breaks the scrolling event.
A fix is being worked on. As a temporary workaround, disabling "tap to click" should avoid this problem (but of course you'll need to use physical buttons to click then).
Application issues
Kerberos might be broken in certain cases
link to this item - Bugzilla: #1494843
Kerberos does not work in certain configurations on Fedora 27. If you're affected, commenting out contents of /etc/krb5.conf.d/kcm_default_ccache might help you.
ARM issues
link to this item - Bugzilla: #1497854
When upgrading from a previous Fedora release to Fedora 27 Beta, the system will fail to automatically boot due to a name change of shim- from shim.efi to shimaa64.efi. To boot the system, use a UEFI shell to manually select the correct shimaa64.efi and boot. Once booted, update the boot menu with efibootmgr.
Fedora Server issues
Fedora Cloud issues
Fedora Atomic issues
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
- For BIOS systems:
- 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
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.