Received the following message after running “dnf system-upgrade download --refresh --releasever=31” : Error: Transaction test error:
file /usr/bin/pytest from install of python3-pytest-4.6.11-1.fc31.noarch conflicts with file from package python-logilab-common-0.63.2-6.fc25.noarch
All the files seem to be downloaded, but I don’t know if it safe to continue with "dnf system-upgrade reboot without first taking some kind of other action.
Any help appreciated.
Thanks, Edward
The python-logilab package is built for Fedora 25, and is not part of the Fedora 30 package set. I can’t find a package called “python-logilab” at all, so perhaps that’s not from Fedora at all? It should not be providing ‘/usr/bin/pytest’, so that’s a packaging bug there. Please contact the provider of that package and request them to fix their rpm.
To proceed with the upgrade, you have to remove one of the conflicting packages.
python3-pytest (not suggested, since this will remove other Fedora python packages also)python-logilab-* : suggested, since these are not from the Fedora repositories, and seem to have packaging bugs.I see that the logilab packages are available on pypi: https://pypi.org/search/?q=logilab
So, perhaps you’re better off installing them in a python virtual environment. That way, you’ll keep these separate from the Fedora system packages, and you won’t see these conflicts.
Why not Fedora 32? … and 33 is by the corner
If it didn’t come with Fedora how can find out what application is responsible for it? If I can find that out I can remove the application and then reinstall after upgrade.
dnf info python-logilab-common
that usually prints enough to identify sources
This is what I can find:
So, at some point, you’ve installed “logilab” tools, and python-logilab-common seems to be a dependency of these.
Please check what repositories you have enabled:
sudo dnf repolist
It’ll be best to disable/remove any repositories other than Fedora, RPMFusion, and COPRs (but you should check COPRs), and then:
sudo dnf list --extras
will tell you about packages that aren’t from any repository
The cmd “dnf python-logilab-common” show the repository to be @System and From repo to be @commandline. Don’t know what exactly that means. Looking at Logilab.org I can’t determine any of the apps listed that I may have installed. The main applications I use are all main stream apps from Fedora (Gramps, LibreOffice, Evolution, Tor Browser, SimpleScan, Shotwell, Scribus, Okular, Digikam, Emacs). Don’t think it will affect any of these. When I do dnf remove python-logilab-common it doesn’t list any dependencies (before I answer Y or N ) so I guess it is just a stand alone. Can’t imagine how it got to be here.
At this point I’m going to remove the python-logilab-common and proceed with the upgrade
The dnf list --extras list 72 packages ranging from fc22 - fc29. I don’t know if this is normal but that about corresponds with when I started using the automatic update process instead of a clean install from DVD. The update process went quite smooth up until the last 3 updates and they have all been bears with various applications or packages that conflicted with the upgrade. After various searches I was able to find solutions to those. It may be time to do a clean install and start over building every thing again. Lots of work to keep this thing working which explains why I don’t stay current with the new releases.
The repositories I have enabled are:
SU: # dnf repolist
repo id repo name
Dropbox Dropbox Repository
adobe-linux-x86_64 Adobe Systems Incorporated
fedora Fedora 30 - x86_64
fedora-modular Fedora Modular 30 - x86_64
google-chrome google-chrome - \x86_64
rpmfusion-free RPM Fusion for Fedora 30 - Free
rpmfusion-free-updates RPM Fusion for Fedora 30 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 30 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 30 - Nonfree - Updates
updates Fedora 30 - x86_64 - Updates
updates-modular Fedora Modular 30 - x86_64 - Updates
You shouldn’t have any packages from previous releases. Consider running these steps each time you upgrade:
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-clean-up-old-packages
I’ve also been using upgrades for a while. If your packages only come from the fedora/rpmfusion repos, you shouldn’t have these leftover packages.
Your repos look OK, so it should be go through the extra packages and remove ones that you do not need. Also look at dnf autoremove perhaps.
OK, I removed the package python-logilab-common and ran the upgrade to F 31, but upon reboot the system comes up using the last F30 kernel (ie.:
SU: # uname -a
Linux cyclops 5.6.13-100.fc30.x86_64 #1 SMP Fri May 15 00:36:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I’ve seen this before after new kernel install the grub2 menu doesn’t have the new kernel as the top item so it boots to the old kernel… In the past I’ve always just ran “grub2-mkconfig -o /boot/grub2/grub.cfg” and the new kernel is then shown as the top item in the grub2 menu and the system boots to it. Now the grub2-mkconfig gives an error on the last line.
SU: # grub2-mkconfig -o /boot/grub2 grub.cfg
Generating grub configuration file …
Found linux image: /boot/vmlinuz-5.8.8-100.fc31.x86_64
Found initrd image: /boot/initramfs-5.8.8-100.fc31.x86_64.img
Found linux image: /boot/vmlinuz-5.6.13-100.fc30.x86_64
Found initrd image: /boot/initramfs-5.6.13-100.fc30.x86_64.img
Found linux image: /boot/vmlinuz-5.6.11-100.fc30.x86_64
Found initrd image: /boot/initramfs-5.6.11-100.fc30.x86_64.img
Found linux image: /boot/vmlinuz-3.17.4-301.fc21.x86_64
Found initrd image: /boot/initramfs-3.17.4-301.fc21.x86_64.img
Found linux image: /boot/vmlinuz-fedup
Found initrd image: /boot/initramfs-fedup.img
Found linux image: /boot/vmlinuz-0-rescue-8665c3a532144f44a42cff860f83c59d
Found initrd image: /boot/initramfs-0-rescue-8665c3a532144f44a42cff860f83c59d.img
Found linux image: /boot/vmlinuz-0-rescue-2d41a53cd4824c579a09c1bc49aadcd5
Found initrd image: /boot/initramfs-0-rescue-2d41a53cd4824c579a09c1bc49aadcd5.img
Found memtest image: /boot/elf-memtest86±5.01
/usr/sbin/grub2-mkconfig: line 320: /boot/grub2: Is a directory
[root@cyclops: ~ ]
It does show the f31 kernel as the top item but on the menu that comes up it is still mid way down the list and and I think the error at the end of the output is causing it now to work properly.
Any ideas or help would be appreciated. The grub menu goes away quickly and if I’m not paying close enough attention I can’t select the proper kernel…not a problem if it is the top item.
If the new kernel works fine, you can simply remove the old ones.
But if it doesn’t how do I boot to an older kernel? Should you not still be able to run grub2-mkconfig without error? On second look the f31 kernel doesn’t show up at all in the menu.
This is wrong.
It should be like this:
sudo grub2-mkconfig -o /etc/grub2$(test -d /sys/firmware/efi && echo -efi).cfg
OK, is that new in f31?
Sorry guys, I see now that I left out a / in the command, instead of grub2mkconfig -o /boot/grub2 grub.cfg it should have been grub2mkconfig -o /boot/grub2/grub2.cfg. That’s the source of my command error.
Please except my humble apology.
I assume that if your command
grub2-mkconfig -o /boot/grub2/grub.cfg worked and you are now able to boot properly that your system must be using MBR to boot.
If you are using UEFI then the command should have been
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg I also noted that you said you removed the offending package then did the upgrade, but did not mention that you had verified everything was OK by repeating the download step without errors. I wonder if that may have left something wanting as far as packages being downloaded before you did the final reboot step to complete the upgrade.
Also take care of the --extras packages, or you may have the same problem in 6 months time again. See:
sudo dnf distro-sync
sudo dnf distro-sync --allowerasing
can be very useful.
Note that F31 is going to become EoL in about 2 months, so you should consider upgrading to F32.
Yes, the command worked and I’m booting the way I would like. Thanks for the help and sorry for my overlooking my own mistake. Also I did the dnf system-upgrade clean and then repeated the dnf system-upgrrade download step and the transaction check was clean so I went ahead with dnf system-upgrade reboot.