I created a discussion item here: https://discussion.fedoraproject.org/t/sddm-gdm-fail-after-upgrading-via-dnf-from-f39-to-f40/111949 I used dnf5 for the system upgrade, the transaction check passed. The system then asked if I wanted to continue, I replied "Y", then returned about 90 minutes later. I found a rebooted system with a black screen (using SDDM/Plasma6). I then switched to GDM thinking it was a SDDM issue, and this time I got the screen that says something like contact your system admin, a serious problem has been encountered. I then though to dnf5 upgrade to see if I had missed any updates and found that kdecoration was still on the F39 version because bismuth needed the F39 version, so it didn't upgrade to F40. The F40 version of bismuth failed in koji. Since kdecoration was still on F39 that set up a cascade of upgrade failures with both KDE and GNOME programs. To resolve, I simply removed bismuth, which allow kdecoration and about 1000 other programs to upgrade. This doesn't seem right to me. I would think that at a minimum the initial transaction check should have failed. Instead it basically allow a half upgraded system to be installed. Reproducible: Always Steps to Reproduce: 1.See above details. 2. 3. Actual Results: Half upgraded system allowed to boot. Expected Results: Transaction check should have failed and the upgrade aborted. I ran this with DNF5, I'm not sure if this problem also exists in DNF4. I've never before encountered anything like it.
Can you say exactly how you ran the update? Like, literally what command did you run? Can you attach /var/log/dnf5.log ? Thanks!
Created attachment 2025583 [details] dnf5 log4 The timestamp indicates this was the get F39 current to be upgraded
Created attachment 2025584 [details] dnf5.log.3 This should be the upgrade.
Created attachment 2025585 [details] dnf5.log.2
Created attachment 2025586 [details] dnf5.log.1
Created attachment 2025587 [details] dnf5.log
The command I used was: dnf5 system-upgrade download --releasever=40 Let me know any additional information I can provide. Thanks!
Forgot to add the second command to start the transaction: dnf5 offline reboot then to fix I entered: dnf5 remove bismuth dnf5 upgrade reboot
I was able to recreate in a virtual machine. There is definitely an issue and it's reproducible.
Created attachment 2025667 [details] output from dnf5 system-upgrade Shows transaction check apparently completed with no errors, which isn't true. We know there is a dependency error.
Created attachment 2025668 [details] dependency error After upgrade is complete, system black screen due to incomplete upgrade. dnf5 shows dependency error.
Created attachment 2025669 [details] tail of dnf5 upgrade command Tail of packages to be upgraded after I manually removed bismuth.f39
Created attachment 2025685 [details] dnf4 system_upgrade aborts correctly upon error detection I've tested with DNF4 and as you can see, the dependency issue is correctly detected and the system upgrade is aborted. If this isn't a simple fix, I would suggest you remove access to dnf5 system upgrade until this can be resolved, or at a minimum broadcast out a warning.
Thank you for the report and investigation! It really should be resolved ASAP. I have created a PR with a proposed fix: https://github.com/rpm-software-management/dnf5/pull/1391 and a PR with a test: https://github.com/rpm-software-management/ci-dnf-stack/pull/1482 It turned out this is a more general issue with distro-sync functionality. The dependency error is printed to stderr but right at the start of the output and since system-upgrade output is big it is immediately buried. However the transaction shouldn't proceed anyway (like with dnf4).
@amatej Thanks for the quick resolution. I'll test again the change becomes available in test repo. Much appreciated!
Created attachment 2026039 [details] Tested with 5.1.17-20240410004756.25.gd77b59e0 Tested on a VM with the COPR version 5.1.17-20240410004756.25.gd77b59e0 Looks good! Thanks so much for the quick response. Much appreciated!