I recently updated my system and all packages using sudo dnf upgrade. It also updated the kernel to 6.9.10. Everything seemed fine until I rebooted the system. Since then, the system will try and boot up normally, Plymouth runs for a second, then the screen goes blank and intermittently flashes. No text, icons, or anything appears on the screen. It will do this until I turn the system off. I’ve tried disabling Plymouth, but there doesn’t seem to be any difference. I’ve also tried booting into a different kernel, but the previous kernel versions, which worked before, exhibit the same behavior. I’m at a loss as to what’s going on. It seems like some startup process is in a failed loop that it can’t get past; what the process is or how I disable it is beyond me. Does anybody have any idea as to what could be going on? Any help or insights would be greatly appreciated.
Are you able to reach a tty console? If yes, please share the output of the log entries since the last boot, by running the command journalctl -b --no-hostname | fpaste --raw-url and share the generated link.
BTW, how did you upgrade to kernel 6.10, given that the current stable kernel is 6.9.11-200?
My apologies. I misremembered the kernel number. It’s 6.9.10, not 6.10. Thanks for catching that.
Unfortunately I can’t get logged into the system at all. The problem occurs after Plymouth loads and before login. The only thing I can access is grub. I can’t even boot into the recovery partition.
While I doubt it’s a kernel issue, if it’s helpful, here are all the kernels that I have on my system:
You could edit the grub command when booting, and remove rhgb quiet, in oder to be able to catch some relevant information in the boot logs. Do you notice anything relevant?
Thanks for the reply. I was able to see the boot output. It appeared to boot normally until the screen started flashing. The last entry causes me to pause a bit. It says:
systemd-journald[756]: /var/log/journal/{id}/user-1000.journal: Journal file uses a different sequence number ID, rotating
Doing a quick search (and context clues), it seems like all that is doing is logging. I can’t imagine that would bring my whole system down. However, everything else that started seems to be fine. There is a line that says the following:
Starting plymouth-quit-wait.service - Hold until boot process finishes up...
and no line after that indicating that the boot process finished up. I’ve included a screenshot with the output. Sorry for the poor quality; I had to take the image quickly, as it only displays for about a half second.
No relevant information there as far as I can tell.
It is not clear to me if you managed to reach the console after the blank screen or not. It should be possible by pressing Ctrl+Alt+F3 (try also Ctrl+Alt+F2 and Ctrl+Alt+F4).
If you cannot reach the console, then after a new boot I would try booting into multi-user.target (i.e. text mode or runlevel 3) instead of graphical.target. This should be possible by adding to the grub command line, after rhgb quiet either text, or 3 (try with one or the other, I haven’t tested it).
Should you reach the console, log in, then provide the generated links for the following command:
# System logs for the last boot, in case you managed
# to reach the console without changing grub
journalctl -b --no-host | fpaste --raw-url
# OR
# System logs for the previous boot (the one before the last one, with issues)
# in case you needed to change the grub command line
journalctl -b -1 --no-host | fpaste --raw-url
and that of:
fpaste --sysinfo --raw-url
There were some issues with mesa, also documented here in the forums, however those seem to be fixed with the latest release. On the other hand, your upgrade was not the “most” recent, given that you’ve upgraded to kernel 6.9.10, whereas we are currently on 6.9.11.
While at the console, you should also run a sudo dnf upgrade --refresh, maybe your issue got fixed in the meantime.
Thanks for all the info. It’s been helpful. I was able to get to the tty console by appending a ‘3’ at the end of the grub arguments. However, something very curious happened. When I login successfully, the console pauses for a moment, then resets, asking me to login again. I know it’s a successful login attempt, because the console tells me if it was unsuccessful. It also flashes briefly “X failed login attempts” when I then login successfully before it resets.
Since I can’t seem to do anything, I’m wondering if the best solution is to just wipe my system and start from scratch again?
I have also booted into multi-user.target (runlevel3), but I haven’t seen many services being started after successful login (Pipewire PulseAudio, creation of tmp files, among the few), which could cause your issue.
You might want to check the health of your hard drives, e.g. with a Fedora WS 40 live USB, which you would need anyhow if you’re pondering on fresh installing the system.
I am out of ideas, but I would wait for a short while, maybe someone else might join the topic with suggestions. If not, reinstalling the system (and backing it up from time to time ) could be a solution.
I wanted to update this thread as I found the cause of way too many lost hours: my .bashrc file.
I had updated this file with some configurations from another machine. No issues were apparent while I was still logged in. I hardly ever restart my machine until an update forces me to, which is why I attributed the issue to some package update. After I finally clean installed Fedora, I went through updating and installing everything that I needed. Lo and behold, on reboot, the issue showed back up.
After rebooting after every single package installation and update that I use, I finally whittled it down to my .bashrc file. My user automatically logs in after boot, which is why I could get past Plymouth, but then when it would attempt to login, it would immediately kick me out. It would then try to login again ad infinitum. That’s also why it would kick me out after a second when I tried to login to a TTY session. Something in that file was causing an error on login. What it was I have no idea; I haven’t gone through to figure that out. I’m sure it was an incompatibility between the machine I got it from and this one.
Long story short: the problem was user error. And I could have saved myself a lot of trouble by just editing .bashrc from a live USB had I known that was the problem. Hopefully this can help some poor chap experiencing the same bizarre issue I was.
) could be a solution.