From Fedora Project Wiki

m (Added additional information about the grub2-install command that is in the bug but not the workaround instructions)
(remove 1674045 (fixed in Final))
Line 28: Line 28:
  
 
And then execute the {{command|grub2-install /dev/X}} command (where X is the boot device, i.e sda) to update the GRUB core and the modules to the latest version installed by the {{package|grub2-pc-modules}} package.
 
And then execute the {{command|grub2-install /dev/X}} command (where X is the boot device, i.e sda) to update the GRUB core and the modules to the latest version installed by the {{package|grub2-pc-modules}} package.
 
{{Common bugs issue|upgrade-29-hang|Upgrade from Fedora 29 hangs at end of upgrade process, showing "Upgrade complete! Cleaning up and rebooting..."|1674045}}
 
 
If you upgrade from Fedora 29 to Fedora 30, it is likely that after the upgrade completes, instead of rebooting to Fedora 30 automatically, the system will stop at a screen saying "Upgrade complete! Cleaning up and rebooting..."
 
 
If this happens, the upgrade has completed successfully and it is safe to simply reset the system. Fedora 30 should boot automatically and work correctly.
 
  
 
{{Common bugs issue|upgrade-module-platform|Upgrade fails due to dependency issues related to modules|1688462}}
 
{{Common bugs issue|upgrade-module-platform|Upgrade fails due to dependency issues related to modules|1688462}}

Revision as of 16:49, 29 April 2019

This page documents common bugs in Fedora 30 and, if available, fixes or workarounds for these problems. If you find your problem in this page, do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.

Note.png
Pre-release version
Fedora 30 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 30 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).

Release Notes

Read the F30_Beta_release_announcement for specific information about changes in Fedora 30 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
    1. a summary of the problem
    2. any known workarounds
    3. 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)

Upgrade issues

GRUB boot menu is not populated after an upgrade

link to this item - Bugzilla: #1652806

If you have a legacy BIOS installation, it is possible that after the upgrade process the GRUB bootloader will not be able to populate the boot menu and just display the GRUB prompt. This happens on systems that were originally installed using Fedora 20 or older.

This happens because the GRUB core and modules in legacy BIOS are never updated unless the grub2-install command is executed. Because in Fedora 30 the default GRUB configuration was changed to use BootLoaderSpec-style files by default, the blscfg module is updated when the Package-x-generic-16.pnggrub2-pc-modules package is upgraded. But this module only is compatible with older versions of the GRUB core up to Fedora 21.

So if you have an installation that has been updated since Fedora 20 or before, it is recommended to execute the grub2-install command before doing a system upgrade. This should not affect legacy BIOS installations since Fedora 21 and also UEFI installs since in the UEFI case the GRUB core is updated and the modules are built-in.

If you hit this issue, the old GRUB configuration is stored in /boot/grub2/grub.cfg.rpmsave. So the system can be recovered by executing the following from the GRUB prompt:

grub> configfile /grub2/grub.cfg.rpmsave

And then execute the grub2-install /dev/X command (where X is the boot device, i.e sda) to update the GRUB core and the modules to the latest version installed by the Package-x-generic-16.pnggrub2-pc-modules package.

Upgrade fails due to dependency issues related to modules

link to this item - Bugzilla: #1688462

It is quite common when upgrading to Fedora 30 Beta (especially from Fedora 29, less so from Fedora 28) to encounter dependency issues related to packages from modules. The errors will look something like this:

Problem 1: conflicting requests
  - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64

This occurs because a specific item of configuration related to how the module system is implemented is not known by dnf. To avoid the problem, you must include an argument which tells dnf about this in the upgrade commands. Where previously you would have run just:

sudo dnf system-upgrade download --refresh --releasever=30

You must now run:

sudo dnf system-upgrade download --refresh --releasever=30 --setopt=module_platform_id=platform:f30

This should allow the upgrade to proceed correctly (also note the other entries in this section). We intend to improve things before the release of Fedora 30 Final such that explicitly passing this option will no longer be necessary, but for now please use it! Especially please do not use the --allowerasing argument to work around this problem: it will lead to packages being unnecessarily removed.

Conflicts between fedora-release packages on upgrade

link to this item - Bugzilla: #1649921

When attempting to upgrade to Fedora 30, you may see conflicts between multiple Package-x-generic-16.pngfedora-release subpackages. If this happens, we recommend you remove one of the conflicting packages to unblock the upgrade. Leave installed the package that most closely matches how you want the system to identify itself - the one that most closely matches your primary use of the system.

Workstation issues

'Basic graphics' mode will often fail on Workstation

link to this item - Bugzilla: #1691909 - Bugzilla: #1683197

Due to at least two different problems, trying to boot a Fedora 30 Workstation live image or installed system using the 'basic graphics' option will often fail; when doing a BIOS native boot it will probably always fail, with a UEFI native boot it may work.

Fortunately this option is less commonly needed than it used to be. If you have a system on which it is necessary, you may need to install a different Fedora edition until fixes or workarounds for the problems are available.

Top icon often disappears from dash

link to this item - Bugzilla: #1690429

A bug in GNOME in Fedora 30 Beta means that the icon that should appear at the top of the 'dash' in the overview (the panel of icons for running and/or favorite applications, on the left hand side) does not appear. Only a small horizontal bar will appear - you can interact with this bar as if it were the icon. (Technically, the icon is present, but has been assigned a height of 0, which is why it is not shown). The GNOME developers are working to fix this issue, and we will provide the fix as soon as it is available.

Other software issues

Conflicts between fedora-release packages when installing package groups

link to this item - Bugzilla: #1649921

When trying to install package groups, you may run into a conflict between different Package-x-generic-16.pngfedora-release subpackages. This can happen for example if you install the server-product package group or several of the desktop groups after initial system installation. This error would look something like this:

Error: 
 Problem: problem with installed package fedora-release-workstation-30-0.24.noarch
  - package fedora-release-workstation-30-0.24.noarch conflicts with system-release provided by fedora-release-matecompiz-30-0.25.noarch
  - package fedora-release-matecompiz-30-0.25.noarch conflicts with system-release provided by fedora-release-workstation-30-0.24.noarch
  - package fedora-release-workstation-30-0.25.noarch conflicts with system-release provided by fedora-release-matecompiz-30-0.25.noarch
  - package fedora-release-matecompiz-30-0.25.noarch conflicts with system-release provided by fedora-release-workstation-30-0.25.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

But with the package names depending on the package you already have installed, and the package coming in with the group you are trying to install.

You have four choices for how to resolve this issue. In each case we use the package names from the example above; obviously you should modify these to match the package names that are actually involved in the conflict on your system.

  • RECOMMENDED Pass --excludepkg fedora-release-matecompiz to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will retain your system's "identity" to what it was from initial installation.
  • Pass --excludepkg fedora-release-workstation to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will change your system identity such that it will now report as a MATE Compiz system rather than a Workstation one.
  • Pass --skip-broken. This is similar to passing --excludepkg fedora-release-matecompiz except that it will also skip any other potential conflicts which may result in an incomplete group install. Make sure to carefully examine the transaction summary before proceeding. This option will retain your system's "identity" to what it was from initial installation.
  • Pass --allowerasing. This is similar to passing --excludepkg fedora-release-workstation except that it may also result in replacing other packages on your system unexpectedly. Make sure to carefully examine the transaction summary before proceeding. This option will change your system identity such that it will now report as a MATE Compiz system rather than a Workstation one.