Fedora 38 crashes after resuming from hibernation

Hi folks, first post here, nice to meet you all!

I recently installed Fedora 38 from the standard live .iso with Gnome and out of the box I started encountering some issues after hibernation: every time I hibernate my system (or close the laptop lid) Fedora either doesn’t let me get out of the lockscreen, doesn’t let me get root access in the gnome terminal or crashes as soon as I start an application or open a gnome menu.

This is the log:

I don’t know if there’s a fix available or if it may be useful to the devs, let me know if I’m missing something here to fix this.

When reporting a problem, it is very helpful if you can provide enough detail (hardware platform, update status, using Xorg or wayland, etc.) to allow someone with similar hardware to reproduce the problem (or at least tell you they don’t have the problem, which can help pinpoint the reason).

There are usually some “issues” for fresh installs with things that didn’t get caught in testing, so it is important to install updates. Most uers will hibernate a system with several apps running. It could be useful to see if the problem is specific to one app by closing just one app for each hibernation.

Hi, thanks for your reply,

I am sorry I did not provide the necessary info, below the output of inxi:

[beutemeister@fedora ~]$ sudo inxi -Fxz
  Kernel: 6.2.15-300.fc38.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.39-9.fc38 Console: pty pts/1 Distro: Fedora release 38 (Thirty Eight)
  Type: Laptop System: ASUSTeK product: VivoBook_ASUSLaptop X421EAYB_K413EA
    v: 1.0 serial: <filter>
  Mobo: ASUSTeK model: X421EAYB v: 1.0 serial: <filter> UEFI: American
    Megatrends LLC. v: X421EAYB.202 date: 08/18/2021
  ID-1: BAT0 charge: 40.0 Wh (99.0%) condition: 40.4/42.1 Wh (96.1%)
    volts: 11.8 min: 11.8 model: ASUSTeK ASUS Battery status: discharging
  Info: quad core model: 11th Gen Intel Core i5-1135G7 bits: 64 type: MT MCP
    arch: Tiger Lake rev: 1 cache: L1: 320 KiB L2: 5 MiB L3: 8 MiB
  Speed (MHz): avg: 1537 high: 2400 min/max: 400/4200 cores: 1: 1034 2: 796
    3: 1165 4: 2400 5: 2400 6: 1027 7: 2400 8: 1075 bogomips: 38707
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] vendor: ASUSTeK
    driver: i915 v: kernel arch: Gen-12.1 bus-ID: 0000:00:02.0
  Device-2: Quanta USB2.0 HD UVC WebCam type: USB driver: uvcvideo
    bus-ID: 1-6:2
  Display: server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9 driver:
    dri: iris gpu: i915 note: X driver n/a resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 23.0.3 renderer: Mesa Intel Xe Graphics (TGL GT2)
    direct-render: Yes
  Device-1: Intel Tiger Lake-LP Smart Sound Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 0000:00:1f.3
  API: ALSA v: k6.2.15-300.fc38.x86_64 status: kernel-api
  Server-1: PipeWire v: 0.3.70 status: n/a (root, process)
  Device-1: MEDIATEK MT7921 802.11ax PCI Express Wireless Network Adapter
    vendor: AzureWave driver: mt7921e v: kernel bus-ID: 0000:02:00.0
  IF: wlo1 state: up mac: <filter>
  Device-1: IMC Networks Wireless_Device type: USB driver: btusb v: 0.8
    bus-ID: 1-10:4
  Report: rfkill ID: hci0 rfk-id: 2 state: up address: see --recommends
  Hardware-1: Intel Volume Management Device NVMe RAID Controller driver: vmd
    v: 0.6 bus-ID: 0000:00:0e.0
  Local Storage: total: 476.94 GiB used: 12.23 GiB (2.6%)
  ID-1: /dev/nvme0n1 vendor: Micron model: 2210 MTFDHBA512QFD
    size: 476.94 GiB temp: 33.9 C
  ID-1: / size: 156.43 GiB used: 12.18 GiB (7.8%) fs: ext4 dev: /dev/nvme0n1p6
  ID-2: /boot/efi size: 256 MiB used: 47 MiB (18.4%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-1: swap-1 type: zram size: 7.44 GiB used: 0 KiB (0.0%) dev: /dev/zram0
  ID-2: swap-2 type: partition size: 8 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p7
  System Temperatures: cpu: 40.0 C mobo: N/A
  Fan Speeds (RPM): cpu: 0
  Processes: 278 Uptime: 13m Memory: 7.44 GiB used: 2.45 GiB (33.0%)
  Init: systemd target: graphical (5) Compilers: N/A Packages: 8
  note: see --rpm Shell: Bash v: 5.2.15 inxi: 3.3.26

The issue was there on install and updating with dnf didn’t change anything, I don’t really need to open any application to have the OS crash, I just have to close the lid or leave the computer as is until it goes to sleep (guess you can count all the GNOME processess tho). If it can be useful I can install other DEs to see if the issue is GNOME specific.

By the way, I’m using stock Fedora with GNOME and Wayland.

Kindly hoping in your response, let me know if I can provide more info.

Are you using a Gnome Extension for Hibernation? There is an issue in Gnome Shell 44.0 crashing at logout. I wonder if it also affects hibernation. The fix is expected in early June at Gnome Shell 44.2.

hi, I actually made a rookie mistake. I was referring to sleep, not hibernation .
i installed Lxqt and the bug seems to happen either way regardless of Desktop Environment.
Btw, as I said earlier I’m using stock GNOME, no extensions. Systemd is in charge of putting the OS to sleep so it’s either that or even a kernel problem.
Either way I would like for it to be solved, let me know if you guys have any idea of how to solve this.
Kind regards.

Same here, the intel driver is crashing and is preventing me to wake up my screen from sleep

This happens to me too since I’ve switched NVMe drives and reinstalled. I can sometimes switch to another TTY via CTRL-ALT-F3 (etc) and see kernel errors during this failure regarding storage. I am using a different NVMe device than you and NOT Intel RAID. But I will actually try switching to another NVMe storage device to see if there’s something wrong with these. I was hoping a kernel update would fix this but it seems like no.

Local Storage: total: 476.94 GiB used: 19.03 GiB (4.0%)
ID-1: /dev/nvme0n1 vendor: Silicon Power model: SPCC M.2 PCIe SSD
size: 476.94 GiB temp: 36.9 C

The way to solve such problems is to a) make it possible for others to reproduce the issue, and b) provide relevant error messages.

This requires details of your hardware and software, starting with inxi -Fzx and following up when asked for more details. It also requires making sure all available updates have been applied so you are chasing a bug that has already been fixed and so others will be using the same versions. Journalctl provides a wealth of data (more when run with “root” privileges), so there will often be information about a problem buried in a mass of irrelevant data.

See: How to file a bug.

Many users try to solve bugs by reinstalling Fedora, switching to an older release, or switching to flatpak versions of a failing application. This is understandable when the user has work they need to do, but means the underlying problem remains open.