Tato stránka dokumentuje běžné chyby vyskytující se ve Fedoře 24 a, pokud jsou k dispozici, opravy a řešení těchto problémů. Pokud na této stránce naleznete svůj problém, nereportujte ho, pokud není uvedeno jinak. Tam, kde je to vhodné, je přiložen odkaz na aktuální chybu(y) nareportované v Bugzille.
Poznámky k vydání
Přečtěte si všeobecné oznámení o vydání F24 pro konkrétní informace o změnách ve Fedoře 24 a další obecné informace.
Moje chyba není uvedena
Ne každá chyba je uvedena na této stránce, ale Bugzilla by měla být komplexní databází známých chyb. Tato stránka je výběrem z chyb nejčastěji diskutovaných na našich mailových konferencích a fórech.
Chcete-li zjistit, zda již byla vaše chyba hlášena, můžete prohledat Bugzillu. V případě, že dosud nebyla nahlášena, vás tímto chceme povzbudit k pomoci zlepšit Fedoru pro sebe a ostatní. Průvodce chyb a požadavků na nové funkce byl připraven, aby vám pomohl.
Pokud si myslíte, že by již nahlášenéný problém měl být doplněn na ""tuto"" stránku, protože se s ním běžně setkáváme, můžete:
- Přidat ho sami, pokud máte přístup k wiki. Instrukce pro běžné chyby poskytují návod, jak správně přidat záznam na stránku, ale nejdůležitější je se ujistit, že je uveden záznam o chybě - nebojte se, pokud nebudete mít formátovaní úplně v pořádku, to můžeme vyčistit později.
- Nebo přidejte klíčové slovo CommonBugs do záznamu chyby. Někdo z Kvality týmu zkontroluje problém, aby zjistil, zda by měla být tato chyba uvedena na seznamu běžných chyb. Chcete-li urychlit svůj požadavek, přidejte prosím poznámku do záznamu chyby, která zahrnuje
- shrnutí problému
- jakákoli známá řešení
- posouzení o dopadu na uživatele Fedory
Pro referenci, můžete prohledat Bugzillu s chybami označených jako CommonBugs:
- CommonBugs? (chyby obsahující klíčové slovo CommonBugs, ale ještě nemají odkaz na tuto stránku)
- CommonBugs+ (chyby obsahující klíčové slovo CommonBugs a obsahují odkaz na tuto stránku)
Problémy s instalací
Duální bootování s Windows selže s chybou "přemístění selhalo" na některých systémech UEFI
odkaz na tuto položku - Bugzilla: #1347291
On some hardware, it's not possible to start Windows (possibly even some other OSes) from GRUB boot menu when booting over UEFI (it does not happen in BIOS mode). The message says error: relocation failed. The problem is still being investigated.
As a workaround, you can use your UEFI boot menu (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc) to boot Windows, which should work fine.
Advanced users can download and install grub2-2.02-0.25.fc23 (grub2 from Fedora 23), which should immediately fix the problem. However, when using this solution, the broken version of grub2 from Fedora 24 will be offered to you with every new system update, and you'll need to manually exclude it every time.
Položka Windows chybí v zavaděči systémů grub, kdy jsou systémy instalovány na firmwaru RAID na UEFI systému
odkaz na tuto položku - Bugzilla: #1347273
When Fedora is installed beside Windows on the firmware RAID and on UEFI it could happen that there will be Windows entry missing in grub menu.
This happens only with UEFI. User can use UEFI boot menu as a workaround (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc).
This bug appears just when UEFI and firmware RAID is used. So BIOS installations and normal disks (or with FW RAID turned off) shouldn't be affected.
Instalace Fedory selže na některých RAID sestavách
odkaz na tuto položku - Bugzilla: #1333131 - Bugzilla: #1259953
On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash. If you try to create a RAID array during setup on a system that has an existing RAID configuration using the drives from that previous RAID array, the newly-created one gets produced incorrectly and is unusable (and of course, the one you deleted is no longer there). User can restart and try again on the same selected drives (this time using free space) as workaround.
OS X svazky využívající Apple Core Storage nejsou rozpoznány instalačním programem a jejich zmenšování zničí všechna data
odkaz na tuto položku - Bugzilla: #1033778
The installer appears to support volume shrink for OS X volumes (Apple Core Storage) by offering a Shrink button and sizing slider in Automatic partitioning; and likewise allow numeric resizing in Manual partitioning. However, setting the installer to resize these volumes and proceeding with installation will result in complete data loss of the volume. Resize the volume in OS X's Disk Utility to create free space before proceeding with the installation of Fedora.
Fedora Media Writer nevykazuje žádný postup zápisu na Fedoře 22
odkaz na tuto položku - Bugzilla: #1328462
If you use Fedora Media Writer (formerly liveusb-creator) on Fedora 22 to create a new bootable USB drive, no progress is displayed during the writing process. You need to wait until the dialog says "Finished".
Nastavení LVM na šifrovaných fyzických svazcích je nerozpoznáno po dešifrování
odkaz na tuto položku - Bugzilla: #1348688
Due to the issues with the new LVM DBus API, the installation fails to analyze an existing LVM setup on top of encrypted (LUKS) PVs after unlocking the LUKS device(s).
Aktualizace instalačního obrazu byla zpřístupněna, což řeší tento problém. Pokud ji chcete použít, stiskněte e nebo Tab ⇆ v nabídce zavaděče systému instalace pro úpravu možností zavaděče a přidejte následující: inst.updates=http://vpodzime.fedorapeople.org/1348688_updates.img
This bug doesn't seem to occur with Live images (at least with Workstation Live), only netinst/Server images.
Softwarový RAID (mdraid) u stávajících instalací Fedory nerozpoznán edicí Workstation/Živou
odkaz na tuto položku - Bugzilla: #1225184
Installation from Workstation/Live image does not properly recognize existing Software RAID (mdraid) devices (e.g. from an existing Fedora installation). Those devices are listed as "Unknown" (0 bytes size) and cannot be used in the device selection dialogue which makes it effectively impossible to install Fedora 24 or keep existing data.
This bug exists since Fedora 22 (several Bugzilla reports have been filed for this issue but none has been processed yet).
The Server image does not have this problem and it can be used as a workaround to setup a minimal Server, and then install the "Workstation" package group from network remotely (using dnf). The result is not exactly the same and requires some minor additional manual work afterwards. (If anybody knows easier workarounds, please add to this section.)
Neživá instalace KDE nebo instalace KDE po skončení instalace nainstaluje také Cinnamon
odkaz na tuto položku - Bugzilla: #1349743
Due to some unfortunate interactions between the Fedora package group definitions and the 
libsolvsudo dnf groupinstall kde-desktop-environment or something similar, you will get KDE...and also Cinnamon.
There is no way to work around this at system install time, besides installing from the KDE live image instead. You would just have to remove the unwanted packages manually. If you are trying to install KDE after initial system install and wish to avoid the unnecessary Cinnamon packages, running sudo dnf install @kde-desktop-environment imsettings-qt should avoid the problem.
Problémy s upgradem
Balíčky Rpmfusion blokují aktualizaci Fedory
At the time of release, rpmfusion packages were blocking Fedora upgrades with a message similar to:
Error: Package a52dec-0.7.4-19.fc24.x86_64.rpm is not signed
This is a third-party repository issue outside of Fedora control. You can read more about possible solutions in this blog post. The repository maintainers are supposedly working on signing their repo, so that the issue disappears in the future. As of recently (mid-July) this has been fixed and RPMFusion packages are signed.
Problémy jádra systému
DNF by mohlo odstranit základní balíčky systému, pokud jste v minulosti použili PackageKit (GNOME Software, KDE Apper)
odkaz na tuto položku - Bugzilla: #1259865
There was an unfortunate situation in the past few Fedora releases where PackageKit and DNF didn't work well together. If you installed something via PackageKit (used by GNOME Software or KDE Apper), it didn't mark such packages as "user installed" in the DNF database (which is used to differentiate user-requested packages from other packages installed purely as a dependency, but not explicitly requested by the user). Similarly, if you updated your system using PackageKit (GNOME offline updates, Apper), it erased such "user installed" flags from all updated packages. DNF then tries to remove any unnecessary packages during its next transaction (or when specifically asked using sudo dnf autoremove). This might lead to removing core system packages because DNF no longer sees them as "user installed" and considers them a no-longer-needed dependency. It is also possible that this might happen to you when performing a system upgrade to Fedora 24.
This is now fixed in Fedora 24 (since libhif-0.2.2-3.fc24) and Fedora 23 (since libhif-0.2.2-3.fc23). Future use of PackageKit (GNOME Software, Apper) should be safe. However, if you have ever used these tools in the past, you're strongly advised to fix your "user installed" database before you start using DNF:
- First, make sure your libhif package version is the same as described above or newer:
rpm -q libhif
If not, update it, and check again:
sudo dnf --refresh update libhif
Reboot after update. - Then, mark all your current packages as "user installed" using this command:
rpm -qa --qf '%{NAME}\n' | xargs sudo dnf mark install
Please note that this solution is slightly excessive, because you're going to end up with all your packages considered either system essential or user requested, and none of them is ever going to be removed as a no-longer-needed dependency. However, this is the only way how to be absolutely sure that you're not going to be affected by this issue, at a relatively small cost (some packages might stay on your disk unnecessarily). Power users can tweak this solution according to their needs.
Problémy s GNOME
Offline aktualizace přestane v GNOME fungovat poté, co je nainstalován Google Chrome
odkaz na tuto položku - Bugzilla: #1344643
If you install Google Chrome, it tries but fails to install a GPG key for its repository. This will break "offline update" functionality in GNOME Software (in this mode the updates are installed during a system reboot). Once a new google-chrome update is released, all future updates using GNOME Software will fail (including system updates unrelated to google-chrome, it's enough that the new google-chrome package is in the update set). This is not a problem for DNF, which will ask you to confirm the GPG key during the next google-chrome update.
In order to work around this, you need to confirm the GPG key for the google-chrome repo. You can do it using DNF, once a new google-chrome update is available. Simply update chrome using DNF and confirm the gpg key question:
$ sudo dnf update 'google-chrome*'
Alternatively, you can download the key and import it into RPM database (in this case you don't need to wait until new google-chrome update is available):
$ curl -O 'https://dl.google.com/linux/linux_signing_key.pub' $ sudo rpmkeys --import ./linux_signing_key.pub
After this, offline updates using GNOME Software should start working again.
Změny konfigurace sítě provedené v řídicím centru GNOME se ne vždy aplikují
odkaz na tuto položku - Bugzilla: #1344788
In GNOME settings (control-center), network changes may not take effect for a connection using the Apply button - the configuration is not reloaded. Turn the connection off then back on again to reload the settings.
One of the affected options is "Use this connection only for resources on its network". This can be used for example when someone wants to make wireless connection default and still connect via wired connection for local resources.
Problémy s Plasma (KDE)
Dojde k pádu Plasmy při přepnutí uživatelů ve virtuálních systémech využívajících ovladače QXL
odkaz na tuto položku - Bugzilla: #1293167
If you try to switch between different user accounts in Plasma while running in a virtual machine using the QXL driver, Plasma is likely to crash. This doesn't seem to happen when using a different video driver. It also doesn't affect bare metal machines (because those don't use QXL). The workaround is to use a different video driver in your VM.
Problémy se sítí
Problémy s hardware
Problémy s aplikacemi
Firefox již nepřehrává obsah H264 pomocí gstreamer, nyní využívá ffmpeg
odkaz na tuto položku - Bugzilla: #1331496
Since Firefox 46, it no longer uses gstreamer to play non-free multimedia content (most often represented by H264 video codec), but uses ffmpeg instead. Instead of having gstreamer1-libav, now you need to have ffmpeg-libs installed if you want to be able to play such content in Firefox. Please note that ffmpeg is not distributed by Fedora and you need to obtain it yourself, if you wish to use it.
Dockeru se nepodaří nic spustit, pokud byl někdy použit docker-1.10.3-3
odkaz na tuto položku - Bugzilla: #1322909
There has been reported an issue with docker-1.10.3-3, which results in unusable docker. This issue persists even if docker is updated. Sufficient workaround should be to stop docker, remove directory /var/lib/docker and install newer docker. Users with lvm thin pool must recreate the pool since the removal of /var/lib/docker breaks it. For more, see RHBZ 1322909#c21.
Problémy s ARM
Bananapi: nelze nabootovat do PXE
odkaz na tuto položku - Bugzilla: #1329613
Some people are experiencing a problem with graphical PXE installation on Banana Pi. They are probably running into memory issues when 1G of RAM is not enough. The workaround is to append inst.text to kernel cmdline and proceed with text installation or install the system via VNC.
Problémy s Fedora Serverem
FreeIPA se po upgradu nespustí, pokud byl původně nainstalován ve Fedoře 21 nebo dřív
odkaz na tuto položku - Bugzilla: #1323400
Between Fedora 21 and Fedora 22, FreeIPA was changed from using a file-based store for certificate profiles to a database store. Any FreeIPA server initially deployed under Fedora 21 or earlier would have had the file store, and would need to be migrated to the database store on upgrade to Fedora 22 or later.
Testing indicates that this migration was often not correctly performed on upgrade. With versions of
An update that fixes the upgrade migration process is available. If you have a server which was initially deployed with Fedora 21 or earlier and you have not yet upgraded to Fedora 22 or later, please either wait for the update to be released, or ensure it is included in the upgrade by enabling the updates-testing repository during upgrade or in some other way, to ensure the migration works correctly.
If you already hit this bug during upgrade, updating the package will not fix it. The symptom of this bug is that the pki-tomcatd@pki-tomcat.service service fails to start during FreeIPA initialization. If you run ipactl -d, you will see it repeatedly attempt to connection to https://(serverhostname):8443/ca/admin/ca/getStatus for some time, failing each time, then eventually time out.
If you are affected by the bug, first apply the update: run sudo dnf install yum, then sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-4d226a5f7e. Then, edit the file /etc/pki/pki-tomcat/ca/CS.cfg and replace the text subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem with subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem. Finally, run sudo ipa-server-upgrade. This should correctly perform the migration, and FreeIPA should subsequently start correctly.
Problémy s Fedora Cloudem
Další problémy
Režim hibernace ze standardní instalace nefunguje
odkaz na tuto položku - 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)