system fails to log in after upgrade from 38 to 39. After entering login password, I see a white screen like the following:
Oh no! Something had gone wrong.
A problem has occurred and the system can’t recover.
Log Out (button)
Symptoms:
I don’t see f39 in boot menu
I see some errors during boot about CUPS service failing to start.
I had about 5 gb free space on / before starting upgrade. Did this small space screw my system?
Is there a cure?
Can you get to a console to login? Ctrl-Alt-F3? Or can you ssh into the machine?
If so then you can start collecting information to help find out what has happened.
Yes I can open tty3 and I checked free space with df which was 5 gb. So it might not be the issue. Interestingly dnf does not work in that tty giving a command not found error. Ping Google.com doesn’t neither.
Tried logging in with other gnome environments. None worked. Wayland immediately jumps back to login screen but other ones open the white screen with error message.
What does /etc/fedora-release contain? Does it say you have 38 or 39?
What does ls -l /usr/bin/dnf report?
I’m wonder if the upgrade broke part way through.
Also helpful would the the detailed output of df so we could see the actual space available in all mounted file systems.
Release shows 39.
For that second, I get
lrwxrwxrwx 1 root root 5 sep 20 03:30 /usr/bin/dnf → dnf-3
df -h / gives:
/dev/sda10 81g 75g(used) 5.3g(available) 94%(use)
I suspect I need to create a bootable f39 flash disk and install a fresh f39.
This never happened to me though. Always, the upgrades worked smoothly since 2015.
An version upgrade does not always install a new kernel. The kernel from the previous version can sometimes be newer than the one from the new version.
What exact errors was that?
That can very well be a cause for problems. The directories /var/tmp, /var/log, and /var/cache can contain big files you can safely remove.
OK, after deleting the mentioned directories, what other procedures should I do to save the system?
If dnf worked, which doesn’t, I could have installed KDE and switch to that to see if I can log in with non-gnome environments.
I suspect the dnf system has broken, and the upgrade has failed. Not sure why this could happen given that dnf uses transaction system to perform upgrades (presumably to revert back failed operations).
Shouldn’t have heeded the upgrade temptation in the middle of a project 
for now, I have to do things in the Windows environment, which lacks the ease of use I saw in Gnome over the years, but better than nothing.
You were not supposed to remove the whole thing. Only the big files you were sure you would not need.
I have not deleted them yet. Do you think adding more free space on top of the existing 5gb can fix issues?
Running a filesystem with a small percentage of free space generally slows things down. My experience has been that upgrades are disk intensive and will push older drives over the edge into failure. I try to keep drives above 20% free space.
I would start by checking the S.M.A.R.T status of the drive. You can do that in Windows (various 3rd party software) or with the Live Installer on a USB stick in Gnome Disks.
You have not shown us the requested “detailed output of df”. This is very important, as there may be partitions that ran out of space.
There is no magic 1-step fix. If the drive is OK, a careful cleanup removing old logs, downloads, etc. may get you more free space, speeding up the process and reducing the risk of problems.
Then you will need to look in logs for error messages and post details to determine the next step.
This clearly is soon to become an issue if it is not already. It was requested that you post the full output of df. You chose to only post a single partition which limits the info we have for making an informed suggestion. You should take action to either reduce the amount of data there or to expand that file system to allow more room for growth.
One quick shrinkage might be to run sudo dnf clean all and sudo dnf system-upgrade clean to remove all the cached data from use of dnf and see what happens after that.
Anytime the root file system is more than 90% full it is a problem waiting to happen since new data added to the filesystem quickly becomes fragmented as well as having limited space for larger activities. A system upgrade is clearly one of the largest downloads of data that would routinely be done into the root file system.
So I guess I should run df without any arguments to give the full output.
Also, the bad part is dnf is not working anymore. Looks like it’s broken. Showing a Python error each time I run it. I’ll update this with details after I switch to Fedora and gather more info.
Your problem is different from the one in this thread. Multiple problems in one thread is confusing and tends to bog down the process. I suggest a new thread with a title that will be recognized by others with the same problem: upgrade to F39 failed: pdpg-fedora-repo-42.0-28PGDG already installed.
Please start your own thread on this. It becomes very difficult to understand the discussion when working on more than one issue within the same thread. It is hard to tell what comments apply to which user and problem.
