Fedora 42 Live Media: Freeze on Dell Precision 5490

Ask Fedora
, , ,
1

Hello community!

Today I’d like to try Fedora 42 on my Dell Precision 5490, but unfortunately it freezes right after the desktop loads…

No CTRL+ALT+Fn; no capslock toggle.

I tried sending SysRq+E to kill all running processes - it worked. Of course I rebooted with sysrq_always_enabled. Now I can see on the console that the task has been killed - but very slowly, about one process/thread every ~10 seconds.

I’m trying to get a working/responsive console now to capture some logs. is there anything else I can do? Are there any “safe mode” boot args I can try?

Edit: Also shim “repairs” the boot-loader while booting right from the Live media, adding a “Fedora” Boot Entry to the EFI System. This shouldn’t happen (see Boot0008 record).

liveuser@localhost-live:~$ efibootmgr 
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0008,0003,0002,0001,0000,0004,0005,0006,0007
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00001 	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option}
Boot0002* UEFI Misc Device	PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0){auto_created_boot_option}
Boot0003* Fedora	HD(1,GPT,8bd69b14-685b-4bba-bec4-2676746c1bba,0x800,0x12c000)/\EFI\fedora\shimx64.efi
Boot0004* UEFI PXEv4 (MAC:5254003A108E)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003a108e,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option}
Boot0005* UEFI PXEv6 (MAC:5254003A108E)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003a108e,1)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option}
Boot0006* UEFI HTTPv4 (MAC:5254003A108E)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003a108e,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
Boot0007* UEFI HTTPv6 (MAC:5254003A108E)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003a108e,1)/IPv6([::],0,Static,[::],[::],64)/Uri(){auto_created_boot_option}
Boot0008* Fedora	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/CDROM(1,0x118c48,0xf000)/\EFI\fedora\shimx64.efi
liveuser@localhost-live:~$
2

Latest Nightly ISO Build works. But the Shim-Bug is still present.

3

Please be more precise and use tags to indicate your edition/spin.

Please give us also more information about your system like inxi -Fzxx and post it as pre-formated text </>.

4

Thanks for your reply - it looks like my edits weren’t saved. This happens in both editions: Workstation and Kde.

As I said, the latest nightly (Fedora-42-20250407.n.0) works, so I think it’s something to do with the shipped kernel and has already been fixed.

Inxi Output: 
System:
  Kernel: 6.14.0-63.fc42.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 15.0.1
  Desktop: GNOME v: 48.0 tk: GTK v: 3.24.49 wm: gnome-shell dm: GDM
    Distro: Fedora Linux 42 (Workstation Edition Prerelease)
Machine:
  Type: Laptop System: Dell product: Precision 5490 v: N/A
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: Dell model: 0MDP90 v: A00 serial: <superuser required> part-nu: 0CC7
    UEFI: Dell v: 1.10.1 date: 12/23/2024
Battery:
  ID-1: BAT0 charge: 64.9 Wh (100.0%) condition: 64.9/70.6 Wh (91.8%)
    volts: 16.8 min: 15.4 model: SMP DELL YXP8T43F serial: <filter>
    status: not charging
CPU:
  Info: 16-core (6-mt/10-st) model: Intel Core Ultra 7 165H bits: 64
    type: MST AMCP arch: Meteor Lake rev: 4 cache: L1: 1.6 MiB L2: 18 MiB
    L3: 24 MiB
  Speed (MHz): avg: 1694 min/max: 400/4700:5000:3800:2500 cores: 1: 1694
    2: 1694 3: 1694 4: 1694 5: 1694 6: 1694 7: 1694 8: 1694 9: 1694 10: 1694
    11: 1694 12: 1694 13: 1694 14: 1694 15: 1694 16: 1694 17: 1694 18: 1694
    19: 1694 20: 1694 21: 1694 22: 1694 bogomips: 135168
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel Meteor Lake-P [Intel Arc Graphics] vendor: Dell driver: i915
    v: kernel arch: Xe-LPG ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4
    bus-ID: 0000:00:02.0 chip-ID: 8086:7d55
  Display: wayland server: Xwayland v: 24.1.6 compositor: gnome-shell
    driver: gpu: i915 display-ID: 0
  Monitor-1: eDP-1 model: AU Optronics 0x4f9b res: 2560x1600 dpi: 216
    diag: 355mm (14")
  API: OpenGL v: 4.6 vendor: intel mesa v: 25.0.2 glx-v: 1.4 es-v: 3.2
    direct-render: yes renderer: Mesa Intel Arc Graphics (MTL)
    device-ID: 8086:7d55 display-ID: :0.0
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
  Info: Tools: api: glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel Meteor Lake IPU vendor: Dell driver: intel-ipu6
    bus-ID: 0000:00:05.0 chip-ID: 8086:7d19
  Device-2: Intel Meteor Lake-P HD Audio vendor: Dell
    driver: sof-audio-pci-intel-mtl bus-ID: 0000:00:1f.3 chip-ID: 8086:7e28
  API: ALSA v: k6.14.0-63.fc42.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.4.1 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin
Network:
  Device-1: Intel Wi-Fi 7 AX1775 /AX1790 /BE20 /BE401/BE1750 2x2
    driver: iwlwifi v: kernel bus-ID: 0000:01:00.0 chip-ID: 8086:272b
  IF: wlp1s0f0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel driver: btusb v: 0.8 type: USB rev: 2.0 speed: 12 Mb/s
    lanes: 1 bus-ID: 3-10:4 chip-ID: 8087:0036
  Report: btmgmt ID: hci0 rfk-id: 2 state: up address: <filter> bt-v: 5.4
    lmp-v: 13
RAID:
  Hardware-1: Intel Volume Management Device NVMe RAID Controller Intel
    driver: vmd v: 0.6 bus-ID: 0000:00:0e.0 chip-ID: 8086:7d0b
Drives:
  Local Storage: total: 476.94 GiB used: 4.1 GiB (0.9%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: PM9A1 NVMe 512GB
    size: 476.94 GiB speed: 63.2 Gb/s lanes: 4 serial: <filter> temp: 31.9 C
Partition:
  ID-1: / size: 475.34 GiB used: 3.83 GiB (0.8%) fs: btrfs dev: /dev/dm-0
    mapped: luks-72d991f0-f977-41fd-9eff-e0451114a07e
  ID-2: /boot size: 973.4 MiB used: 252.7 MiB (26.0%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 598.8 MiB used: 19.3 MiB (3.2%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 475.34 GiB used: 3.83 GiB (0.8%) fs: btrfs
    dev: /dev/dm-0 mapped: luks-72d991f0-f977-41fd-9eff-e0451114a07e
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 42.0 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 32 GiB note: est. available: 30.78 GiB used: 4.11 GiB (13.4%)
  Processes: 1283 Power: uptime: 10m wakeups: 0 Init: systemd v: 257
    target: graphical (5) default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm Compilers: N/A Shell: Bash
    v: 5.2.37 running-in: ptyxis-agent inxi: 3.3.37
1 Like
7

Hey, just wanted to chime in — I had the same issue after upgrading to Fedora 42. My system would freeze randomly, especially shortly after logging in.

I noticed it only happened when I had the “Performance” power profile enabled. After switching back to “Balanced”, the freezes stopped completely. It’s been stable so far, but I’m still monitoring it just in case.

Maybe this workaround can help someone else too.

1 Like
8

In order to keep together all data that belongs together (which fosters solution of the issue for everyone affected), I suggested to consolidate experiences and what people have in common in the topic that already consolidates several cases: Consistent screen freezes after upgrading to F42 - #10 by airdiz → you might use this IF its elaborations apply to you. Feel free to add more information to help identifying what all have in common in order to identify what cases are the same, and what might be the origin.

I leave all other topics open as the elaborations of the three topics (this one, the one I just mentioned, plus No.3, and maybe more) do not yet make clear if that really are all the same issue. So if you think the one I mentioned does not apply to you but any of the other, you may of course keep posting there. But I suggest to mention your reasons in order to help delimiting the issues.

Everybody is free to open a bug report of course, but I suggest to invest the time to fill its fields carefully and produce and provide relevant data/logs that get attached, in order to get a real chance that a maintainer can pick it up (especially in times of a new release maintainers have to focus).

If you see more related topics that might resemble one of the existing ones, feel free to let them know about the others.