Partial dnf-system-upgrade and broken dnf?

[Jeffrey Walton]

Hi Everyone,

I attempted a dnf-system-upgrade on an old server (F40) to match the
new server (F41) I've been setting up for the migration. The
dnf-system-upgrade on the old server went sideways after step 3: `dnf
system-upgrade reboot`. On the old server, it appears the upgrade
partially happened. The machine boots, and I can login seated at the
chair; but networking is down and dnf is broken. I think most programs
are supplied by F40, but I may be mistaken.

Trying to run dnf results in similar to [1]:

Traceback (most recent call last):
     File "/usr/bin/dnf", line 61, in <module>
       from dnf.cli import main
   ModuleNotFoundError: No module named 'dnf'

I'm trying to repair dnf using rpm.[2] I *think* `rpm --reinstall
python3-dnf*.rpm` may be able to repair dnf. But I'm not sure about
dnf vs dnf5:

# from a working F41 machine
   $ dnf search '*dnf*'
   ...
   python3-libdnf.x86_64: Python 3 bindings for the libdnf library.
   python3-libdnf5.x86_64: Python 3 bindings for the libdnf library

So my question is, is the generic 'dnf' Ok, or should I try to install
specific 'dnf5' for Fedora 41? Or maybe something else?

(I'm about ready to tar up the important data files on the old server,
copy them to a USB stick, sneaker-net them over to the new server, and
destroy that old server like in [3]).

Thanks in advance.

[1] https://www.reddit.com/r/Fedora/comments/12blsg0/my_dnf_is_broken/
[2] https://www.reddit.com/r/Fedora/comments/12blsg0/comment/jf3qonz/?context=3
[3] https://www.youtube.com/watch?v=P1tihTYb1wk&t=20s

Hi.

On Thu, 14 Nov 2024 16:15:47 -0500 Jeffrey Walton wrote:
> Trying to run dnf results in similar to [1]:
> Traceback (most recent call last):
>      File "/usr/bin/dnf", line 61, in <module>
>        from dnf.cli import main
>    ModuleNotFoundError: No module named 'dnf'
> I'm trying to repair dnf using rpm.[2] I *think* `rpm --reinstall
> python3-dnf*.rpm` may be able to repair dnf. But I'm not sure about
> dnf vs dnf5:
> # from a working F41 machine
>    $ dnf search '*dnf*'
>    ...
>    python3-libdnf.x86_64: Python 3 bindings for the libdnf library.
>    python3-libdnf5.x86_64: Python 3 bindings for the libdnf library
> So my question is, is the generic 'dnf' Ok,

I think so.
> or should I try to install specific 'dnf5' for Fedora 41?

Probably not mandatory.
> Or maybe something else?

/usr/bin/dnf (F40) is a /usr/bin/python3 script.

I suspect that python3.13 (Fedora 41) has been installed, giving the
symlink:

/usr/bin/python3 -> python3.13

but that dnf5 and the python3-libdnf* RPMs have not be installed
(before the failure of system-upgrade).

python3.12 and all its modules is probably still there.

If python3.12 and all its modules is still there, you may try to:

- replace temporarily the /usr/bin/python3 symlink to point to
    python3.12
  - run "dnf distro-sync" to repair

Note: there is probably duplicates RPMs. dnf4 provides (not dnf5
AFAIK):

dnf remove --duplicates

that may help before distro-sync
> [1] https://www.reddit.com/r/Fedora/comments/12blsg0/my_dnf_is_broken/
> [2] https://www.reddit.com/r/Fedora/comments/12blsg0/comment/jf3qonz/?context=3
> [3] https://www.youtube.com/watch?v=P1tihTYb1wk&t=20s

Hi

On Sun, 17 Nov 2024 21:18:07 +0100 [e-mail] wrote:
> Note: there is probably duplicates RPMs. dnf4 provides (not dnf5
> AFAIK):
> dnf remove --duplicates
> that may help before distro-sync

I had today a machine (a VM with only 4G of memory) where an upgrade
with "dnf distro-sync" failed with result 'oom-kill' (no time to
investigate the precise reason of that).

There was a lot of duplicate packages, including protected packages
like dnf and systemd.

dnf was still pointing to dnf4 (through /usr/bin/dnf-3).

I managed to repair with:

- dnf --setopt=keepcache=yes --setopt=protected_packages= \
      remove --duplicates > FILE < /dev/null

Look then carefully at the list of packages to reinstall, then ran
    it in real:

- nohup dnf -y --setopt=keepcache=yes --setopt=protected_packages= \
      remove --duplicates

I finished then the upgrade with: dnf -y distro-sync

I saw that dnf5 has an issue to provide "remove --duplicates":

https://github.com/rpm-software-management/dnf5/issues/760

[Barry]

> On 19 Nov 2024, at 17:12, [e-mail] wrote:
>
> with "dnf distro-sync" failed with result 'oom-kill' (no time to
> investigate the precise reason of that).

One of the reasons for dnf5 development is to fix high memory usage in dnf4.

Barry