Fedora 43 KDE: Black screen with underscore after LUKS passphrase

Ask Fedora
,
1

Hi everyone,

I’m a new Fedora user and I’ve run into an issue after a fresh installation of Fedora 43 KDE. I’m dual-booting with Windows on a single SSD.

The installation from the live image went smoothly. However, when I reboot and select Fedora from the GRUB menu, I see the OMEN logo with fedora under, followed by the prompt for my disk encryption passphrase. After I enter the correct passphrase, the screen goes black with only a single underscore in the top-left corner. The desktop environment (KDE) never loads.

System spefications:

  • HP OMEN MAX 16
  • Intel® Core™ Ultra 9-275HX (with integrated graphics)
  • NVIDIA RTX 5070Ti
  • Dual-boot with Windows (on the same SSD)

For troubleshooting I have disabled fast startup in Windows, disabled secure boot in the BIOS, tried booting without graphical boot (as discussed in the forum before, racing condition etc.) pressed e at the GRUB menu, remove rhgb from the linux line, then booted again, but these all didn’t solve the issue.

Lastly I have tried all of the button combinations while I am on the black screen as CTRL + ALT + F1/F2/F3 to see anything on the screen, but it resulted with nothing.

I have not yet installed the proprietary NVIDIA drivers yet, as I can’t get to a desktop. So I don’t think it is any related to NVIDIA.

Could anyone please advise on the next steps? I really liked Fedora on the Live Image, so I really want to use as linux distro. I tried UBUNTU also, but ended up with wifi and bluetooth problems which I also couldn’t find a solution.

Maybe these are all problems because of dual-booting on the same disk, I am going to get a new SSD to install Fedora there soon. But until that time, I wanted to see if I can do anything more.

4

Same thing happens to me on a ~2 yr old OMEN 17 with a 3070. One time I actually got it to start completely randomly but then the NVIDIA drivers from RPMfusion wouldn’t work. And then the next reinstall it wouldn’t first boot again.

I’m not dual booting, so that’s not it. I’ve been using Linux 20+ years and I’ve never had problems like these. I posted my issues on different platforms since it was ignored here and basically was told it was a skill issue.

Hope the realize the issues this is causing for some users the more they post about it.

Edit: Actually looks like someone posted something potentiality helpful here (Fedora 43 KDE sometimes boots to a black screen), especially if you are booting with external monitors, but I swear I tried disconnecting them. I’ll try fresh install with no dock or external monitors when I get home.

5

Already tried this one related to playmouth handoff, but no solution still. Thank you indeed for your attention.

6

Maybe something here: Talk: Fedora 43 KDE sometimes boots to a black screen - #7 by fedor-alex

7

I actually got it to work. When you boot, in the GRUB boot menu, press e on the top boot option. remove rhgb quiet like you did and replace it with modprobe.blacklist=nouveau and ctrl+x to boot. Since I have disk encryption, it seems to hang, after a bit of scrolling text, when it stops, press a button and it will prompt for the unlock password. After that, it should boot. I updated and then rebooted again, it seemed to take a while to boot, but I didn’t need to do anything special. After that its been fine. I did install the NVIDIA driver from RPMFusion pretty quick though.

2 Likes
8

Thank you so much Garrett, I am now writing on Fedora. I have also successfully downloaded NVIDIA Driver from RPMFusion.

1 Like
9

I have a similar problem on desktop. The hardware is an Intel NUC7i5BNH with OS and data on an M2 240Gb SSD, RAM 32Gb
I updated from F41 to F43, without doing data backup (on reflection, all very bad moves!!) using the standard ‘Software’ utility.
All appeared to complete without error, but when attempting to reboot, the process gets to a static cursor, top left of screen, and then stops.

Using Ctl+Alt+F4 when booting (from the M2 disk) I can display the CLI login screen but cursor is static.

During the various attempts to solve the problem I have found two reported errors.

  1. “Fedora Linux 38. The ‘initramfs’ is past its end-of-support date (2024-05-14)”
    The full message is difficult to see, as it only appears for an instant, when booting the installed F43 OS.

  2. I created an image of F43 on a USB and booted from this device.
    This completes the boot process, and I can open the terminal.
    ‘fdisk -l’ reveals one error relating to the M2 disk on which the OS resides.
    The error states that :
    “GPT PMBR size mismatch will be corrected by write. The backup GPT table is not on the end of the device”

Following your tips on another thread I have edited the linux line in the boot script,
removing ‘rhgb’ and ‘quiet’ and adding 'systemd.unit=multi-user.target

This enables the boot process to progress to the point where a stable (blinking cursor) CLI screen is displayed and I am able to login.

‘rpm -q kernel’ lists four kernels :
6.5.11=200.fc38 *** 6.16.12=100.fc41 *** 6.17.6=100.fc41 *** 6.17.7=300.fc43

‘ls /boot’ indicates the fc38 initramfs

Tried using ‘dracut’ to build the fc43 kernel but that failed ‘No space left on device’
Anything to do with needing gt 1Gb partition mentioned somewhere ??

I attempted to boot the system using ‘startx’
It crashed trying to access ‘x11’ server. Could it be because of the wrong ‘initramfs’ ?

Any ideas, suggestions much appreciated. I’m thrashing about in (for me) the weeds here ! Thanks.

10

why is this kernel still installed? Have you been booting this old kernel all this time?

pls post output of these four commands

$ sudo grubby --default-kernel
$ cat  /etc/sysconfig/kernel
$ ls -l /boot/
$ df -Th /boot/
11

Hi Mark,

I was not aware that the kernel was out of date until attempting to install F43. Most new releases until now have gone smoothly.

/boot/vmlinuz-6.5.11-200.fc38.x86_64

#UPDATEDEFAULT specifies if new-kernel-pkg should make

#new kernels the default

UPDATEDEFAULT=yes

#DEFAULTKERNEL specifies the default kernel package type

DEFAULTKERNEL=kernel-core

This contains a number of directories and files relating to the fc38 kernel. I will try to upload a photo. It didn’t work last time I tried.

/dev/sdb2 ext4 974M 133M 775M 15% /boot

That’s it I think

12

copy and paste the text and mark it as preformatted text! Use the ‘</>’ symbol.

13

I’m posting from another machine - can I do that?

14

as long as you post the info from the nuc and not from the ‘other’ machine.
I assume you’ve logged into the nuc with ssh or rdp.

ah right. system is in multi-user. ssh should be available to login if enabled.

15

I’m posting from a laptop which ironically has F43 installed.

The desktop with the problem is alongside. I am logged on to the desktop using the CLI. Can’t get past that point - no GUI running.

I don’t know if this relevant, but I tried re-installing from the USB image. A warning indicated that there was not enough space - only 1Gb - needs 1.07Gb I think it was referring to /dev/sdb2

Correction: ‘df -h /boot/efi’ shows /dev/sdb1 size:200Mb Used:197Mb Avail:7.2Mb

16

enable sshd on the nuc and ssh from your laptop.

Have you read this and made sure it has been configured?

I’d say this could be the main issue. And there is something else going on, because it looks like /boot is not utilized much if we can trust those numbers

/dev/sdb2 ext4 974M 133M 775M 15% /boot

that would mean that 775M are still available?

Assuming you running 6.5.11 right now (check with uname -r ) I’d try to remove kernel 6.16.12 and 6.17.6 ( don’t remove the kernel system is running )

use rpm -qa kernel-core
and then sudo dnf remove kernel-core-"theversion you want to remove"

then sudo dracut --kver=6.17.7-300.fc43.x86_64 -f and boot the 6.17.7 kernel.

you can also pull new updates excluding kernel
sudo dnf upgrade -x kernel\*

17

I am running 6.5.11 now. There are only three kernels left now, as I removed 6.16.12 to make space. ‘dracut’ 6.17.7 still failed - not enough space.

I will remove 6.17.6 and attempt to generate 6.17.7 again.

Thanks for your help. I’m busy this weekend, so will follow your instructions and post again early next week.

1 Like
18

Just made an account to thank you for this!
I bought the very same PC as Pengu 3 days ago and I was struggling with Fedora and I couldn’t find what was triggering the error… even with 3 different versions (Fedora 42 KDE, Fedora 43 Workstation, Manjaro…)
Love you <3

1 Like
19

Glad I could help! Surprised the issue persisted across versions and different DE of Fedora, and even another distro, I just thought it was something specific to this F43 KDE release.

20

I’ve been taking a look and it doesn’t look that atrange as nouveau is a graphics driver. Most likely, the recent versions of the distro use this driver that “may contain” some sort of bug that causes a loop.
Since I testee removing some kernel arguments on grub (rhgb, quiet) and took some photos of it, I’ll try findong a way to report it somewhere in case it helps…

IMG_20251121_192333985
IMG_20251121_1923339851920×3415 895 KB

IMG_20251121_193740866_HDR
IMG_20251121_193740866_HDR1920×1080 365 KB

21

Hello Mark,

The GDM problem :
‘authselect current’ returned ‘No file found’. There was no postlogin’ file.
I corrected things as suggested and the current file is now in place after reboot.

Using ‘ssh’ :
I managed to get the two machines linked using ‘ssh’ but, since rebooting the NUC,
‘host unreachable’ and ‘ssh.service does not exist’ is reported on both machines.
Not used this facility before so, I need to go back through the process again to check what I have done wrong.

The kernel problem :
Removed 6.17.6-100.fc41
Dracut 6.17.7-300.fc43. No space. Failed to create /boot/efi/ecb…/6.17.7-300.fc43.x86_64/initrd.tmp
'du -sh /boot/efi indicates that 197M of 200M is used. This seems to be the reason the new kernel cannot be generated.

I removed a directory /boot/efi/ecb…/4.15.17-200.fc26.x86_64 (another historical left-over ??) from /boot/efi.
This reduced the size a little, but 'du -sh /boot/efi still shows 197M used. The laptop shows 4k!

Is it safe to clear /boot/efi ?

22

see the procedure in F39 kernels fail to install when /boot/efi/$machineid is present

check the output of sudo kernel-install

$ sudo kernel-install 
        Machine ID: $machineid
 Kernel Image Type: pe
            Layout: other
         Boot Root: /boot/efi
  Entry Token Type: machine-id
       Entry Token: $machineid
   Entry Directory: /boot/efi/$machineid/6.17.9-300.fc43.x86_64
    Kernel Version: 6.17.9-300.fc43.x86_64
            Kernel: /usr/lib/modules/6.17.9-300.fc43.x86_64/vmlinuz
           Initrds: (unset)                                                          
  Initrd Generator: (unset)                                                          
     UKI Generator: (unset)                                                          
           Plugins: /usr/lib/kernel/install.d/10-devicetree.install
                    /usr/lib/kernel/install.d/20-grub.install
                    /usr/lib/kernel/install.d/50-depmod.install
                    /usr/lib/kernel/install.d/50-dracut.install
                    /usr/lib/kernel/install.d/51-dracut-rescue.install
                    /usr/lib/kernel/install.d/55-set-boot-entry.install
                    /usr/lib/kernel/install.d/60-kdump.install
                    /usr/lib/kernel/install.d/90-loaderentry.install
                    /usr/lib/kernel/install.d/90-uki-copy.install
                    /usr/lib/kernel/install.d/92-crashkernel.install
                    /usr/lib/kernel/install.d/92-tuned.install
                    /usr/lib/kernel/install.d/95-akmodsposttrans.install
                    /usr/lib/kernel/install.d/95-kernel-hooks.install
                    /usr/lib/kernel/install.d/99-grub-mkconfig.install
Plugin Environment: LC_COLLATE=C.UTF-8
                    KERNEL_INSTALL_VERBOSE=0
                    KERNEL_INSTALL_IMAGE_TYPE=pe
                    KERNEL_INSTALL_MACHINE_ID=$machineid
                    KERNEL_INSTALL_ENTRY_TOKEN=$machineid
                    KERNEL_INSTALL_BOOT_ROOT=/boot/efi
                    KERNEL_INSTALL_LAYOUT=other
                    KERNEL_INSTALL_INITRD_GENERATOR=
                    KERNEL_INSTALL_UKI_GENERATOR=
                    KERNEL_INSTALL_STAGING_AREA=/tmp/kernel-install.staging.XXXXXX
  Plugin Arguments: add|remove
                    6.17.9-300.fc43.x86_64
                    /boot/efi/$machineid/6.17.9-300.fc43.x86_64
                    /usr/lib/modules/6.17.9-300.fc43.x86_64/vmlinuz
                    [INITRD...]

the important line is Layout: other

As always, it depends ;). You can remove the directory /boot/efi/$machineid_disabled after you have successfully booted from a newly installed kernel in /boot/.