Trouble updating from fc36 to fc38

Thank you for your message, I have run the command
% dnf repolist
repo id repo name
code Visual Studio Code
copr:copr.fedorainfracloud.org:neteler:remarkable Copr repo for remarkable owned by neteler
copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek
dell-system-update_dependent dell-system-update_dependent
dell-system-update_independent dell-system-update_independent
fedora Fedora 36 - x86_64
fedora-cisco-openh264 Fedora 36 openh264 (From Cisco) - x86_64
fedora-modular Fedora Modular 36 - x86_64
fedora-multimedia negativo17 - Multimedia
home_moritzmolch_gencfsm Gnome Encfs Manager (15.4)
mysql-connectors-community MySQL Connectors Community
mysql-tools-community MySQL Tools Community
mysql80-community MySQL 8.0 Community Server
rpmfusion-nonfree-steam RPM Fusion for Fedora 36 - Nonfree - Steam
skype-stable skype (stable)
teams teams
updates Fedora 36 - x86_64 - Updates
updates-modular Fedora Modular 36 - x86_64 - Updates
virtualbox Fedora 36 - x86_64 - VirtualBox

which shows fedora 36 which is wrong as I am running kernel
% uname -a
Linux jazz6 6.2.14-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 1 00:55:28 UTC 2023 x86_64 GNU/Linux

So clearly something is out of sync. Do you know where $releasever is read from? Why when running dnf repolist do I get 36 instead of 38 repos?

Otherwise I am not sure to understand “remove the conflicting packages” as clearly these packages are not installed anyway as I wrote and it looks like the rpm database has been replaced by an older state.

Many thanks,
Patrick

dnf download fedora-release-{common,{identity-,}workstation} --releasever=38
sudo rpm --nodeps -e fedora-release-{common,{identity-,}workstation}
sudo rpm --force --nodeps -i fedora-release-{common,{identity-,}workstation}-*.rpm

Thank you again for your prompt response, I highly appreciate!
I downloaded the three fedora-release files with dnf download

fedora-release-common-38-35.noarch.rpm
fedora-release-identity-workstation-38-35.noarch.rpm
fedora-release-workstation-38-35.noarch.rpm

I looked at the content with rpm -ql and checked the files that are installed
% rpm -ql fedora-release-common-38-35.noarch.rpm
warning: fedora-release-common-38-35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
/etc/fedora-release
/etc/issue
/etc/issue.d
/etc/issue.net
/etc/os-release
/etc/redhat-release
/etc/swid
/etc/swid/swidtags.d
/etc/swid/swidtags.d/fedoraproject.org
/etc/system-release
/etc/system-release-cpe
/usr/lib/fedora-release
/usr/lib/issue
/usr/lib/issue.net
/usr/lib/rpm/macros.d/macros.dist
/usr/lib/swidtag/fedoraproject.org
/usr/lib/swidtag/fedoraproject.org/org.fedoraproject.Fedora-38.swidtag
/usr/lib/system-release-cpe
/usr/lib/systemd/system-preset
/usr/lib/systemd/system-preset/85-display-manager.preset
/usr/lib/systemd/system-preset/90-default.preset
/usr/lib/systemd/system-preset/99-default-disable.preset
/usr/lib/systemd/user-preset
/usr/lib/systemd/user-preset/90-default-user.preset
/usr/lib/systemd/user-preset/99-default-disable.preset
/usr/share/licenses/fedora-release-common
/usr/share/licenses/fedora-release-common/Fedora-Legal-README.txt
/usr/share/licenses/fedora-release-common/LICENSE

and could check that files like /etc/fedora-release, /etc/os-release, /etc/redhat-release and others all contain version 38 so clearly the fedora-release-* files for version 38 are installed. Isn’t $releasever used by dnf with /etc/yum.d/fedora.repo read from these files or am I missing something?
Still I get the following when running
% rpm -qf /etc/os-release
fedora-release-common-36-20.noarch
Wouldn’t be a way to check the history of the rpm database forcing a erasing and reinstall (rpm -e then rpm -i)?
Many thanks
Patrick

Check the output:

rpm -q -a fedora-release\*
rpm -q -f $(readlink -f /etc/os-release)

Here we go
% rpm -q -a fedora-release*
fedora-release-identity-workstation-36-20.noarch
fedora-release-workstation-36-20.noarch
fedora-release-common-36-20.noarch
error: Verifying a signature using certificate 9E02B8BC00D3DF2B01C3C013D1F3DBBF95FAD414 (home:moritzmolch OBS Project home:moritzmolch@build.opensuse.org):

  1. Certificiate D1F3DBBF95FAD414 invalid: certificate is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
  2. Key D1F3DBBF95FAD414 invalid: key is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
    % rpm -q -f $(readlink -f /etc/os-release)
    fedora-release-identity-workstation-36-20.noarch

So clearly no 38 version registered in rpm database even though the files are only version 38 files.

I have also tried to run the command
% rpm -qa --last | less
error: Verifying a signature using certificate 9E02B8BC00D3DF2B01C3C013D1F3DBBF95FAD414 (home:moritzmolch OBS Project home:moritzmolch@build.opensuse.org):

  1. Certificiate D1F3DBBF95FAD414 invalid: certificate is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
  2. Key D1F3DBBF95FAD414 invalid: key is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
    kmod-VirtualBox-6.0.8-200.fc36.x86_64-7.0.2-1.fc36.x86_64 Mon 21 Nov 2022 13:08:05 GMT
    VirtualBox-server-7.0.2-1.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    VirtualBox-7.0.2-1.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    podman-plugins-4.3.1-1.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    podman-4.3.1-1.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    pipewire-utils-0.3.60-5.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    pipewire-pulseaudio-0.3.60-5.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT
    pipewire-jack-audio-connection-kit-0.3.60-5.fc36.x86_64 Mon 21 Nov 2022 13:07:58 GMT

It looks like all the rpm transactions after 21 Nov 2022 have disappeared which is what I suspected, the database is not up to date. Is there a way to check whether there is a backup of a more recent version somewhere? Would that be an idea to try rebuilding the rpm database using rpm --rebuilddb?
I just looked at some notes I had and I just looked at the content of /var/lib/rpm and indeed the file is from Nov 21
ll /var/lib/rpm
total 255968
-rw-r–r–. 1 root root 0 May 4 16:31 .migratedb
-rw-r–r–. 1 root root 262078464 Nov 21 13:08 rpmdb.sqlite
-rw-r–r–. 1 root root 32768 May 5 16:26 rpmdb.sqlite-shm
-rw-r–r–. 1 root root 0 Nov 21 13:08 rpmdb.sqlite-wal
-rw-r–r–. 1 root root 0 Oct 28 2022 .rpm.lock
So clearly the rpm database is not up-to-date :frowning:
Patrick

Try this way, assuming the relevant RPMs are already downloaded:

sudo rpm --rebuilddb
sudo rpm --nodeps -e fedora-release-workstation
sudo rpm --nodeps -e fedora-release-identity-workstation
sudo rpm --nodeps -e fedora-release-common
sudo rpm --force --nodeps -i fedora-release-common-38-*.noarch.rpm
sudo rpm --force --nodeps -i fedora-release-identity-workstation-38-*.noarch.rpm
sudo rpm --force --nodeps -i fedora-release-workstation-38-*.noarch.rpm
sudo ln -f -r -s /usr/lib/os-release /etc
rpm -q -a fedora-release\*
rpm -V -a fedora-release\*

Is it really safe to do a rpm --rebuilddb? Will rpm be able to see that my rpms’ are f38 and not f36?
I have looked for some information regarding rpm --rebuilddb and it looks like the directory /var/lib/rpm/ should contain a file Packages?
Many thanks
Patrick

You can back the RPM database before rebuilding.
The database format was changed in Fedora 33.

Thank you , I have now rebuild the database without any issue but it didn’t change anything.
I still have the old rpm database from 21 Nov 2022 and running dnf upgrade --refresh still point to version 36.
I haven’t run the other rpm -e amd rpm -i but I would like to understand what you expect from these commands. Do you think it will help when runnung dnf upgrade --refresh to point to version 38?
Many thanks,

What is the output when running the above commands?

[patrick@jazz6 ~]$ sudo rpm --rebuilddb
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-workstation
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-identity-workstation
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-common
warning: file org.fedoraproject.Fedora-36.swidtag: remove failed: No such file or directory
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-common-38-.noarch.rpm
warning: fedora-release-common-38-35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-identity-workstation-38-
.noarch.rpm
warning: fedora-release-identity-workstation-38-35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-workstation-38-*.noarch.rpm
warning: fedora-release-workstation-38-35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
[patrick@jazz6 ~]$ sudo ln -f -r -s /usr/lib/os-release /etc
[patrick@jazz6 ~]$ rpm -q -a fedora-release*
error: Verifying a signature using certificate 9E02B8BC00D3DF2B01C3C013D1F3DBBF95FAD414 (home:moritzmolch OBS Project home:moritzmolch@build.opensuse.org):

  1. Certificiate D1F3DBBF95FAD414 invalid: certificate is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
  2. Key D1F3DBBF95FAD414 invalid: key is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
    fedora-release-common-38-35.noarch
    fedora-release-identity-workstation-38-35.noarch
    fedora-release-workstation-38-35.noarch
    [patrick@jazz6 ~]$ rpm -V -a fedora-release*
    error: Verifying a signature using certificate 9E02B8BC00D3DF2B01C3C013D1F3DBBF95FAD414 (home:moritzmolch OBS Project home:moritzmolch@build.opensuse.org):
  3. Certificiate D1F3DBBF95FAD414 invalid: certificate is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
  4. Key D1F3DBBF95FAD414 invalid: key is not alive
    because: The primary key is not live
    because: Expired on 2019-12-21T03:49:18Z
    Unsatisfied dependencies for fedora-release-common-38-35.noarch:
    fedora-repos(38) is needed by (installed) fedora-release-common-38-35.noarch

I have try to run dnf upgrade --refresh and now it recognised version 38. I haven’t run it yet.
Is there a way I could attach the logfile of the command
but I attach the output of sudo dnf upgrade --refresh | & tee dnf-upgrade–refresh.log
What would be the best way to proceed? Using this command or dnf distro-sync or anything else?
Many thanks

Or shall I update first the fedora-repos
$ rpm -qa | grep fedora-repos
fedora-repos-36-4.noarch
fedora-repos-modular-36-4.noarch

You can import the missing GPG key like this:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-38-$(arch)
sudo rpm --import /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary

List the installed GPG keys and remove the expired one:

rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n" gpg-pubkey | sort -k 2
sudo rpm -e gpg-pubkey-xxxxxxxx-xxxxxxxx

Then try again the above commands to make sure they run without error.

The two import commands run sucessfully
There was only one command matching the string moritz
% rpm -q --qf “%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n” gpg-pubkey | sort -k 2|grep moritz
gpg-pubkey-95fad414-59dee63e home:moritzmolch OBS Project home:moritzmolch@build.opensuse.org public key
so I removed it sucessfully
% sudo rpm -e gpg-pubkey-95fad414-59dee63e
Then I rerun the commands, as you can see there is still warning
[patrick@jazz6 ~]$ sudo rpm --rebuilddb
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-workstation
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-identity-workstation
[patrick@jazz6 ~]$ sudo rpm --nodeps -e fedora-release-common
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-common-38-.noarch.rpm
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-identity-workstation-38-
.noarch.rpm
[patrick@jazz6 ~]$ sudo rpm --force --nodeps -i fedora-release-workstation-38-*.noarch.rpm
[patrick@jazz6 ~]$ sudo ln -f -r -s /usr/lib/os-release /etc
[patrick@jazz6 ~]$ rpm -q -a fedora-release*
fedora-release-common-38-35.noarch
fedora-release-identity-workstation-38-35.noarch
fedora-release-workstation-38-35.noarch
[patrick@jazz6 ~]$ rpm -V -a fedora-release*
Unsatisfied dependencies for fedora-release-common-38-35.noarch:
fedora-repos(38) is needed by (installed) fedora-release-common-38-35.noarch

I also noticed that the distro-sync would not work
sudo dnf distro-sync
Fedora 38 - x86_64 - VirtualBox 444 B/s | 819 B 00:01
Fedora 38 - x86_64 - VirtualBox 2.2 kB/s | 1.7 kB 00:00
Fedora 38 - x86_64 - VirtualBox 12 kB/s | 819 B 00:00
Error: Failed to download metadata for repo ‘virtualbox’: repomd.xml GPG signature verification error: Bad GPG signature
Ignoring repositories: virtualbox
Last metadata expiration check: 0:09:48 ago on Sat 06 May 2023 14:03:49 BST.
Error:
Problem: package nautilus-dropbox-1:2020.03.04-3.fc35.x86_64 requires libnautilus-extension.so.1()(64bit), but none of the providers can be installed

  • nautilus-extensions-42.2-1.fc36.x86_64 does not belong to a distupgrade repository
  • problem with installed package nautilus-dropbox-1:2020.03.04-3.fc35.x86_64
    (try to add ‘–skip-broken’ to skip uninstallable packages)
    while the dnf update --refresh would seem to work. I have the log files of the output but I am not sure whether it is possible to share in these discussions.
    I also have the log of the original command I run to upgrade
    sudo dnf system-upgrade download --disablerepo=rpmfusion* --allowerasing --releasever=38 | & tee fc38.log

Import the new GPG key and temporarily remove the conflicting packages:

sudo rpm --import https://www.virtualbox.org/download/oracle_vbox_2016.asc
sudo rpm --nodeps -e nautilus-extensions
sudo rpm --nodeps -e nautilus-dropbox

You can post the upgrade log to paste.centos.org or cpaste.org.

I have imported the new GPG key for virtualbox and removed the conflicting packages which I actually didn’t have when I upgraded as you can see in the log file I created just before doing the upgrade luckily! (sudo dnf list installed |& tee jazz6-dnf-installed.tx)
% grep dropbox Dropbox/jazz6-dnf-installed.txt
dropbox.noarch 1:2020.03.04-3.fc35 @rpmfusion-nonfree

This is very neat, I didn’t know about these tools!
Here are the links for
dnf list installed version 36 prior to update https://paste.centos.org/view/a4f791cb
dnf system-upgrade download --disablerepo=rpmfusion* --allowerasing --releasever=38 https://paste.centos.org/view/3a6ded25
dnf distro-sync https://paste.centos.org/view/e951d16a
dnf upgrade --refresh https://paste.centos.org/view/0643c8d5
As you can see these updates do not provide as many packages as the system-upgrade since the current rpm database is not up-to-date and since 21 Nov 2022 I have added packages (texlive and others)…
Do you think there would be a way to use automatically the log of the system-upgrade to reinstall the ones missing in the distro-sync or upgrade?
Many thanks for your help! I learn a lot!

You can start with system-upgrade and perform distro-sync after upgrading.
All DNF transactions will be logged and can be inspected later.
Also update the GPG key URL to fix the related error:

sudo dnf config-manager --save --setopt virtualbox.gpgkey=\
https://www.virtualbox.org/download/oracle_vbox_2016.asc

Thank you I have updated the GPG key URL to fix the error.

I am not sure to understand what you mean by start with system-upgrade. The log for the system-upgrade I provided was for my attempt two days ago which failed and was the reason I started this discussion.

I have now a system with what looks like a working version 38 rpms but without record in the rpm database apart from the three fedora-release rpms updated manually under your advice. The rpm database still contain an old state of the rpm database from 21 Nov 2022 which was not the state I started the upgrade two days ago and most of the rpms in the database are not installed any longer.
If I try to run the system-upgrade now it fails

% sudo dnf system-upgrade download --releasever=38
[sudo] password for patrick:
Before you continue ensure that your system is fully upgraded by running “dnf --refresh upgrade”. Do you want to continue [y/N]: y
Error: Need a --releasever greater than the current system version.

For completeness here is the log of dnf history
% dnf history
ID | Command line | Date and time | Action(s) | Altered

1585 | system-upgrade upgrade | 2023-05-04 16:22 | D, E, I, O, R, | 3522 EE
1584 | install ffmpeg-5.1.3-2.fc36. | 2023-05-04 16:08 | Install | 5
1583 | remove ffmpeg-5.1.3-2.fc36.x | 2023-05-04 15:32 | Removed | 5 <
1582 | remove libheif | 2023-05-04 15:19 | Removed | 1 >
1581 | install libheif.x86_64 | 2023-05-04 15:19 | Install | 1

As you can see the last transaction is the system-upgrade I did two days ago that resulted in this corrupted rpm database from 21 Nov 2022. I can get the log of the transaction with dnf history info 1585 and here is a link to the output https://paste.centos.org/view/e9004b51

I am not sure how to further proceed, any advice would be welcome.
Also it is still not clear what actually happened and failed during this upgrade 36->38.

Some further information that might be useful, here is the output of the command
% rpm -qa | grep ^kernel | sort
kernel-6.0.8-200.fc36.x86_64
kernel-core-6.0.8-200.fc36.x86_64
kernel-devel-5.19.16-200.fc36.x86_64
kernel-devel-6.0.8-200.fc36.x86_64
kernel-devel-matched-6.0.8-200.fc36.x86_64
kernel-headers-6.0.5-200.fc36.x86_64
kernel-modules-6.0.8-200.fc36.x86_64
kernel-modules-extra-6.0.8-200.fc36.x86_64
kernel-srpm-macros-1.0-14.fc36.noarch

while here is a list of the kernel files I had just before the system-upgrade two days ago
% grep ^kernel jazz6-dnf-installed.txt
kernel.x86_64 6.2.14-100.fc36 @updates
kernel-core.x86_64 6.2.14-100.fc36 @updates
kernel-devel.x86_64 6.2.14-100.fc36 @updates
kernel-devel-matched.x86_64 6.2.14-100.fc36 @updates
kernel-headers.x86_64 6.2.6-100.fc36 @updates
kernel-modules.x86_64 6.2.14-100.fc36 @updates
kernel-modules-core.x86_64 6.2.14-100.fc36 @updates
kernel-modules-extra.x86_64 6.2.14-100.fc36 @updates
kernel-srpm-macros.noarch 1.0-14.fc36 @fedora

Clearly the database is not correct and dates back 21 Nov 2022, note that all the kernels files are not here now and have been removed since this date.