Black screen (only "_" on top left) on boot, after grub menu; only but all 6.3 kernels including 6.3.8 (module_blacklist=ucsi_acpi doesn't mitigate)

Ask Fedora
, , ,
1

This is a follow-up of Fedora hangs on boot after upgrading to kernel 6.3.4 - #87 by py0xc3 → at this time, we know that the topic contains three different issues/bugs. Two of whom were already solved in the other topic.

In all cases, please update to kernel 6.3.8, which solves two of the three issues. If 6.3.8 does not solve your problem, please boot once with 6.3.8 with the kernel parameter module_blacklist=ucsi_acpi: if kernel 6.3.8 does not solve your problem on itself, but booting with module_blacklist=ucsi_acpi does, then please add a post in the other topic, so the one mentioned above, to let us know. If neither module_blacklist=ucsi_acpi nor kernel 6.3.8 solve your issue (while 6.2.15 is the most recent kernel that works without issues), you are right here:

In the other topic, one user (the original author of the topic) remains with their problem, which thus is different to the other two problems. The hardware and behavior correlates to the users with the ucsi_acpi issue, which is why we should focus on testing with kernel 6.3.8 onward (just to ensure that the ucsi_acpi bug and its related entries do not blur our analysis of the remaining issue, in case it did apply to the user next to another yet unknown bug)

Original problem elaboration of the affected user (from the other topic):

@rairai9 Sean, let us continue here to elaborate your problem, beginning testing with 6.3.8 and only considering data from 6.2.15 and 6.3.8+ to avoid anything that could be linked to one of the other issues. Beyond the people working on the bug report, I will have another look on how to get more data in the next days. If there are any changes or you get any new data, feel free to let us know here.

If there are other users with the same issue, feel free to let us know here.

The related bug report is at the moment: 2212012 – Fedora 38 workstation hangs on boot after upgrading to kernel 6.3.4 (it incorporates also the ucsi_acpi issue) → the bugzilla report contains the 6.2.15 dmesg of the user who still has the problem (which is @rairai9 ).

2

@rairai9 Can you try once again to boot without rhgb quiet but this time with kernel 6.3.8? What output appears when booting in this setting?

At the best, make a screenshot with a camera or so.

3

@py0xc3 Yes, when booting kernel 6.3.8 without rhgb quiet the only output that appears on the screen is this message (which also appeared when attempting to boot earlier 6.3.X kernels) -

 Booting a command list

EFI stub: UEFI Secure Boot is enabled.
4

Expected, but worth a try.

I don’t think it is related because 6.2.15 works while the majority has
no issues on 6.3.X, but you should try to disable secure boot in your
bios for once and try again. Then repeat the 6.3.8 boot without rhgb quiet. If it is the same, enable secure boot again.

Just to finally exclude a relation.

5

I have now two further kernel issues with regards to graphics, but in both cases, the issue is limited to some devices that are attached by graphical interfaces (likely both hdmi). This means, one device attached and the issue appears, once the device is exchanged by another one, everything works fine. [1] [2]

Both have amd, but this can be a coincident if the bug is not amd- but hdmi-specific (or specific to something else with potential for graphics impact). Is it possible that you try to work with kernel 6.3.8 with other monitors, beamers or whatever?

Also, can you identify the supported HDMI version of your machine and the monitor (and if you can test with other monitors, also of these monitors).

Of course feel free to test any monitor/beamer you have, not limited to HDMI. We want to know what works and what not.

6

@py0xc3 When booting kernel 6.3.8 without rhgb quiet and with secure boot disabled, the only output that appears on the screen is a similar message -

 Booting a command list

Unfortunately I only have the monitor I’m using. It is relatively new and has never given me any problems in terms of graphics or visuals. My desktop (a Dell Inspiron 3891) supports HDMI 1.4b. I can’t seem to find any data about the supported HDMI version of my monitor (an LG 24QP500-B), but I’m guessing it also supports the same HDMI version. The monitor runs natively at 1440p and has a native 75 Hz refresh rate.

7

I think at the moment, the best way to get a little ahead is to blindly
test blacklisting modules and see what makes a difference… It’s an
ugly and implicit way of identifying origins, but I think the comparably
easiest/fastest to get some direction.

Boot with the most recent kernel that works (6.2.15 as far as I
remember), then check lsmod. You will get an output with three
columns: “Module”, “Size”, “Used by”.

I suggest now to boot your system with kernel 6.3.8 but each time with
module_blacklist=<module name> where <module name> is one of the
modules in “Module”, while you test first the modules in “Module” where
the corresponding “Used by” Column does only contain a number but
nothing else right to the number (the number itself is not relevant for
our purpose). This way, you test the modules one by one.

You may start with the modules that indicate video/graphics relation,
but be aware that on the kernel level, it can even be that the origin of
such an issue is, e.g., a network driver or so. So test all modules,
even if there is no obvious relation to graphics/video.

If any module’s blacklisting helps to boot 6.3.8 completely/properly, or
if it just helps to boot further than before (it would be already a big
advantage if it would boot to a level where we get some logs), then let
us know at the best this module’s line in lsmod with 6.3.8. If any
module makes a difference (whatever difference it is), also let us know
the corresponding lsmod line (if the difference does not allow you to
enter a terminal in 6.3.8, get the line of 6.2.15).

8

Hello,

I have the same problem. I tried the module_blacklist=ucsi_acpi without luck, but saw some errors related to nouveau in journalctl -b -1.

So I tried to blacklist nouveau in grub directly during boot and I’ve finally managed to boot completely without issues.

Here is my setup, if it can help pinpoint any issue (don’t hesitate if you need more information, that’s my very first post here):

Computer:
Dell XPS 15 (nvidia 3050ti, i7-11800H, 32Gb RAM) + dock thunderbolt 4
Fedora 38 spin xfce (version 4.18) 

$ uname -a

Linux pc-216.home 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15 02:15:40 UTC 2023 x86_64 GNU/Linux

$ dmesg | grep secure

[    0.000000] secureboot: Secure boot disabled
[    0.007231] secureboot: Secure boot disabled

$ journalctl -b -1

Jun 22 21:15:48 fedora kernel: ------------[ cut here ]------------
Jun 22 21:15:48 fedora kernel: nouveau 0000:01:00.0: timeout
Jun 22 21:15:48 fedora kernel: WARNING: CPU: 13 PID: 1853 at drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:821 gf100_gr_fecs_wfi_golden_save+0x120/0x140 [nouveau]
Jun 22 21:15:48 fedora kernel: Modules linked in: nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables snd_hda_codec_hdmi nfnetlink qrtr bnep sunrpc vfat fat snd>
Jun 22 21:15:48 fedora kernel:  processor_thermal_device_pci_legacy uvcvideo hid_sensor_als usbnet dell_wmi processor_thermal_device btrtl snd_seq irqbypass videobuf2_vmalloc rapl videobuf2_memops snd_seq_device btbcm dell_smbios videobuf2_v4l2 intel_cs>
Jun 22 21:15:48 fedora kernel:  hid_sensor_hub intel_ishtp_hid i915 nouveau nvme rtsx_pci_sdmmc drm_ttm_helper drm_buddy mmc_core mxm_wmi nvme_core drm_display_helper crct10dif_pclmul intel_ish_ipc crc32_pclmul hid_multitouch crc32c_intel video polyval_>
Jun 22 21:15:48 fedora kernel: CPU: 13 PID: 1853 Comm: Xorg Not tainted 6.2.15-200.fc37.x86_64 #1
Jun 22 21:15:48 fedora kernel: Hardware name: Dell Inc. XPS 15 9510/01V4T3, BIOS 1.19.0 03/10/2023
Jun 22 21:15:48 fedora kernel: RIP: 0010:gf100_gr_fecs_wfi_golden_save+0x120/0x140 [nouveau]
Jun 22 21:15:48 fedora kernel: Code: 04 24 48 8b 40 10 48 8b 78 10 48 8b 5f 50 48 85 db 74 20 e8 42 bc 07 ef 48 89 da 48 c7 c7 9b 2e b3 c0 48 89 c6 e8 90 27 6f ee <0f> 0b b8 92 ff ff ff eb ac 48 8b 1f eb db e8 2d 3e 54 ef 66 66 2e
Jun 22 21:15:48 fedora kernel: RSP: 0018:ffffc222442efa00 EFLAGS: 00010286
Jun 22 21:15:48 fedora kernel: RAX: 0000000000000000 RBX: ffffa09c031990d0 RCX: 0000000000000000
Jun 22 21:15:48 fedora kernel: RDX: 0000000000000002 RSI: ffffffffb08c1e1e RDI: 00000000ffffffff
Jun 22 21:15:48 fedora kernel: RBP: 00000000800ffe40 R08: 0000000000000000 R09: ffffc222442ef890
Jun 22 21:15:48 fedora kernel: R10: 0000000000000003 R11: ffffffffb11447c8 R12: 0000000000000000
Jun 22 21:15:48 fedora kernel: R13: ffffa09c0c92a540 R14: ffffa09c1280f800 R15: ffffffffc0b0ef00
Jun 22 21:15:48 fedora kernel: FS:  00007f946342aac0(0000) GS:ffffa0a36f740000(0000) knlGS:0000000000000000
Jun 22 21:15:48 fedora kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 22 21:15:48 fedora kernel: CR2: 00007f9460c4a120 CR3: 0000000148074004 CR4: 0000000000770ee0
Jun 22 21:15:48 fedora kernel: PKRU: 55555554
Jun 22 21:15:48 fedora kernel: Call Trace:
Jun 22 21:15:48 fedora kernel:  <TASK>
Jun 22 21:15:48 fedora kernel:  gf100_grctx_generate+0x64b/0x710 [nouveau]
Jun 22 21:15:48 fedora kernel:  ? nvkm_vram_map+0x56/0x80 [nouveau]
Jun 22 21:15:48 fedora kernel:  gf100_gr_chan_new+0x467/0x4a0 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_cgrp_ectx_get+0x145/0x210 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_cgrp_vctx_get+0xd6/0x2b0 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_chan_cctx_get+0x10d/0x270 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_uchan_object_new+0xd5/0x1f0 [nouveau]
Jun 22 21:15:48 fedora kernel:  ? nvkm_engine_init+0x34/0xa0 [nouveau]
Jun 22 21:15:48 fedora kernel:  ? ktime_get+0x38/0xa0
Jun 22 21:15:48 fedora kernel:  ? nvkm_subdev_init_+0x55/0x130 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_ioctl_new+0x149/0x290 [nouveau]
Jun 22 21:15:48 fedora kernel:  ? __pfx_nvkm_uchan_object_new+0x10/0x10 [nouveau]
Jun 22 21:15:48 fedora kernel:  ? __pfx_gf100_gr_object_new+0x10/0x10 [nouveau]
Jun 22 21:15:48 fedora kernel:  nvkm_ioctl+0x107/0x240 [nouveau]
Jun 22 21:15:48 fedora kernel:  usif_ioctl+0x26a/0x3f0 [nouveau]
Jun 22 21:15:48 fedora kernel:  nouveau_drm_ioctl+0xa1/0xb0 [nouveau]
Jun 22 21:15:48 fedora kernel:  __x64_sys_ioctl+0x8d/0xd0
Jun 22 21:15:48 fedora kernel:  do_syscall_64+0x58/0x80
Jun 22 21:15:48 fedora kernel:  ? syscall_exit_to_user_mode+0x17/0x40
Jun 22 21:15:48 fedora kernel:  ? do_syscall_64+0x67/0x80
Jun 22 21:15:48 fedora kernel:  ? exit_to_user_mode_prepare+0x13a/0x1f0
Jun 22 21:15:48 fedora kernel:  entry_SYSCALL_64_after_hwframe+0x72/0xdc
Jun 22 21:15:48 fedora kernel: RIP: 0033:0x7f9462d61edd
Jun 22 21:15:48 fedora kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
Jun 22 21:15:48 fedora kernel: RSP: 002b:00007fff8ee434a0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Jun 22 21:15:48 fedora kernel: RAX: ffffffffffffffda RBX: 00005612daf38810 RCX: 00007f9462d61edd
Jun 22 21:15:48 fedora kernel: RDX: 00005612daf1c850 RSI: 00000000c0386447 RDI: 0000000000000017
Jun 22 21:15:48 fedora kernel: RBP: 00007fff8ee434f0 R08: 00005612daf36160 R09: 0000000000000000
Jun 22 21:15:48 fedora kernel: R10: 000000000000a140 R11: 0000000000000246 R12: 00005612daf1c850
Jun 22 21:15:48 fedora kernel: R13: 00000000c0386447 R14: 0000000000000017 R15: 0000000000000038
Jun 22 21:15:48 fedora kernel:  </TASK>
Jun 22 21:15:48 fedora kernel: ---[ end trace 0000000000000000 ]---
Jun 22 21:15:48 fedora kernel: nouveau 0000:01:00.0: gr: failed to construct context
Jun 22 21:15:48 fedora kernel: nouveau 0000:01:00.0: fifo:c00000:0001:[Xorg[1853]] ectx 0[gr]: -110
Jun 22 21:15:48 fedora kernel: nouveau 0000:01:00.0: fifo:c00000:0001:0001:[Xorg[1853]] vctx 0[gr]: -110
[...]
Jun 22 21:15:49 pc-216.home abrt-server[2096]: Oops looks like a problem in kernel module, new component xorg-x11-drv-nouveau
Jun 22 21:15:49 pc-216.home abrt-server[2096]: Can't find a meaningful backtrace for hashing in '.'
Jun 22 21:15:49 pc-216.home abrt-server[2096]: Preserving oops '.' because DropNotReportableOopses is 'no'
9

@cforycki Please open a new topic with the tags f38 kernel and nvidia
because you have a different issue: your issue seems at first glance
related to the open source driver of nvidia (which is nouveau). I wonder
if your problem is related to the issue that was just solved at the
nvidia driver but that might be not yet “reverse engineered” to nouveau
(because of the “drm” reference in your logs). If no one with
nvidia/nouveau experience can solve the issue, then this might be worth
a bug report to let the developers know (in this case:
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=kernel&format
and carefully follow the instructions about the necessary information/files/data).

This topic here is not related to nvidia hardware/driver since the
affected user has no nvidia but Intel graphics. Also, it seems that your
machine is able to mount root and add log entries, which is not the case
at the affected user of this topic.

I suggest to add a full log if you open a new topic, with a precise
elaboration of the issue you experience.

10

@py0xc3 I blacklisted every module one by one and tried to boot 6.3.8, but sadly none of the changes made a difference. The system still hangs on boot regardless of what module is blacklisted. Here’s my lsmod output in case you wanted to see it -

Module                  Size  Used by
hid_logitech_hidpp     69632  0
uhid                   20480  1
ufs                   106496  0
hfsplus               172032  0
hfs                   102400  0
minix                  61440  0
msdos                  20480  0
jfs                   258048  0
xfs                  2506752  0
uinput                 20480  0
rfcomm                102400  4
snd_seq_dummy          16384  0
snd_hrtimer            16384  1
nf_conntrack_netbios_ns    16384  1
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nft_fib_inet           16384  1
nft_fib_ipv4           16384  1 nft_fib_inet
nft_fib_ipv6           16384  1 nft_fib_inet
nft_fib                16384  3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
nft_reject_inet        16384  6
nf_reject_ipv4         16384  1 nft_reject_inet
nf_reject_ipv6         24576  1 nft_reject_inet
nft_reject             16384  1 nft_reject_inet
nft_ct                 20480  8
nft_chain_nat          16384  3
nf_nat                 65536  1 nft_chain_nat
nf_conntrack          196608  4 nf_nat,nft_ct,nf_conntrack_netbios_ns,nf_conntrack_broadcast
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
ip_set                 65536  0
nf_tables             348160  229 nft_ct,nft_reject_inet,nft_fib_ipv6,nft_fib_ipv4,nft_chain_nat,nft_reject,nft_fib,nft_fib_inet
nfnetlink              20480  3 nf_tables,ip_set
qrtr                   57344  4
bnep                   36864  2
binfmt_misc            28672  1
vfat                   24576  1
fat                   102400  2 msdos,vfat
snd_sof_pci_intel_tgl    16384  0
snd_sof_intel_hda_common   225280  1 snd_sof_pci_intel_tgl
soundwire_intel        61440  1 snd_sof_intel_hda_common
soundwire_generic_allocation    16384  1 soundwire_intel
soundwire_cadence      45056  1 soundwire_intel
snd_sof_intel_hda      24576  1 snd_sof_intel_hda_common
snd_sof_pci            24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof_xtensa_dsp     20480  1 snd_sof_intel_hda_common
snd_sof               376832  3 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_hda
snd_sof_utils          20480  1 snd_sof
snd_soc_hdac_hda       28672  1 snd_sof_intel_hda_common
snd_hda_ext_core       36864  3 snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda
snd_soc_acpi_intel_match    73728  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_soc_acpi           16384  2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common
intel_rapl_msr         20480  0
soundwire_bus         135168  3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence
intel_rapl_common      36864  1 intel_rapl_msr
x86_pkg_temp_thermal    20480  0
intel_powerclamp       20480  0
snd_soc_core          434176  4 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda
coretemp               20480  0
iwlmvm                610304  0
kvm_intel             434176  0
snd_compress           32768  1 snd_soc_core
snd_hda_codec_hdmi     94208  1
ac97_bus               16384  1 snd_soc_core
snd_pcm_dmaengine      20480  1 snd_soc_core
mac80211             1486848  1 iwlmvm
snd_hda_intel          65536  2
kvm                  1318912  1 kvm_intel
snd_intel_dspcfg       36864  3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common
libarc4                16384  1 mac80211
snd_intel_sdw_acpi     20480  2 snd_sof_intel_hda_common,snd_intel_dspcfg
snd_hda_codec         217088  4 snd_hda_codec_hdmi,snd_hda_intel,snd_soc_hdac_hda,snd_sof_intel_hda
snd_usb_audio         442368  4
irqbypass              16384  1 kvm
snd_hda_core          139264  7 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda
snd_usbmidi_lib        49152  1 snd_usb_audio
iwlwifi               458752  1 iwlmvm
snd_rawmidi            53248  1 snd_usbmidi_lib
mc                     81920  1 snd_usb_audio
snd_hwdep              20480  2 snd_usb_audio,snd_hda_codec
snd_seq               106496  7 snd_seq_dummy
intel_cstate           24576  0
snd_seq_device         16384  2 snd_seq,snd_rawmidi
btusb                  77824  0
dell_wmi               32768  0
snd_pcm               180224  12 snd_hda_codec_hdmi,snd_hda_intel,snd_usb_audio,snd_hda_codec,soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_compress,snd_soc_core,snd_sof_utils,snd_hda_core,snd_pcm_dmaengine
iTCO_wdt               16384  0
btrtl                  28672  1 btusb
btbcm                  24576  1 btusb
intel_pmc_bxt          16384  1 iTCO_wdt
iTCO_vendor_support    16384  1 iTCO_wdt
mei_pxp                20480  0
mei_hdcp               28672  0
btintel                53248  1 btusb
ee1004                 20480  0
dell_smbios            32768  1 dell_wmi
btmtk                  16384  1 btusb
ledtrig_audio          16384  1 dell_wmi
cfg80211             1269760  3 iwlmvm,iwlwifi,mac80211
dell_wmi_sysman        57344  0
dcdbas                 24576  1 dell_smbios
bluetooth            1015808  38 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
snd_timer              53248  3 snd_seq,snd_hrtimer,snd_pcm
i2c_i801               40960  0
intel_uncore          253952  0
sparse_keymap          16384  1 dell_wmi
wmi_bmof               16384  0
pcspkr                 16384  0
dell_wmi_descriptor    20480  2 dell_wmi,dell_smbios
firmware_attributes_class    16384  1 dell_wmi_sysman
mei_me                 61440  2
snd                   143360  28 snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_usb_audio,snd_usbmidi_lib,snd_hda_codec,snd_sof,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_rawmidi
i2c_smbus              20480  1 i2c_i801
idma64                 20480  0
mei                   192512  5 mei_hdcp,mei_pxp,mei_me
rfkill                 40960  9 iwlmvm,bluetooth,cfg80211
soundcore              16384  1 snd
intel_skl_int3472_tps68470    20480  0
tps68470_regulator     16384  0
clk_tps68470           16384  0
intel_skl_int3472_discrete    20480  0
joydev                 28672  0
acpi_tad               20480  0
apple_mfi_fastcharge    20480  0
acpi_pad              184320  0
loop                   36864  0
zram                   45056  2
hid_apple              24576  0
i915                 3768320  10
drm_buddy              20480  1 i915
crct10dif_pclmul       16384  1
crc32_pclmul           16384  0
drm_display_helper    200704  1 i915
crc32c_intel           24576  3
polyval_clmulni        16384  0
polyval_generic        16384  1 polyval_clmulni
nvme                   69632  3
cec                    86016  2 drm_display_helper,i915
nvme_core             221184  4 nvme
ghash_clmulni_intel    16384  0
ucsi_acpi              16384  0
r8169                 114688  0
sha512_ssse3           53248  0
typec_ucsi             61440  1 ucsi_acpi
ttm                   102400  1 i915
nvme_common            24576  1 nvme_core
typec                 106496  1 typec_ucsi
video                  77824  2 dell_wmi,i915
wmi                    45056  6 dell_wmi_sysman,video,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
ip6_tables             40960  0
ip_tables              40960  0
fuse                  204800  3
11

You might re-install Fedora or install a second Fedora (e.g., using an
USB drive or so if you don’t wanna touch the existing installation’s
drive), keep it default (do not install or change anything) but once
installed, update it to the current state, so update everything (kernel
and everything else as well). Then reboot and let’s see if this works
with 6.3.X. If this works, then I suggest to adjust the new installation
to your needs, install your apps, and so on - one by one and regularly
reboot in between to see if any change you do on your system causes the
issue (maybe it’s the interaction of some change(s) you impose and of
6.3.X kernels that cause the issue in conjunction).

If for some reason everything keeps working, then replace the old
installation by the new one. If the issue appears at some point again,
let us know all changes you imposed in between the last working and the
first failed boot.

12

@py0xc3 I did a full reinstall of Fedora and everything went well at first until the system updated to kernel 6.3.8, then I experienced the same black screen issue as before. Unfortunately now I’m stuck on kernel 6.2.9 since that’s the kernel that Fedora 38 shipped with initially. I’m sure I could install kernel 6.2.15 manually, but I’m not sure which packages to install to make that happen.

Every other package (GNOME, other system packages, etc.) updated and is working perfectly, so that’s no problem. I don’t have any programs or packages installed besides what Fedora 38 comes with. Since other users with similar issues were able to get the new kernel to boot on different hardware, I’m guessing my issue is specifically related to my Dell Inspiron 3891 desktop.

13

I opened a new thread a few minutes ago but just realized that I believe I also fall under this issue. For reference, I’m running on a Dell Precision 5560. Glad there are others in the same boat. Here are some details from my end if they’re at all helpful:

  • Booting any of the kernel options listed in GRUB would have the same behavior. When I was originally debugging I had the following kernels installed: 6.3.5-100.fc37, 6.2.9-200.fc37 and 6.2.14-200.fc37. None of these appeared to work, so I went for a last ditch effort and upgraded to Fedora 38. I’m now running on 6.3.8-200.fc38 but still getting hung up on the underscore upon booting.
  • If I hit esc during the boot process I am able to see a failure of dkms.service starting. After doing some digging it appears to be failing due to a failure of compiling evdi/1.12.0.
  • I’ve tried disabling evdi by running dkms remove evdi/1.12.0. This makes dkms.service run successfully in the boot process but I still get the hanging underscore. This makes me wonder if the evdi issue is a red herring for what’s actually going on.
  • I am able to SSH into the machine while it’s hung at the underscore, so I can still work with it/modify things as needed. I’m also able to get to a command line by appending 3 to the end of the GRUB boot command.
  • module_blacklist=ucsi_acpi doesn’t resolve the issue

At this point I’m on the latest version of Fedora with all packages upgraded, so I’m not really sure what else I can do. My machine is pretty bricked and I’m at a loss of what I can do to get it back up and running.

Happy to post additional information/logs if needed, and any help or advice is much appreciated

EDIT: One more data point, I tried downgrading to 3.2.9-300.fc38 as mentioned by @rairai9’s post but am still getting the same issue :frowning:

EDIT: Heck yeah! I also saw issues with nouveau in my journalctl -b -1 log. and tried adding module_blacklist=nouveau to my kernel params in GRUB. This appears to get me back to a working desktop!

I guess it’s not problem solved but this is at least a workaround that unblocks me for the time being. Thanks for the info @cforycki!

14

@rairai9 , to get 6.2.15 again: sudo dnf install https://kojipkgs.fedoraproject.org//packages/kernel/6.2.15/300.fc38/x86_64/kernel-6.2.15-300.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/kernel/6.2.15/300.fc38/x86_64/kernel-core-6.2.15-300.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/kernel/6.2.15/300.fc38/x86_64/kernel-modules-6.2.15-300.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/kernel/6.2.15/300.fc38/x86_64/kernel-modules-core-6.2.15-300.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/kernel/6.2.15/300.fc38/x86_64/kernel-modules-extra-6.2.15-300.fc38.x86_64.rpm

Have you already tried to update your firmware? If not, check out the support page of Dell and get the newest firmware and update. Sometimes vendors provide files that you can update from within Linux with fwupdmgr or so. Sometimes they also provide ISO files that can be burned on a CD/DVD. I’m quite sure you will find details at Dell’s support page what possibilities they provide and how to update properly. I saw there are “critical” BIOS updates for your hardware from 2023.

If nothing of that helps, my next step would be to check if the 6.3.X kernels of Debian 12 Bookworm and Ubuntu 23.04 behave the same (you can test just by installing them on an external USB drive or so). When testing, I suggest to ensure that you use Debian 12 Bookworm / Ubuntu 23.04, and not older versions, to ensure that the first update after installation gets its current 6.3.X kernel.

Since the issue seems so far to not occur on other machines, I indeed see the possibility that it is related to your hardware and/or the firmware. Dell seems to officially support Ubuntu 20.04 on your hardware, which makes me assume that they test it’s firmware and hardware for that os and adjust correspondingly. This Ubuntu release remains with long-term-supported 5.X kernels, so it will not lead them to test and adjust the firmware for 6.3.X atm. At the same time, Ubuntu has a modified kernel that strongly differs from the vanilla (= “original”) Linux kernel (this is why I asked above to test both Debian and Ubuntu).

If nothing of that works and if all 6.3.X kernels have the same issue, I indeed would suggest to switch to a system with a long term supported kernel from before 6.3. At the same time, given its modifications, I could also imagine that the Ubuntu 6.3.X kernel works because it contains proprietary drivers that are not part of the vanilla kernel. My personal preference would be always to stick with the vanilla kernel and its stability and security guarantees, but finally, you have to make this decision for yourself. It’s always a compromise.

Another alternative I can provide is to use a long term supported kernel on Fedora, which you can do by enabling copr and then install long term supported kernels from there → kwizart/kernel-longterm-6.1 Copr. However, be aware that this is not officially supported by Fedora but the service of a single user who keeps providing that already for a long time. However, it might give you the possibility to stick with Fedora and to check from time to time if the officially supported kernels start to work again at some point. I would consider this at the best as an interim solution (I don’t know if / how long that user keeps providing pre-6.3 kernel builds for current Fedora releases) → the official kernel 6.4 would be my next hope to solve your issue. In either case, everything is better than sticking with an obsolete 6.2.15 kernel that no longer receives any updates.

@steog45 Your issue is different: if you can create a connection with SSH, the machine is booted to a higher run level. This differs from Sean’s issue. In Sean’s case, the machine could not even mount the root partition. For example, you can see the logs of the corrupted boot with journalctl --boot=-1, which is not possible in Sean’s case (that’s the major challenge we face here). I saw you closed your topic. I suggest to create a new one. I do not fully understand your elaboration. You might add your logs when creating a new topic, and elaborate first one by one the issue that occurs, and after that mention what you have already tried to mitigate and how the system behaved with these mitigation tries. In case your issue occurs only with specific kernel versions while it does not appear with other kernel versions, please also add the tag kernel .

15

I am also still unable to boot into Fedora with any 6.3 kernel. The screen goes blank, and then my monitor turns on and off repeatedly. It never gets to the password screen to decrypt my hard drive.

Only the old 6.2.15-200.fc37 works.

I’ve tried 6.3.8 with the module_blacklist=ucsi_acpi parameter and only get:
Booting a command list then just the blank screen again. 6.3.8 without the parameter returns the same blank screen.

As I mentioned in previous posts, I am running the open-source AMD drivers on Fedora 37. My Intel laptop doesn’t have any issues.

I am really hoping for a fix. I’ve been running Fedora since version 21, and am worried I will have to switch to a different operating system.

16

@rye Please open a new topic. This topic is only for f38.

(paragraph removed by author)

17

OK. I thought this was the correct thread.

18

@py0xc3 My firmware is up to date according to the latest patch on the Dell support website. I’ve spent the past few weeks testing several distros, including the latest versions of Debian, Arch (with kernel 6.4), and Ubuntu, and the only distro out of those three that I could get to boot the kernel was Ubuntu. Ubuntu 23.04 works on my hardware with its current kernel listed as 6.2.0-24-generic according to uname -r - as far as I can tell, this is the latest official Ubuntu kernel available (I believe Ubuntu handles kernel security issues via separate security patches, all of which I also have up to date).

In order to keep my system as secure as possible, I will stick with Ubuntu for the time being and keep it updated. I will also look out for future firmware updates from Dell and test Fedora again in the future to see if anything changes.

Thank you for all of your help and suggestions over these past several weeks, it is greatly appreciated!

19

I just hit this issue on a brand-new Framework 13 (Intel, Intel graphics) laptop.
Installed Fedora 38, everything works fine (Kernel 6.2.9-300)
Did a full dnf update, which included kernel 6.4.4-200, reboot hangs with black screen. when booting to 6.4.4.
Tried booting with module_blacklist=ucsi_acpi, no change.
Booting with 6.2.9 still works fine.

20

Hello Michael,

What you write does not tell much. Please review the above and other
kernel topics to see what type of information you should provide so
that people here can help.

Please open a new topic for that since I do not yet assume a correlation
between this topic and your issue.