Gnome 42 - Wayland - hangs at initial ramdisk - starts without NetworkManager

Initially I was planning to add this as a comment on this thread, but I eventually felt like it didn't fit so I decided to toss it into its own thread.

I recently installed Gnome 42 (garuda-gnome-linux-zen-220329) and after reading in the wiki post here which warns that enabling Wayland will break stuff, I had no choice but to immediately enable Wayland. :joy:

I enabled it with Garuda Assistant (Settings -> enable GDM Wayland) and took a reboot. After selecting the grub entry, I got the familiar "Loading Linux linux-zen ... / Loading initial ramdisk ..." message, then the Plymouth screen with the eagle head and the status bar. After the status bar was mostly full, it reverted back to " Loading Linux linux-zen ... / Loading initial ramdisk ..." and got stuck.

I gave it a few minutes just in case, then was going to take Raising Elephants and restore a snapshot to backtrack a little. I only got out the "R" and the "E" when the screen snapped back to life and the login screen (GDM?) came up. I logged in normally and poof, there I was in a Wayland session.

Oddly, I wasn't connected to my network and I quickly discovered that NetworkManager actually wasn't running at all. sudo NetworkManager restart and it popped back on and automatically connected to the network.

I had to look it up because I had forgotten, but Magic SysRq key "R" switches the keyboard from raw to XLATE mode and "E" sends the SIGTERM signal to all processes except init. It appears starting NetworkManager is a process that is getting killed in this case, but other than that I'm not sure if anything is missing. The session seems fine, the obvious things are all working normally.

I took an update and rebooted and discovered the issue recurs exactly: the boot gets stuck at initial ramdisk, Alt+(Print,R,E) breaks it free and login screen loads normally, the session loads without NetworkManager started.

I understand there are still some kinks to be ironed out with the Gnome 42/Wayland stack, and frankly this issue has a very small impact on me personally so I'm not calling for support at all. I just thought I would offer it up to the community in case it would be helpful to troubleshoot. For now, the issue is easily and reliably reproducible.

garuda-inxi
System:
  Kernel: 5.17.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=0e41d854-daa7-4d3e-8607-256fbb8317bb rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: GNOME v: 42.1 tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Laptop System: Framework product: Laptop v: AB
    serial: <superuser required>
  Mobo: Framework model: FRANBMCP0B v: AB serial: <superuser required>
    UEFI: INSYDE v: 03.07 date: 12/14/2021
Battery:
  ID-1: BAT1 charge: 46.7 Wh (84.3%) condition: 55.4/55.0 Wh (100.8%)
    volts: 16.7 min: 15.4 model: NVT Framewo type: Li-ion serial: <filter>
    status: discharging
CPU:
  Info: model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP
    arch: Tiger Lake family: 6 model-id: 0x8C (140) stepping: 1 microcode: 0xA4
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 320 KiB desc: d-4x48 KiB; i-4x32 KiB L2: 5 MiB desc: 4x1.2 MiB
    L3: 12 MiB desc: 1x12 MiB
  Speed (MHz): avg: 609 high: 962 min/max: 400/4700 scaling:
    driver: intel_pstate governor: powersave cores: 1: 700 2: 642 3: 613 4: 444
    5: 590 6: 962 7: 420 8: 501 bogomips: 44851
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
    mitigation: Enhanced IBRS, IBPB: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
    ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4 bus-ID: 00:02.0
    chip-ID: 8086:9a49 class-ID: 0300
  Device-2: Realtek Laptop Camera type: USB driver: uvcvideo bus-ID: 3-7:2
    chip-ID: 0bda:5634 class-ID: 0e02 serial: <filter>
  Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: 0
  Monitor-1: eDP-1 model: BOE Display 0x095f built: 2019 res: 2256x1504
    dpi: 201 gamma: 1.2 size: 285x190mm (11.22x7.48") diag: 343mm (13.5")
    ratio: 3:2 modes: 2256x1504
  Message: Wayland GBM/EGL data currently not available.
Audio:
  Device-1: Intel Tiger Lake-LP Smart Sound Audio driver: snd_hda_intel
    v: kernel alternate: snd_sof_pci_intel_tgl bus-ID: 00:1f.3
    chip-ID: 8086:a0c8 class-ID: 0403
  Sound Server-1: ALSA v: k5.17.6-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.51 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX210/AX211/AX411 160MHz driver: iwlwifi v: kernel
    pcie: gen: 2 speed: 5 GT/s lanes: 1 bus-ID: aa:00.0 chip-ID: 8086:2725
    class-ID: 0280
  IF: wlp170s0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel AX210 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 3-10:4 chip-ID: 8087:0032 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 0 state: down
    bt-service: enabled,running rfk-block: hardware: no software: no
    address: <filter>
Drives:
  Local Storage: total: 931.51 GiB used: 17.08 GiB (1.8%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
    model: WDS100T3X0C-00SJG0 size: 931.51 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 111130WD temp: 41.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 14.64 GiB (19.6%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 953 MiB size: 951.1 MiB (99.80%)
    used: 266.5 MiB (28.0%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 14.64 GiB (19.6%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-4: /var/log raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 14.64 GiB (19.6%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-5: /var/tmp raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 14.64 GiB (19.6%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 18.63 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p4 maj-min: 259:4
  ID-2: swap-2 type: zram size: 15.41 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 40.8 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 304 Uptime: 12m wakeups: 839 Memory: 15.41 GiB
  used: 2.86 GiB (18.6%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 12.1.0 Packages: pacman: 1262 lib: 345 flatpak: 0 Shell: fish v: 3.4.1
  running-in: alacritty inxi: 3.3.15
Garuda (2.6.2-1):
  System install date:     2022-05-07
  Last full system update: 2022-05-11
  Is partially upgraded:   No
  Relevant software:       None
  Windows dual boot:       No/Undetected
  Snapshots:               Snapper
  Failed units:
5 Likes

But if it is a bug somewhere, shouldn't we try to find out and fix it?

:man_shrugging: Yes, I think so. That's why I started up the thread, my friend. Let me know if you have any ideas for how I can dig in and expose the problem a bit; your experience runs quite a bit deeper than mine.

I think it is very unlikely this is an issue with Garuda's implementation, but as you mention it might be worth sending a bug report upstream.

I'm at work now, but when I get home I am planning on firing up a different kernel to see what happens. Let me know if you've got some other thoughts and I'd be more than happy to take a crack at it.

In a general thought,

  • start from a non-Wayland Gnome that works as OOTB (restore snapshot?)
  • log /etc/ files timestamps and file sizes (with a find command or other) in a log file
  • Create the problem :smiley: using the same procedure you did before
  • After rebooting with your tweaks, use the same command/script to create a new similar log
  • Compare the logs with meld
  • Post findings :+1:

Or an easier(?) approach, from your current Wayland system

  • Mount an old snapshot before the problem
  • Compare relevant directories with meld
3 Likes

I have a spare partition on this laptop anyway and I had already renamed the grub file for my first Gnome so I just installed a new one.

  • Installed garuda-gnome-linux-zen-220329
  • Updated with garuda-update
  • Rebooted
garuda-inxi_1
System:
  Kernel: 5.17.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=28ca1792-2901-4ee4-b914-c933a4daf7e0 rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: GNOME v: 42.1 tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Laptop System: Framework product: Laptop v: AB
    serial: <superuser required>
  Mobo: Framework model: FRANBMCP0B v: AB serial: <superuser required>
    UEFI: INSYDE v: 03.07 date: 12/14/2021
Battery:
  ID-1: BAT1 charge: 26.1 Wh (47.0%) condition: 55.5/55.0 Wh (101.0%)
    volts: 15.3 min: 15.4 model: NVT Framewo type: Li-ion serial: <filter>
    status: discharging
CPU:
  Info: model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP
    arch: Tiger Lake family: 6 model-id: 0x8C (140) stepping: 1 microcode: 0xA4
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 320 KiB desc: d-4x48 KiB; i-4x32 KiB L2: 5 MiB desc: 4x1.2 MiB
    L3: 12 MiB desc: 1x12 MiB
  Speed (MHz): avg: 653 high: 964 min/max: 400/4700 scaling:
    driver: intel_pstate governor: powersave cores: 1: 584 2: 883 3: 566 4: 655
    5: 659 6: 479 7: 440 8: 964 bogomips: 44851
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
    mitigation: Enhanced IBRS, IBPB: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
    ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4 bus-ID: 00:02.0
    chip-ID: 8086:9a49 class-ID: 0300
  Device-2: Realtek Laptop Camera type: USB driver: uvcvideo bus-ID: 3-7:2
    chip-ID: 0bda:5634 class-ID: 0e02 serial: <filter>
  Display: x11 server: X.Org v: 21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: :1 screens: 1
  Screen-1: 0 s-res: 2256x1504 s-dpi: 96 s-size: 596x397mm (23.46x15.63")
    s-diag: 716mm (28.19")
  Monitor-1: eDP-1 model: BOE Display 0x095f built: 2019 res: 2256x1504
    hz: 60 dpi: 201 gamma: 1.2 size: 285x190mm (11.22x7.48")
    diag: 343mm (13.5") ratio: 3:2 modes: 2256x1504
  Message: Unable to show GL data. Required tool glxinfo missing.
Audio:
  Device-1: Intel Tiger Lake-LP Smart Sound Audio driver: snd_hda_intel
    v: kernel alternate: snd_sof_pci_intel_tgl bus-ID: 00:1f.3
    chip-ID: 8086:a0c8 class-ID: 0403
  Sound Server-1: ALSA v: k5.17.6-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.51 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX210/AX211/AX411 160MHz driver: iwlwifi v: kernel
    pcie: gen: 2 speed: 5 GT/s lanes: 1 bus-ID: aa:00.0 chip-ID: 8086:2725
    class-ID: 0280
  IF: wlp170s0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel AX210 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 3-10:4 chip-ID: 8087:0032 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 0 state: down
    bt-service: enabled,running rfk-block: hardware: no software: no
    address: <filter>
Drives:
  Local Storage: total: 931.51 GiB used: 10.61 GiB (1.1%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
    model: WDS100T3X0C-00SJG0 size: 931.51 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 111130WD temp: 33.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.35 GiB (13.9%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-2: /boot/efi raw-size: 953 MiB size: 951.1 MiB (99.80%)
    used: 266.7 MiB (28.0%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.35 GiB (13.9%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-4: /var/log raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.35 GiB (13.9%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-5: /var/tmp raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.35 GiB (13.9%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 18.63 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p4 maj-min: 259:4
  ID-2: swap-2 type: zram size: 15.41 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 36.8 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 287 Uptime: 1m wakeups: 310 Memory: 15.41 GiB
  used: 1.38 GiB (9.0%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 12.1.0 Packages: pacman: 1071 lib: 299 flatpak: 0 Shell: fish v: 3.4.1
  default: Bash v: 5.1.16 running-in: gnome-terminal inxi: 3.3.15
e[1;34mGaruda (2.6.2-1):e[0m
e[1;34m  System install date:e[0m     2022-05-12
e[1;34m  Last full system update:e[0m 2022-05-12
e[1;34m  Is partially upgraded:  e[0m No
e[1;34m  Relevant software:      e[0m NetworkManager
e[1;34m  Windows dual boot:      e[0m No/Undetected
e[1;34m  Snapshots:              e[0m Snapper
e[1;34m  Failed units:           e[0m 

Made my first /etc file:

sudo find /etc -type f | sudo xargs stat > etc_find_1.txt

Next:

  • Garuda Assistant -> Settings -> Enable GDM Wayland
  • Reboot
  • Login hangs at "initial ramdisk"
  • Magic SysRq R,E
  • Login to Wayland session.
garuda-inxi_2
System:
  Kernel: 5.17.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=28ca1792-2901-4ee4-b914-c933a4daf7e0 rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: GNOME v: 42.1 tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Laptop System: Framework product: Laptop v: AB
    serial: <superuser required>
  Mobo: Framework model: FRANBMCP0B v: AB serial: <superuser required>
    UEFI: INSYDE v: 03.07 date: 12/14/2021
Battery:
  ID-1: BAT1 charge: 25.3 Wh (45.6%) condition: 55.5/55.0 Wh (101.0%)
    volts: 15.3 min: 15.4 model: NVT Framewo type: Li-ion serial: <filter>
    status: discharging
CPU:
  Info: model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP
    arch: Tiger Lake family: 6 model-id: 0x8C (140) stepping: 1 microcode: 0xA4
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 320 KiB desc: d-4x48 KiB; i-4x32 KiB L2: 5 MiB desc: 4x1.2 MiB
    L3: 12 MiB desc: 1x12 MiB
  Speed (MHz): avg: 638 high: 965 min/max: 400/4700 scaling:
    driver: intel_pstate governor: powersave cores: 1: 831 2: 555 3: 519 4: 684
    5: 482 6: 555 7: 518 8: 965 bogomips: 44851
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
    mitigation: Enhanced IBRS, IBPB: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
    ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4 bus-ID: 00:02.0
    chip-ID: 8086:9a49 class-ID: 0300
  Device-2: Realtek Laptop Camera type: USB driver: uvcvideo bus-ID: 3-7:2
    chip-ID: 0bda:5634 class-ID: 0e02 serial: <filter>
  Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: 0
  Monitor-1: eDP-1 model: BOE Display 0x095f built: 2019 res: 2256x1504
    dpi: 201 gamma: 1.2 size: 285x190mm (11.22x7.48") diag: 343mm (13.5")
    ratio: 3:2 modes: 2256x1504
  Message: Wayland GBM/EGL data currently not available.
Audio:
  Device-1: Intel Tiger Lake-LP Smart Sound Audio driver: snd_hda_intel
    v: kernel alternate: snd_sof_pci_intel_tgl bus-ID: 00:1f.3
    chip-ID: 8086:a0c8 class-ID: 0403
  Sound Server-1: ALSA v: k5.17.6-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.51 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX210/AX211/AX411 160MHz driver: iwlwifi v: kernel
    pcie: gen: 2 speed: 5 GT/s lanes: 1 bus-ID: aa:00.0 chip-ID: 8086:2725
    class-ID: 0280
  IF: wlp170s0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel AX210 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 3-10:4 chip-ID: 8087:0032 class-ID: e001
  Report: bt-adapter note: tool can't run ID: hci0 rfk-id: 0 state: down
    bt-service: enabled,stopped rfk-block: hardware: no software: no
    address: N/A
Drives:
  Local Storage: total: 931.51 GiB used: 10.36 GiB (1.1%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
    model: WDS100T3X0C-00SJG0 size: 931.51 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 111130WD temp: 29.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.1 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-2: /boot/efi raw-size: 953 MiB size: 951.1 MiB (99.80%)
    used: 266.7 MiB (28.0%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.1 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-4: /var/log raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.1 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
  ID-5: /var/tmp raw-size: 74.51 GiB size: 74.51 GiB (100.00%)
    used: 10.1 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p8 maj-min: 259:8
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 18.63 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p4 maj-min: 259:4
  ID-2: swap-2 type: zram size: 15.41 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 33.8 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 272 Uptime: 3m wakeups: 103 Memory: 15.41 GiB
  used: 1.35 GiB (8.8%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 12.1.0 Packages: pacman: 1071 lib: 299 flatpak: 0 Shell: fish v: 3.4.1
  default: Bash v: 5.1.16 running-in: gnome-terminal inxi: 3.3.15
e[1;34mGaruda (2.6.2-1):e[0m
e[1;34m  System install date:e[0m     2022-05-12
e[1;34m  Last full system update:e[0m 2022-05-12
e[1;34m  Is partially upgraded:  e[0m No
e[1;34m  Relevant software:      e[0m None
e[1;34m  Windows dual boot:      e[0m No/Undetected
e[1;34m  Snapshots:              e[0m Snapper
e[1;34m  Failed units:           e[0m 

Made the second /etc file:

sudo find /etc -type f | sudo xargs stat > etc_find_2.txt

Meld was not installed so I installed it real quick (had to restart NetworkManager first), then ran it against etc_find_1.txt and etc_find_2.txt. There were only five hits, so I'll just list them out:

/etc/environment and /etc/gdm/custom.conf were both modified. /etc/gdm/custom.conf gets the WaylandEnable=false line commented out when you enable Wayland. The new entries in /etc/environment do not seem particularly noteworthy, although it does seem odd that the file is basically empty to begin with (see .bak version below).

/etc/environment
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
_JAVA_AWT_WM_NONREPARENTING=1
#MOZ_ENABLE_WAYLAND=1 
EDITOR=/usr/bin/micro
BROWSER=firefox
TERM=alacritty
MAIL=geary
/etc/gdm/custom.conf
# GDM configuration storage

[daemon]
AutomaticLoginEnable=False
# Uncomment the line below to force the login screen to use Xorg
#WaylandEnable=false
DefaultSession=gnome-xorg.desktop

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
#Enable=true

/etc/ld.so.cache did not change, but it was accessed at some point between running find 1 and find 2. I do not know what this file is.

/etc/environment.bak is a new file that was created--makes sense, although as I mentioned the file is basically empty.

/etc/environment.bak
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#

/etc/resolv.conf changed, which at first interested me but then I realized when I restarted NetworkManager to install meld it would have whipped up a fresh copy of resolv.conf so that checks out.

At first glance these findings seem unremarkable to me, but let me know if I'm overlooking something.

I think next I'll throw another kernel in here and see if anything interesting happens.

2 Likes
  • This doesn't make sense for a GDM Wayland setting.
    Disable DefaultSession in custom.conf

  • GDM logs might provide debug info. They are at

/ver/log/gdm/

and I guess they would be the equivalent of Xorg logs, since there is no Xorg running. If OTOH /var/log/Xorg.?.0 exist and their log time was in the Wayland boot, they would also add to our understanding, potentially Xorg was trying to start.

  • If there are no logs, or they are not enough, there is a setting in custom.conf to enable debugging (default: disabled)
[debug]
# Uncomment the line below to turn on debugging
Enable=true
  • You might also try booting to TTY and try starting GDM from there, to get a visualized error effect :rofl: , or just revert failiing changes/tests.

That's for now :smile: Let's play Sherlock! :mag_right:

2 Likes

I commented out the line and took a reboot just in case this could be breaking something (I honestly wasn't sure). However, if this has made a change it is not one that is obvious to me.

garuda-inxi from the Wayland session does mention X.org as a server that is running. Does that seem right?

Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: 0

There are not too many logs in here at the moment. The gdm directory doesn't contain a single file.

ฮป ls -l /var/log
drwx------      - root 21 Apr 06:34 ๏„• audit
drwx--x--x      - root 12 May 18:45 ๏„• gdm
drwxr-xr-x      - root 14 Jan  2021 ๏„• gssproxy
[email protected]     - root 12 May 18:45 ๏„• journal
drwxr-xr-x      - root  6 Dec  2021 ๏„• old
drwx------      - root 28 Apr 01:30 ๏„• private
.rw-------    52k root 13 May 09:49 ๏† boot.log
.rw-rw----      0 root 12 May 18:45 ๏€– btmp
.rw-rw-r--      0 root 12 May 18:45 ๏€– lastlog
.rw-r--r--   118k root 12 May 21:45 ๏† pacman.log
.rw-r-----    36k root 13 May 09:38 ๏† snapper.log
.rw-rw-r--  10.0k root 13 May 09:50 ๏€– wtmp

So:

I'll fire up this debug option and see if we can get anybody to talk. :gun:

UPDATE 1:

This seems a little odd, but after enabling debug mode and rebooting it did not hang at initial ramdisk like usual, but it did automatically load an X11 session for some reason. :face_with_raised_eyebrow:

/etc/gdm/custom.conf has not changed:

# GDM configuration storage

[daemon]
AutomaticLoginEnable=False
# Uncomment the line below to force the login screen to use Xorg
#WaylandEnable=false
#DefaultSession=gnome-xorg.desktop

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
Enable=true

"Enable GDM Wayland" is still checked in Garuda Assistant:

/var/log/ is still completely empty except for boot.log (no errors noted), pacman.log, snapper.log, and wtmp.

I'll see if I can reboot and get back into a Wayland session from the login screen.

UPDATE 2:

I was not able to get back into a Wayland session while the debug mode was enabled.

It seems odd, but something about the debug mode appears to disable Wayland somehow. I tried Zen and LTS kernels (why not :man_shrugging: ) but it boots straight to X11. The cog wheel on the login screen is also missing (the cogwheel gives the option to switch to X11 if you want to when booting Wayland).

When I commented out the debugging line in /etc/gdm/custom.conf and rebooted, I was back to stuck at ramdisk -> Raising Elephants -> login to Wayland without NetworkManager.

:thinking:

1 Like

This setting does not exist in my default Arch package custom.conf :person_shrugging:
There is no man page for gdm to help with settings.

It might mean Xwayland or generally a $DISPLAY existence. I don't know. Mutter takes control after gdm.

Look in ~/.local/share/, in relevant folders. Xorg saves at /xorg/, maybe gdm or other?

Did you check as root? It is not readable by anyone else...

There are some automation rules for gdm, that disable Wayland in some cases. It could be something from those that (wrongly or not) does this.

$ grep "^#"  /usr/lib/udev/rules.d/61-gdm.rules
# identify virtio graphics cards to find passthrough setups
# identify virtio graphics cards to find passthrough setups
# cirrus
# vga
# qxl
# disable Wayland on Hi1710 chipsets
# disable Wayland on Matrox chipsets
# disable Wayland on aspeed chipsets
# disable Wayland if modesetting is disabled
# but keep it enabled for simple framebuffer drivers
# The vendor nvidia driver has multiple modules that need to be loaded before GDM can make an
# informed choice on which way to proceed, so force GDM to wait until NVidia's modules are
# loaded before starting up.
# Check if suspend/resume services necessary for working wayland support is available
# If this machine has an internal panel, take note, since it's probably a laptop
# FIXME: It could be "ghost connectors" make this pop positive for some workstations
# in the wild. If so, we may have to fallback to looking at the chassis type from
# dmi data or acpi
# If this is a hybrid graphics setup, take note
# If this is a hybrid graphics laptop with vendor nvidia driver, disable wayland
# Disable wayland in situation where we're in a guest with a virtual gpu and host passthrough gpu
# Disable wayland when there are multiple virtual gpus
# Disable wayland when nvidia modeset is disabled or when drivers are a lower
# version than 470,
# For versions above 470 but lower than 510 prefer Xorg,
# Above 510, prefer Wayland.
# disable wayland if nvidia-drm modeset is not enabled
# disable wayland for nvidia drivers versions lower than 470
# For nvidia drivers versions Above 510, keep Wayland by default
# For nvidia drivers versions 470-495, prefer Xorg by default

I have some coding to do, so I won't try GDM for now. Maybe later, or someone else would want to test and confirm this issue, or not.
As long as it doesn't seem to be a Garuda settings issue, there is no real rush.
Probably your HW/SW combination, unless others reproduce it... :hammer: :joy:
Gnome devs are smarter than any of us, anyway! :rofl:

2 Likes

Yes, I switched to root and confirmed the directory is empty.

That is interesting. :thinking: I didn't see anything that jumped out at me on this list as far as GDM debug mode goes, but I take your point: there could be something somewhere disabling Wayland on purpose, for any number of reasons.

This thread got me combing through the output of journal -b looking for clues, but it is quite a lengthy file and I have a bit of an untrained eye. I could identify the moment when the sysrq commands were entered, but nothing surrounding that event really stood out to me.

I thought it might be more useful to look at the journal if there were a more pronounced time difference between all the stuff that is working normally, and whatever the system is hanging up on so I took a reboot and left the system "stuck" on the initial ramdisk screen while I took my son to the park to run around like an insane maniac (as he does) before dinner.

When I came back a little over an hour later, sure enough it was still on the initial ramdisk screen. I sent through the sysrq commands and logged in to review the journal -b output. This time I noticed a lengthy series of "state changed new lease" outputs leading up to the sysrq commands:

May 13 17:02:25 fw-gnome NetworkManager[533]: <info>  [1652475745.6991] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:03:19 fw-gnome NetworkManager[533]: <info>  [1652475799.6993] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:04:13 fw-gnome NetworkManager[533]: <info>  [1652475853.6977] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:05:07 fw-gnome NetworkManager[533]: <info>  [1652475907.7023] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:06:02 fw-gnome NetworkManager[533]: <info>  [1652475962.6986] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:06:57 fw-gnome NetworkManager[533]: <info>  [1652476017.7014] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:07:52 fw-gnome NetworkManager[533]: <info>  [1652476072.7075] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:08:47 fw-gnome NetworkManager[533]: <info>  [1652476127.7027] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:08:48 fw-gnome wpa_supplicant[1158]: wlp170s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-56 noise=9999 txrate=245000
May 13 17:08:50 fw-gnome wpa_supplicant[1158]: wlp170s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-56 noise=9999 txrate=245000
May 13 17:08:56 fw-gnome wpa_supplicant[1158]: wlp170s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=245000
May 13 17:09:41 fw-gnome NetworkManager[533]: <info>  [1652476181.7081] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:10:35 fw-gnome NetworkManager[533]: <info>  [1652476235.7015] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:11:30 fw-gnome NetworkManager[533]: <info>  [1652476290.7023] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:12:26 fw-gnome NetworkManager[533]: <info>  [1652476346.7029] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:13:20 fw-gnome NetworkManager[533]: <info>  [1652476400.7036] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:14:16 fw-gnome NetworkManager[533]: <info>  [1652476456.7021] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:15:09 fw-gnome NetworkManager[533]: <info>  [1652476509.7068] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:16:05 fw-gnome NetworkManager[533]: <info>  [1652476565.6837] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:16:59 fw-gnome NetworkManager[533]: <info>  [1652476619.7022] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:17:53 fw-gnome NetworkManager[533]: <info>  [1652476673.7013] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:18:46 fw-gnome NetworkManager[533]: <info>  [1652476726.7035] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:19:39 fw-gnome NetworkManager[533]: <info>  [1652476779.7086] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:20:32 fw-gnome NetworkManager[533]: <info>  [1652476832.7021] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:21:25 fw-gnome NetworkManager[533]: <info>  [1652476885.7051] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:22:20 fw-gnome NetworkManager[533]: <info>  [1652476940.7044] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:23:16 fw-gnome NetworkManager[533]: <info>  [1652476996.7594] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:24:09 fw-gnome NetworkManager[533]: <info>  [1652477049.7146] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:25:04 fw-gnome NetworkManager[533]: <info>  [1652477104.7047] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:25:59 fw-gnome NetworkManager[533]: <info>  [1652477159.7068] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:26:53 fw-gnome NetworkManager[533]: <info>  [1652477213.7086] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:27:48 fw-gnome NetworkManager[533]: <info>  [1652477268.7048] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:28:41 fw-gnome NetworkManager[533]: <info>  [1652477321.7076] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:29:35 fw-gnome NetworkManager[533]: <info>  [1652477375.7603] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:30:30 fw-gnome NetworkManager[533]: <info>  [1652477430.7111] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:31:24 fw-gnome NetworkManager[533]: <info>  [1652477484.7066] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:32:19 fw-gnome NetworkManager[533]: <info>  [1652477539.6799] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:33:12 fw-gnome NetworkManager[533]: <info>  [1652477592.7093] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:34:06 fw-gnome NetworkManager[533]: <info>  [1652477646.7073] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:35:00 fw-gnome NetworkManager[533]: <info>  [1652477700.7195] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:35:55 fw-gnome NetworkManager[533]: <info>  [1652477755.7062] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:36:50 fw-gnome NetworkManager[533]: <info>  [1652477810.7093] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:37:46 fw-gnome NetworkManager[533]: <info>  [1652477866.7117] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:38:41 fw-gnome NetworkManager[533]: <info>  [1652477921.6847] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:39:34 fw-gnome NetworkManager[533]: <info>  [1652477974.7082] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:40:27 fw-gnome NetworkManager[533]: <info>  [1652478027.7083] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:41:22 fw-gnome NetworkManager[533]: <info>  [1652478082.7099] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:42:15 fw-gnome NetworkManager[533]: <info>  [1652478135.7088] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:43:11 fw-gnome NetworkManager[533]: <info>  [1652478191.7068] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:44:04 fw-gnome NetworkManager[533]: <info>  [1652478244.7082] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:44:58 fw-gnome NetworkManager[533]: <info>  [1652478298.7133] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:45:51 fw-gnome NetworkManager[533]: <info>  [1652478351.7114] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:46:45 fw-gnome NetworkManager[533]: <info>  [1652478405.7129] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:47:41 fw-gnome NetworkManager[533]: <info>  [1652478461.7097] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:48:37 fw-gnome NetworkManager[533]: <info>  [1652478517.7100] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:49:33 fw-gnome NetworkManager[533]: <info>  [1652478573.7088] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:50:27 fw-gnome NetworkManager[533]: <info>  [1652478627.7114] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:51:22 fw-gnome NetworkManager[533]: <info>  [1652478682.7118] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:52:15 fw-gnome NetworkManager[533]: <info>  [1652478735.7099] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:53:10 fw-gnome NetworkManager[533]: <info>  [1652478790.7105] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:54:05 fw-gnome NetworkManager[533]: <info>  [1652478845.7129] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:55:01 fw-gnome NetworkManager[533]: <info>  [1652478901.6874] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:55:56 fw-gnome NetworkManager[533]: <info>  [1652478956.7152] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:56:51 fw-gnome NetworkManager[533]: <info>  [1652479011.7123] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:57:47 fw-gnome NetworkManager[533]: <info>  [1652479067.7144] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:58:41 fw-gnome NetworkManager[533]: <info>  [1652479121.7144] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 17:59:36 fw-gnome NetworkManager[533]: <info>  [1652479176.7795] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:00:29 fw-gnome NetworkManager[533]: <info>  [1652479229.6937] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:01:25 fw-gnome NetworkManager[533]: <info>  [1652479285.7180] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:02:19 fw-gnome NetworkManager[533]: <info>  [1652479339.7173] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:03:12 fw-gnome NetworkManager[533]: <info>  [1652479392.7151] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:04:08 fw-gnome NetworkManager[533]: <info>  [1652479448.7194] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:05:01 fw-gnome NetworkManager[533]: <info>  [1652479501.7186] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:05:55 fw-gnome NetworkManager[533]: <info>  [1652479555.7166] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:06:48 fw-gnome NetworkManager[533]: <info>  [1652479608.6890] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:07:43 fw-gnome NetworkManager[533]: <info>  [1652479663.7147] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:08:37 fw-gnome NetworkManager[533]: <info>  [1652479717.7171] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:09:33 fw-gnome NetworkManager[533]: <info>  [1652479773.7170] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:10:27 fw-gnome NetworkManager[533]: <info>  [1652479827.7145] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:11:23 fw-gnome NetworkManager[533]: <info>  [1652479883.7169] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:12:17 fw-gnome NetworkManager[533]: <info>  [1652479937.7138] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:13:13 fw-gnome NetworkManager[533]: <info>  [1652479993.7170] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:14:07 fw-gnome NetworkManager[533]: <info>  [1652480047.6925] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:15:02 fw-gnome NetworkManager[533]: <info>  [1652480102.7168] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:15:58 fw-gnome NetworkManager[533]: <info>  [1652480158.7179] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:16:51 fw-gnome NetworkManager[533]: <info>  [1652480211.7158] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:17:46 fw-gnome NetworkManager[533]: <info>  [1652480266.7182] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:18:42 fw-gnome NetworkManager[533]: <info>  [1652480322.6949] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:19:35 fw-gnome NetworkManager[533]: <info>  [1652480375.7190] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:20:30 fw-gnome NetworkManager[533]: <info>  [1652480430.7248] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:21:25 fw-gnome NetworkManager[533]: <info>  [1652480485.7209] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:22:19 fw-gnome NetworkManager[533]: <info>  [1652480539.7179] dhcp4 (wlp170s0): state changed new lease, address=192.168.0.199
May 13 18:23:02 fw-gnome kernel: sysrq: Keyboard mode set to system default
May 13 18:23:04 fw-gnome kernel: sysrq: Terminate All Tasks
May 13 18:23:04 fw-gnome systemd-journald[299]: Received SIGTERM.
May 13 18:23:04 fw-gnome kernel: fbcon: Taking over console
May 13 18:23:04 fw-gnome bluetoothd[511]: Terminating
May 13 18:23:04 fw-gnome wpa_supplicant[1158]: p2p-dev-wlp170s: CTRL-EVENT-DSCP-POLICY clear_all
May 13 18:23:04 fw-gnome wpa_supplicant[1158]: p2p-dev-wlp170s: CTRL-EVENT-DSCP-POLICY clear_all
May 13 18:23:04 fw-gnome wpa_supplicant[1158]: nl80211: deinit ifname=p2p-dev-wlp170s disabled_11b_rates=0
May 13 18:23:04 fw-gnome NetworkManager[533]: <info>  [1652480584.6689] caught SIGTERM, shutting down normally.
May 13 18:23:04 fw-gnome avahi-daemon[509]: Got SIGTERM, quitting.
May 13 18:23:04 fw-gnome boltd[549]: Error releasing name org.freedesktop.bolt: The connection is closed
May 13 18:23:04 fw-gnome ModemManager[548]: <info>  caught signal, shutting down...
May 13 18:23:04 fw-gnome audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-oomd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 13 18:23:04 fw-gnome kernel: audit: type=1131 audit(1652480584.671:127): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-oomd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 13 18:23:04 fw-gnome systemd[1]: systemd-oomd.service: Deactivated successfully.
May 13 18:23:04 fw-gnome audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetooth comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 13 18:23:04 fw-gnome avahi-daemon[509]: Leaving mDNS multicast group on interface wlp170s0.IPv6 with address 2601:18d:4500:4b00::b9f3.
May 13 18:23:04 fw-gnome kernel: audit: type=1131 audit(1652480584.672:128): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetooth comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 13 18:23:04 fw-gnome systemd[1]: systemd-oomd.service: Consumed 4.825s CPU time.
May 13 18:23:04 fw-gnome avahi-daemon[509]: Leaving mDNS multicast group on interface wlp170s0.IPv4 with address 192.168.0.199.

That is obviously just a snippet of the journal; I tossed the whole file into the pastepin if anyone fancies a peek: PrivateBin

I'm sure this message was there before when I reviewed the log, just not quite so many. A new NetworkManager/"state changed new lease" entry is listed every minute or so for the whole time we were at the park.

I started thinking maybe the issue is related to the network card in the laptop. Bizarre, I would say (because what business does Wayland have interfering with the network card?), but then again NetworkManager appears to be the only service not starting when broken out of the initial ramdisk and into the Wayland session.

I decided to test by installing garuda-gnome-linux-zen-220329 on a spare partition on my desktop system, which has an altogether different hardware setup including an older network card.

garuda-inxi_1
System:
  Kernel: 5.17.4-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 11.2.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=88c89965-3e83-4577-98e3-3cd4995696f8 rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: GNOME v: 42.1 tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Desktop Mobo: ASRock model: H310M-STX serial: <superuser required>
    UEFI: American Megatrends v: P4.40 date: 01/13/2020
CPU:
  Info: model: Intel Core i5-9400 bits: 64 type: MCP arch: Coffee Lake
    family: 6 model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xEC
  Topology: cpus: 1x cores: 6 smt: <unsupported> cache: L1: 384 KiB
    desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB L3: 9 MiB
    desc: 1x9 MiB
  Speed (MHz): avg: 3996 high: 4001 min/max: 800/4100 scaling:
    driver: intel_pstate governor: powersave cores: 1: 3995 2: 3997 3: 3988
    4: 3999 5: 4001 6: 4000 bogomips: 34798
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf
    mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: disabled, RSB filling
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] vendor: ASRock
    driver: i915 v: kernel ports: active: DP-1 empty: DP-2,HDMI-A-1,HDMI-A-2
    bus-ID: 00:02.0 chip-ID: 8086:3e92 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: :1 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 96 s-size: 677x381mm (26.65x15.00")
    s-diag: 777mm (30.58")
  Monitor-1: DP-1 model: Acer EB321HQU C serial: <filter> built: 2020
    res: 2560x1440 hz: 60 dpi: 93 gamma: 1.2 size: 699x393mm (27.52x15.47")
    diag: 802mm (31.6") ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Message: Unable to show GL data. Required tool glxinfo missing.
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: ASRock driver: snd_hda_intel
    v: kernel alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:1f.3
    chip-ID: 8086:a348 class-ID: 0403
  Device-2: GEMBIRD Honk HK-5002 USB Speaker type: USB
    driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-6:4 chip-ID: 1908:2070
    class-ID: 0300 serial: <filter>
  Sound Server-1: ALSA v: k5.17.4-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.51 running: yes
Network:
  Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: kernel
    port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15bc class-ID: 0200
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-2: Intel Dual Band Wireless-AC 3168NGW [Stone Peak]
    driver: iwlwifi v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1
    bus-ID: 02:00.0 chip-ID: 8086:24fb class-ID: 0280
  IF: wlp2s0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel Wireless-AC 3168 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-14:6 chip-ID: 8087:0aa7 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 1 state: down
    bt-service: enabled,running rfk-block: hardware: no software: no
    address: <filter>
Drives:
  Local Storage: total: 1.36 TiB used: 10.1 GiB (0.7%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
    model: WDS100T2B0C-00PXH0 size: 931.51 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 211210WD temp: 51.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 500GB
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
    type: SSD serial: <filter> rev: 4B6Q
Partition:
  ID-1: / raw-size: 74.7 GiB size: 74.7 GiB (100.00%) used: 10.1 GiB (13.5%)
    fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-2: /boot/efi raw-size: 1.86 GiB size: 1.86 GiB (99.80%)
    used: 521.2 MiB (27.4%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.1 GiB (13.5%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-4: /var/log raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.1 GiB (13.5%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-5: /var/tmp raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.1 GiB (13.5%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 18.63 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p7 maj-min: 259:7
  ID-2: swap-2 type: zram size: 15.3 GiB used: 256 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 47.0 C pch: 64.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 254 Uptime: 8m wakeups: 0 Memory: 15.3 GiB
  used: 1.91 GiB (12.5%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 12.1.0 Packages: pacman: 1071 lib: 299 flatpak: 0 Shell: fish v: 3.4.1
  default: Bash v: 5.1.16 running-in: gnome-terminal inxi: 3.3.15
e[1;34mGaruda (2.6.2-1):e[0m
e[1;34m  System install date:e[0m     2022-05-13
e[1;34m  Last full system update:e[0m 2022-05-13 e[1;31mโ†ป
e[1;34m  Is partially upgraded:  e[0m No
e[1;34m  Relevant software:      e[0m NetworkManager
e[1;34m  Windows dual boot:      e[0m No/Undetected
e[1;34m  Snapshots:              e[0m Snapper
e[1;34m  Failed units:           e[0m 
  • Installed
  • Updated
  • Enabled GDM Wayland in Garuda Assistant
  • Reboot

And...it logs into the Wayland session just fine. :man_shrugging:

garuda-inxi_2
System:
  Kernel: 5.17.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=88c89965-3e83-4577-98e3-3cd4995696f8 rw [email protected]
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: GNOME v: 42.1 tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM v: 42.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Desktop Mobo: ASRock model: H310M-STX serial: <superuser required>
    UEFI: American Megatrends v: P4.40 date: 01/13/2020
CPU:
  Info: model: Intel Core i5-9400 bits: 64 type: MCP arch: Coffee Lake
    family: 6 model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xF0
  Topology: cpus: 1x cores: 6 smt: <unsupported> cache: L1: 384 KiB
    desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB L3: 9 MiB
    desc: 1x9 MiB
  Speed (MHz): avg: 800 min/max: 800/4100 scaling: driver: intel_pstate
    governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800
    bogomips: 34798
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf
    mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: disabled, RSB filling
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] vendor: ASRock
    driver: i915 v: kernel ports: active: DP-1 empty: DP-2,HDMI-A-1,HDMI-A-2
    bus-ID: 00:02.0 chip-ID: 8086:3e92 class-ID: 0300
  Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa gpu: i915 display-ID: 0
  Monitor-1: DP-1 model: Acer EB321HQU C serial: <filter> built: 2020
    res: 2560x1440 dpi: 93 gamma: 1.2 size: 699x393mm (27.52x15.47")
    diag: 802mm (31.6") ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Message: Wayland GBM/EGL data currently not available.
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: ASRock driver: snd_hda_intel
    v: kernel alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:1f.3
    chip-ID: 8086:a348 class-ID: 0403
  Device-2: GEMBIRD Honk HK-5002 USB Speaker type: USB
    driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-6:4 chip-ID: 1908:2070
    class-ID: 0300 serial: <filter>
  Sound Server-1: ALSA v: k5.17.6-zen1-1-zen running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.51 running: yes
Network:
  Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: kernel
    port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15bc class-ID: 0200
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-2: Intel Dual Band Wireless-AC 3168NGW [Stone Peak]
    driver: iwlwifi v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1
    bus-ID: 02:00.0 chip-ID: 8086:24fb class-ID: 0280
  IF: wlp2s0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel Wireless-AC 3168 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-14:6 chip-ID: 8087:0aa7 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 2 state: down
    bt-service: enabled,running rfk-block: hardware: no software: no
    address: <filter>
Drives:
  Local Storage: total: 1.36 TiB used: 10.44 GiB (0.7%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
    model: WDS100T2B0C-00PXH0 size: 931.51 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 211210WD temp: 45.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 500GB
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
    type: SSD serial: <filter> rev: 4B6Q
Partition:
  ID-1: / raw-size: 74.7 GiB size: 74.7 GiB (100.00%) used: 10.44 GiB (14.0%)
    fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-2: /boot/efi raw-size: 1.86 GiB size: 1.86 GiB (99.80%)
    used: 521.2 MiB (27.4%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.44 GiB (14.0%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-4: /var/log raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.44 GiB (14.0%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
  ID-5: /var/tmp raw-size: 74.7 GiB size: 74.7 GiB (100.00%)
    used: 10.44 GiB (14.0%) fs: btrfs dev: /dev/nvme0n1p19 maj-min: 259:19
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 18.63 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/nvme0n1p7 maj-min: 259:7
  ID-2: swap-2 type: zram size: 15.3 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 36.0 C pch: 61.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 242 Uptime: 1h 41m wakeups: 44 Memory: 15.3 GiB
  used: 2.64 GiB (17.3%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 12.1.0 Packages: pacman: 1071 lib: 299 flatpak: 0 Shell: fish v: 3.4.1
  default: Bash v: 5.1.16 running-in: gnome-terminal inxi: 3.3.15
Garuda (2.6.2-1):
  System install date:     2022-05-13
  Last full system update: 2022-05-13
  Is partially upgraded:   No
  Relevant software:       NetworkManager
  Windows dual boot:       No/Undetected
  Snapshots:               Snapper
  Failed units:     

No hanging at the Plymouth screen, no sysreq intervention required, it just boots normally.

So...my suspicious eye has come to rest on the relatively new network card (Intel Wi-Fi 6E AX210) in the laptop, although it is still rather unclear to me what is happening.

It doesn't seem like Wayland is to blame, because not only does that just seem insane but also my primary installation on this device is Garuda Sway. I haven't lifted a finger configuring the network card on Sway, it worked OOTB and has never so much as flinched.

Buried in the Gnome/Wayland stack somewhere, something gets changed when you enable GDM that appears to have an effect on the kernel or firmware level. :thinking:

1 Like

Blacklist the iwlwifi module to test if your wifi is responsible. If you can then boot into wayland successfully, manually modprobe iwlwifi to initiate your network connection.

1 Like

Do as @tbg suggests. It could be that.

From the logs, it seems Wayland is tried first and fails. Gnome/gdm error out and then try Xorg, which also fails. After reset, it seems to work, so it's not a terminal/final error. Messages talk about drm something. Maybe a Gnome bug, or network, which seems to start errors.

Relevant log


May 13 16:46:46 fw-gnome gnome-shell[717]: Running GNOME Shell (using mutter 42.1) as a Wayland display server
May 13 16:46:46 fw-gnome NetworkManager[533]: <info>  [1652474806.3470] device (wlp170s0): set-hw-addr: set MAC address to 1E:71:53:A0:29:A7 (scanning)
May 13 16:46:46 fw-gnome kernel: iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
May 13 16:46:46 fw-gnome kernel: iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
May 13 16:46:46 fw-gnome kernel: iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
May 13 16:46:46 fw-gnome gnome-shell[717]: Failed to open atomic modesetting backend: GDBus.Error:System.Error.EBUSY: Device or resource busy
May 13 16:46:46 fw-gnome gnome-shell[717]: g_hash_table_destroy: assertion 'hash_table != NULL' failed
May 13 16:46:46 fw-gnome gnome-shell[717]: Failed to open legacy modesetting backend: GDBus.Error:System.Error.EBUSY: Device or resource busy
May 13 16:46:46 fw-gnome gnome-shell[717]: Failed to open gpu '/dev/dri/card0': No suitable mode setting backend found
May 13 16:46:46 fw-gnome org.gnome.Shell.desktop[717]: Failed to setup: No GPUs found
May 13 16:46:46 fw-gnome gnome-session[640]: gnome-session-binary[640]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
May 13 16:46:46 fw-gnome gnome-session-binary[640]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
May 13 16:46:46 fw-gnome gnome-session-binary[640]: Unrecoverable failure in required component org.gnome.Shell.desktop

I hate to admit it, but I really fumbled with trying to get this module blacklisted.

Following along with the wiki post here, I made file /etc/modprobe.d/bl_iwlwifi.conf and added blacklist iwlwifi, then regenerated the initramfs using sudo mkinitcpio -P and rebooted.

This did not change the broken Plymouth experience, and after logging in mkinitcpio -M still listed iwlwifi. No problem; the wiki notes:

Note: The blacklist command will blacklist a module so that it will not be loaded automatically, but the module may be loaded if another non-blacklisted module depends on it or if it is loaded manually.

However, there is a workaround for this behaviour; the install command instructs modprobe to run a custom command instead of inserting the module in the kernel as normal, so you can force the module to always fail loading with:

/etc/modprobe.d/blacklist.conf

... install module_name /bin/true ...

This will effectively blacklist that module and any other that depends on it.

I added install iwlwifi /bin/true to my bl_iwlwifi.conf, regenerated the initramfs again and rebooted.

This also did not affect the Plymouth hang, and mkinitcpio -M still listed iwlwifi. I started wondering if sudo mkinitcpio -P was perhaps the incorrect way to regenerate the initramfs, and after reading through the man pages a little I switched to sudo mkinitcpio -p linux-zen, but this did not yield a different result.

I tried commenting out the "blacklist" line, thinking perhaps I am not supposed to have both the "blacklist" and "install" lines, but that did not appear to change anything. I found this old post that says to use install module /bin/false (instead of /bin/true) so I tried that. It's unclear to me if this distinction makes any difference.

After running through all possible combinations of these noted variations, I started to wonder if mkinitcpio -M was a reliable method for determining if the module was blacklisted (perhaps it shows up on the module list whether it is blacklisted or not?) so I checked lspci -v and found this output:

aa:00.0 Network controller: Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a)
	Subsystem: Intel Corporation Wi-Fi 6 AX210 160MHz
	Flags: bus master, fast devsel, latency 0, IRQ 17, IOMMU group 18
	Memory at 7a200000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Hmm...doesn't look blacklisted, does it?

But then I restarted NetworkManager are fired up the browser to discover that it was not connected to my network, and oh by the way WiFi is not even an option in the network settings. :expressionless:

I backtracked and commented out the install iwlwifi /bin/false line (leaving just the blacklist line) and the behavior was the same--no change to Plymouth/login/NetworkManager situation, but WiFi is not an available resource.

So I guess the blacklist is working correctly? I was expecting it to be a bit more obvious--for example, that it would come off of the mkinitcpio -M and lspci -v outputs--but there is no denying that blacklisting the module takes the network card down.

All that to say, it looks like WiFi is perhaps not responsible for the Plymouth/initial ramdisk hang after all. :man_shrugging:

3 Likes

That was expected. It doesn't make sense a network driver to break GDM or other video module.
Nevertheless, you may want to know about a bug with this (I think) wifi card/module. There are some wacky workarounds, but the bug is open.

I would suggest to test sddm and/or kde, or lightdm, to see if it is gdm only or gnome.

My experience with wayland in the past was aweful and I recently tried again gnome and kde in Wayland. They feel very stable and improved, with kde having more small usability issues.
I say this because my video setup is far from usual/normal and still Wayland works fine.
I use LightDM and can start any DM, any session type with the same user account, on a desktop with Intel and nvidia390, one monitor on each GPU output, without issues.
I don't know if GDM has to start in Wayland or in Xorg, or which is better. I don't listen to Gnome KDE devs. I just use what works best for my workflow and that is BSPWM.

A last thought is to check Intel gpu troubleshooting, for possible workarounds, something like this or this.

1 Like

That is curious about the WiFi card bug--I have never had any issues with it myself (unless you count this weird GDM thing) although I do know there are two versions of the AX210--one is the "vPro". The vPro version enables a bunch of enterprise-specific functionality that is apparently rather broken on Linux. Some poor folks scooped up the vPro thinking the "pro" meant it was better, but then they have trouble getting normal functionality out of it.

In the bug report, not a single person mentions one way or the other which version they are using, so it makes me wonder if perhaps some of those folks
are running the vPro not realizing it's not fully supported on Linux. :man_shrugging:

That first link appears to be related to Xorg configuration. The second link says:

If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add i915 and intel_agp to the initramfs.

I started to look into this, but it appears those modules are included in the initramfs by default. I am not certain, but is it possible Garuda does not use "late start" KMS?

I spent about an hour reading through @SonarMonkey's exhaustive Gnome/GDM/Wayland threads again (by the way, I haven't seen him in a while...) searching for clues I may have missed before circling back to this:

I slapped SDDM on the box and wouldn't you know it? It boot up just fine. Gnome warned me that the lock screen will be disabled because it relies on GDM, but other than that it works--no hang on initial ramdisk. Correct me if I am misinterpreting this, but that seems to strongly imply the misconfiguration lies in GDM.

Is there any way to review specifically what happens when a user checks the box in Garuda Assistant -> Settings -> Enable GDM Wayland? The user-facing changes appear to be limited to commenting out the one line in /etc/gdm/custom.conf, and that's pretty much it. But there must be something else happening.

The reason I ask is because if the way the Garuda tool implements Wayland on Gnome has a problem, perhaps we could find it and fix it. If not, I guess I'm at the point where maybe I'll just collect my notes, put together a bug report for Gnome, and...move on with my life! :stuck_out_tongue_winking_eye:

2 Likes

We have already checked that.
It just runs one of the two scripts on/off

IIRC while they are included, they start later, while adding them in MODULES, makes them start early. Having tested so far, you might want to test this as well... :smile:

I hear rumors that... He's Back! :joy:

I see what you mean--the script is very simple, not really any room for unintended consequences.

How come MOZ_ENABLE_WAYLAND=1 is a commented out line on the Wayland enable script? I'm just curious; it seems like it should be on (I'm guessing it was causing problems somewhere?).

I've read through the initramfs material a few time trying to figure out if I am missing something, but I guess I'm still thinking these are listed in "modules" and should be starting early.

This is the first chunk of my /etc/mkinitcpio.conf:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(crc32c-intel intel_agp i915 amdgpu radeon nouveau)
MODULES=(crc32c-intel intel_agp i915 amdgpu radeon nouveau)

i915 and intel_agp are already listed there (I did not add them).

Am I looking at the right thing?


Small update:

Instead of breaking the initial ramdisk hang with the sysreq SIGTERM, if I switch to tty2, log in, and run

sudo systemctl restart gdm.service

it pops right to the normal GDM login screen. From there, logging in (again) loads a proper Gnome desktop in a Wayland session.

I'm not sure why I didn't think to try this sooner, just from a troubleshooting standpoint. Obviously this isn't much of an improvement; it's just as hacky as the sysreq/login/sudo NetworkManager restart method (and about twice as much typing, if you count the double login), although logging in with this method has the benefit of automatically connecting to the network (since NetworkManager never gets killed off).

It seems the NetworkManager/state changed new lease error message is a red herring; the GDM service is what hangs.

This almost sounds like a race condition is happening. I am not familiar with Gnome in the least as I have always been a KDE fan since day 1 using Linux. My take on this is that perhaps adding a 2 or 3 second delay before starting the GDM service may help work around this issue. Sure that's still hacky, but at least it won't require any more manual intervention if you use a systemd drop in.

2 Likes

lol--neither am I. It's kind of a nightmare. :joy:

I am interested in trying this, however this is a bit beyond my depth. I don't think I have ever heard of a systemd drop in until now. I've read through this, which is clear enough and led me to discover sudo systemctl edit gdm:

### Editing /etc/systemd/system/gdm.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file



### Lines below this comment will be discarded

### /usr/lib/systemd/system/gdm.service
# [Unit]
# Description=GNOME Display Manager
# 
# # replaces the getty
# [email protected]
# [email protected]
# 
# # replaces plymouth-quit since it quits plymouth on its own
# Conflicts=
# After=
# 
# # Needs all the dependencies of the services it's replacing
# # pulled from [email protected] and 
# # (except for plymouth-quit-wait.service since it waits until
# # plymouth is quit, which we do)
# After=rc-local.service plymouth-start.service systemd-user-sessions.service
# 
# # GDM takes responsibility for stopping plymouth, so if it fails
# # for any reason, make sure plymouth still stops
# OnFailure=plymouth-quit.service
# 
# [Service]
# ExecStart=/usr/bin/gdm
# KillMode=mixed
# Restart=always
# IgnoreSIGPIPE=no
# BusName=org.gnome.DisplayManager
# EnvironmentFile=-/etc/locale.conf
# ExecReload=/bin/kill -SIGHUP $MAINPID
# KeyringMode=shared
# 
# [Install]
# Alias=display-manager.service

It looks like a nice easy way to make a drop-in file, with some suggested lines and everything. Nice!

I noticed the "restart" option mentioned in both the edit gdm file and the wiki post, which sounded like it might work so I tossed this in there:

[Service]
Restart=always
RestartSec=10

It did not work, although I honestly am not sure how to even check if this syntax is correct, or if what I am asking for is what I think I am asking for.

I backed up and took a look here to investigate the "wait" command--that seems like it would be a cleaner solution anyhow--but I'm not sure how to introduce this command into the drop-in file.

If the wait utility is invoked with no operands, it shall wait until all process IDs known to the invoking shell have terminated and exit with a zero exit status.

Okay, fine--that sounds good. But to use the wait command it looks like you are meant to specify a PID. I'm not certain there is a way to determine what the PID of GDM will be, is there?

I read a little further into the wait man pages, but it quickly gets a bit dense (my understanding of bash scripting is very rudimentary).

Hoping to get lucky, I tossed wait (just the single word, by itself :man_shrugging: ) into the edit gdm file but I'm afraid it's not quite that simple.

Do you have any advice for how to set this up properly?

2 Likes

I suspect (and hope...) you haven't added any of those yourself. Else, explain why did you add crc32c-intel. Read this.
Since you have an Intel gpu, I would suggest removing all those modules and rebuild images.
Unless you need amdgpu, nouveau, radeon, which suggests you are... hiding some critical info :rofl:

Restart=always is already the same, so it would not be needed, if you finally create a drop-in.

Wise choice, Watson! :joy: Wrong translation of mine :sob: Don't play with those things... unless you know what you are doing.

1 Like

All that is required to add a start up delay is to add a sleep before GDM is started.

Example:

 [Service]
ExecStart=/usr/bin/sleep 3
ExecStart=/usr/bin/gdm
1 Like