>I don't think it's a kernel problem, possibly a dnf cache issue, I too think it is not likely to be a kernel problem. A dnf cache problem also seems unlikely - each try retrieved new copies of the package files from a mirror, then failed in the same way. After the reboot, I think the dnf cache would be unchanged - but now the update worked.
I suggest some older versions of tools used by dnf (broken or incompatible) were in the memory image when dnf upgrade failed. The reboot loaded up-to-date versions of these tools, and dnf then worked properly. However distasteful I find the remedy "Reboot the machine." I have no sure solution to manage incompatible versions of programs shared by multiple active applications. Maybe dnf could become smarter about detection of incompatibilities when it upgrades a package, and warn the user when a reboot is necessary to reconcile the active environment with the new disk image, but I believe there is no strategy that can do this perfectly. Even if dnf should detect a possible conflict, there is no way it can know whether a user will attempt some activity sensitive to this conflict. At least the problem I observed appears to be safely in the past. _______________________________________________ arm mailing list -- [email protected] To unsubscribe send an email to [email protected]
