Black Screen after upgrading to 43

Ask Fedora
1

I just tried upgrading to Fedora 43 after not using my Framework laptop for a couple months. I went through the Discover application. Discover performed all other updates before it performed the 43 upgrade, which includes a BIOS update. After upgrading to 43, the laptop always gets stuck at a black screen as outlined in these posts:

Updated from 42 to 43: now only get black screen

Fedora 43 KDE sometimes boots to a black screen

Talk: Fedora 43 KDE sometimes boots to a black screen

Fedora 43 black screen. (Workarounds do not work for me)

I’ve tried editing the boot command as mentioned in all of these posts to remove the rhgb argument and adding the nomodeset argument. It give me this prompt, I enter the passphrase, and then I get the black screen. This is before I provide any input:

[ OK ] Started plymouth—start.service — Show Plymouth Boot Screen.
[ OK ] Started systemd-ask-password-plymouth.path — Forward Password Requests
[ OK ] Reached target paths.target — Path Units.
       Starting systemd-battery-check.service — Check battery level during ear
[ OK ] Finished systemd-battery-check.service — Check battery level during ear
[ OK ] Stopped systemd-vconcole-setup.service — Virtual Console Setup.
       Stopping systemd-vconcole-setup.service — Virtual Console Setup...
       Starting systemd-vconcole-setup.service — Virtual Console Setup...
[ OK ] Finished systemd-vconcole-setup.service — Virtual Console Setup.
[ OK ] Found device dev-disk-by\x2duuid-abbf2f4a3\x2dc3c3\x2d40a7\x2da076\x2dcf
       Starting systemd-cryptsetup@luks\x2dabb2f4a3\x2dc3c3\x2d40a7\x2da076\x2

Please enter passphrase for disk WDC WDS250G2B0C-00PXH0 (luks-abb2f4a3-c3c3-40a7
ucsi_acpi USBC000:00: unknown error 256
Please enter passphrase for disk WDC WDS250G2BOC-00PXH0 (luks-abb2f4a3-c3c3-40a7-a076-cfa081449b69)::

This is the unmodified boot command:

load_video
set gfxpayload=keep
insmod gzio
linux ($root)/vmlinuz-6.19.10-100.fc42.x86_64 root=UUID=d7e4707e-1416-4254-be6e-22e428f152f7 ro rootflags=root rd.luks.uuid=liks-abb2f4a3-c3c3-40a7-a076-cfa081449b69 rhgb quiet
initrd ($root)/initramfs-6.19.10-100.fc42.x86_64.img $tuned_initrd

Side note: It seems that every time I’ve upgraded Fedora, the previous version is still listed in Grub. Don’t know what that’s about. Doesn’t look like 43 installed correctly, either:

*Fedora Linux (6.19.10-100.fc42.x86_64) 42 (Workstation Edition)
Fedora Linux (6.17.11-200.fc42.x86_64) 42 (Workstation Edition)
Fedora Linux (6.17.10-100.fc41.x86_64) 41 (Workstation Edition)
Fedora Linux (0-rescue-045dc2c193094b9fa55c8be56247a802) 39 (Workstation Edition)
UEFI Firmware Settings

Does anyone have any input on how to get around this issue? At the very least, I’d like to just get some data off of the encrypted M.2 drive so I can work with it on my desktop.

2

Welcome to :fedora: !

Are you able to get to the Desktop at all? If not we could drop to a Terminal and check journalctl

3

I’m afraid not. I’ve seen some reports are intermittent, but this seems to be happening every time for me. It just sits on a blank screen with a cursor forever after I enter the encryption passphrase.

I was eventually able to boot to a USB after disabling secure boot and grab my files. I tried running journalctl from there and it seems to work, but I don’t know if that’s info from the USB or from the laptop.

4

That’s completely normal. By default, Fedora retains three kernel versions, just in case a new one introduces issues. When you upgrade to a new Fedora version, like F43, it installs a new kernel from F43. A typical system already has three kernels installed, so during the update it will remove the oldest one of these. Normally, this oldest one should be from the version that you are updating from, since Fedora has way more than just three kernel updates during the lifetime of any given version, but in your case the oldest one still seems to be from F41 (maybe update like every one or two weeks? :wink: )

1 Like
5

Right. And if you booted from those “Fedora 42” or “Fedora 41” kernels, your system would still be a Fedora 43 system in every respect other than using an older kernel.

1 Like
6

That is indeed weird, the newest kernel should be from F43 after performing a system update.

What do the following two commands output on your system?

rpm -qa | grep fc43 | wc -l
rpm -qa | grep fc42
7

Running this after booting to the USB.

rpm -qa | grep fc43 | wc -l

0

rpm -qa | grep fc42

Nothing

8

I have the journalctl output in a text file, but it doesn’t look like I can upload anything that isn’t an image; there’s also a character limit on comments. If there’s something specific you wanted to see in it, let me know.

9

That seems to be from the live system, not from your installed one. According to this, you have no packages from either F43 or F42 on that system.

Can you boot your system with any of the three kernels GRUB offers you?

10

we have an fpaste you can use for long logs.

so for example : journalctl -b -1 --no-hostname --no-pager | fpaste –raw-url

11

No, they all lead to a black screen and lone cursor in the top left. The laptop stops accepting input at that point and it just sits there.

12

I get this error when I run the command.

No journal boot entry found from the specified boot offset (-1).
No text to send.
13

How did you get the journal? Does this come from an installed system or a Live USB using the —directory option in a Live USB session?

14

Everything so far is from a Live USB, since I can’t boot to the actual machine. Sorry if I didn’t clarify that.

I ran journalctl > journalctl.log from the desktop of the Live USB. I assume it’s information about the Live USB and not the actual laptop.

15

That makes sense, I lost track of the chat I guess. there is a way for you to boot the installed system from a live environment using systemd-nspawn , if you are interested in working on it.

I’m gone for the day so i can’t provide more info on all of this. Sorry.

1 Like
16

That’s some magic stuff right there, thank you! :100:

Looks like I can access the installed system details from the terminal with that. I can get the results of the previous questions when I have a moment.

1 Like
17

Here’s the information from the installed system after connecting to it via systemd-nspwan

Output for rpm -qa | grep fc43 | wc -l:
3349

Output for rpm -qa | grep fc42 | wc -l (the original command had a huge list):
2270

Output for journalctl -b -1 --no-hostname --no-pager | fpaste –raw-url:
WARNING: your paste size (1469.7KiB) is very large and may be rejected by the server.
Error Uploading: [Errno -3] Temporary failure in name resolution

I couldn’t find info on the error from fpaste. I can connect to pastebin just fine through a browser. I assume the server rejected it because of the file size.

18

OK, this is a bad mix. I had only asked for the count of the F43 packages and wanted to see the actual list of F42 packages, since I assumed that the number of F42 packages would be very low (I have five fc42 packages on this F43 machine).

I suggest you try and complete the upgrade from the commandline:

sudo dnf distro-sync --refresh --releasever=43
1 Like
19

journalctl has “filters” to help select entries relevant to an issue. start with -p … (error priority) and -g … (string search)`. You can find examples online.

20

Thank you guys for the additional input!

I realized that systemd-nspawn is kind of like an RDP of sorts, and nothing on the Live USB system is running in it, including the network. That seems to be why I can’t run fpaste or run sudo dnf distro-sync --refresh --releasever=43. --releasever=43 was also not a recognized argument.

I did some searching for a way to easily enable the network when running systemd-nspawn, but everything I found involved some in-depth network configuring and I am just not motivated to deal with networking stuff; I’ve had too many bad past experiences.

Since I was able to grab my files through the Live USB, I think the easiest option is to just wipe the machine and do a fresh install. That’ll also clear up the lingering F42 packages thing; I assume that stemmed from using Discover to update.