Cannot boot into desktop

Hello everyone,
So unfortunately I broke my installation of Fedora yesterday or so. Now I do not know how to fix. I am hoping someone here could help me fix it without making a reinstall necessary.
My issue is that I cannot boot into my desktop anymore. I always get a white screen with an generic error message along the lines of “Cannot solve issue automatically. Please ask system admin”.
What works so far is unlocking my Luks encrypted partition. So I still have access to my files to backup for a reinstall. Shortly after that I get that aforementioned white screen.
Before the error appeared I was browsing the Internet until my battery died. I also might have deleted some system files that were called wine something. (I wanted to get rid of wine completely, might have been a stupid idea in hindsight).
I am now completely clueless as to how to fix this issue and was hoping to get help here.

Can you boot into any desktop; that is, if you were booting into a Wayland session, can you boot into an X11 one?

No not all. I do not even get to the login screen to choose. Right after choosing Fedora in GRUB, I get the unlock partition screen. After that I expect the user login screen but that’s where I get white error screen instead. Please excuse me if the terminology I use is confusing/wrong.

Not at all, that makes sense now.

Have you tried booting into an older kernel?

1 Like

Yes, I also have an alternative kernel (for surface devices) installed and it has the same issue.

Well, none of that is good. Although I don’t think removing the wine stuff would do anything this serious, who knows.

Have you tried booting a liveusb? That, at least, could rule out a hardware issue and would then somewhat confirm it is something else.

Yeah I did and it works without problems. I had to check if I could at least recover my home folder before a potential reinstall. Which seems like I will have to do I guess.

I’m not even close to an expert, but that sounds like the only option… Perhaps someone else can provide better or different advice, though.

Interestingly, I just happened to see this post and clicked through the referenced article… Doesn’t sound that much different than your issue; although, it’s a flashing white screen and not a blank white one…

1 Like

You should be able to choose different kernels on boot.
→ First, which kernels do you see in grub? E.g., “5.19.11-200.fc36.x86_64”
→ Second, if you choose the two older ones, does the problem persist in both?
→ Additionally, have you updated or done any other changes in the boot before the issue occurred the first time?

→ can you provide a screenshot (e.g., with a camera) of the error you see?
→ If you log into the terminal (when the system has booted, do CTRL+ALT+F4), what is the output of sudo systemctl status gdm & sudo systemctl status sddm ? You can make again screenshots with a camera or so (it can need maybe more than one screenshot to get all lines / complete lines of one output).
→ What is the output of cat /proc/sys/kernel/tainted when using an original Fedora kernel that experiences the problem?
→ Do you use nvidia driver?

What do you mean with “alternative kernel for surface devices”? Can you elaborate that?

I see kernels:

  • 5.19.13-200.fc36.x86_64
  • 5.19.12-200.fc36.x86_64
  • 5.19.11-200.fc36.x86_64
  • 5.19.10-1.surface.fc36.x86_64
  • 0-rescue (if that counts)

Yes, I have the same problem on all kernels.

First command output:

Second command output: Unit sddm.service could not be found

Output: 0


I use Fedora on a Surface Pro 7. For better hardware compatibility (e. g. touch) I had to install a kernel from the linux-surface project.

I don’t really remember. I know that I changed wine and I probably checked for updates because I do that most the time.

The issue does not seem to fit really, at least I can’t do anything with it. Thank you anyway though for helping.

Log into the terminal, then enter the command sudo journalctl --vacuum-time=7d (how much space gets freed?)

Then, reboot. Does the problem persist?

The Session never registered, failing error (see your gdm log) was in another thread caused by a full /var/ partition: Flatpak update warnings on fedora remote

Removing old logs (which is what my command above does) can help us to test if this is the cause on your system as well. That approach is based on the assumption that there are sufficient old logs on your system to free a larger amount of space (this is why I ask above for the freed space).

I tried running your command but it says 0B removed. I also tried uninstalling a few flatpaks, they should be installed in /var/ right? But I still get the white screen.

Just to be on the same page: do you use Fedora Workstation or Fedora Silverblue?

However, maybe your logs can reveal a bit more… Boot your machine once and when it is booted (obviously, with the error), directly shutdown without doing more than that.

Then, boot again, and from the terminal, enter journalctl --boot=-1 > logfile → this creates a file named “logfile” with the logs of the then-last boot, which will be then the one boot that contains nothing but the boot & shutdown.

You will need to use a usb drive or something like that to copy the log file to the machine where you can upload it.

Feel free to anonymize data you consider private (e.g., MAC address, user name).

Also, let us know the output of df -h (for this, a screenshot is sufficient).

Interesting. Let’s see what the logs tell…

I am using Fedora Workstation 36 (GNOME)


Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs        4,0M       0  4,0M    0% /dev
tmpfs           3,7G       0  3,7G    0% /dev/shm
tmpfs           1,5G    2,0M  1,5G    1% /run
/dev/dm-0       119G    117G  1,5G   99% /
tmpfs           3,7G       0  3,7G    0% /tmp
/dev/dm-0       119G    117G  1,5G   99% /home
/dev/nvme0n1p4  974M    315M  592M   35% /boot
/dev/nvme0n1p1  256M     40M  217M   16% /boot/efi
tmpfs           754M     68K  754M    1% /run/user/42
tmpfs           754M     56K  754M    1% /run/user/1000
onedriver       5,0G    3,7G  1,4G   74% /home/kevonfernando/OneDrive

Your logfile link seems to be password protected.

However, your df -h indicates that your system subvolumes are indeed widely full (>99%). So I suggest to get rid of some stuff to free space, and then reboot and check if the problem remains. Given that we know that this error will be produced if GDM/GNOME have no space left, I assume the nearly full system subvolumes are no coincident.

I assume you have a btrfs with / and /home being subvolumes of this btrfs? If this is the case, you can reclaim space at both the / and /home mount points: it will free space on both.

I am still wondering that no logs were removed. However, there are other possibilities to free space, too.

I guess you do not have 115 GB of applications. Maybe clean your Download or Video directory, or remove packages you do no longer need. You can find much incentives here and on the Internet about how to free space on Fedora. dnf autoremove can free a lot but you should check the list of packages it wants to remove, just to be safe (I keep always the list of packages it will remove to be able to reinstall them if I experience an issue later).

Alternatively, it can make sense to increase your btrfs volume, or to create a new file system for one of the system mount points (and move any content within to the new). But the latter has to be done with a live system. Concerning the increased btrfs volume, if you use multiple devices in one btrfs volume in which you store relevant data, you might read the comment of @chrismurphy about creating redundancy for file system meta data here (be aware that this does not replace a backup of critical data or so).

1 Like

I would search through / and see what are the largest files or directories and start cleaning there.

Often the journal takes up a lot of space, (or Trash, or cached packages in /var/cache/PackageKit). Another candidate to use up a lot of disk space are flatpaks (/var/lib/flatpak).

Run the following to find out what’s taking up all the space

LANG=C sudo du -aBm / 2>/dev/null | sort -nr | head -n 25

If the journal has grown big, you can clean it using

journalctl --vacuum-size=500M

As for journal rotation (normally no need to perform this manually), you can set in SystemMaxUse=500M in /etc/systemd/journald.conf and your journal won’t grow above 500M.

1 Like

Oh yeah sorry totally forgot that. The password is fedora123

We already tested --vacuum-time=7d , I guess the remaining is not >500M given the log amount. However, it would be still interesting to see if there is a difference with vacuum-size=500M because there were 0B freed with vacuum-time=7d, which made me wondering. Btw, Kevon, I guess your system is older than 7 days? Or have you already cleared the logs recently? Let us know if --vacuum-size=500M behaves different than vacuum-time=7d.

I skimmed through your log and compared it to the other case (as far as the other topic documents logs). I think we should stick with our approach: free space or add devices.

I believe I had Fedora now for nearly a year, so yeah it should be older than 7 days :smiley:

So this actually made a difference. With --vacuum-size=500M it freed about 100M of space.

This does not seem to work. I deleted a bunch of flatpaks and a large backup I had on my home folder and I still run into that same error screen. df -h also says now that there is now 30% free on the root folder. Also increasing the volume size is not really feasible for me.
I really just feel like reinstalling it at this point to get it over with honestly.