Cannot boot kernels newer than 6.7.11-200.fc39 | Fedora 40 |

Please verify that everything is updated (belts and suspenders mode). Don’t forget system firmware: sudo fwupdtool get-updates or check the vendor’s site.

There are no bios updates available (on asus website, it’s a laptop). I also ran the command:

$ sudo fwupdtool get-updates
Loading…                 [************************************** ]
Devices with no available firmware updates: 
 • ASUE120A:00 04F3:319B
 • MZVLB2T0HMLB-000H1
 • MZVLQ1T0HBLB-00B00
 • System Firmware
Devices with the latest available firmware version:
 • UEFI dbx
No updates available for remaining devices

Otherwise, I’m regularly running sudo dnf update --refresh. Should I do something else?

Output below. That said, the laptop does boot on the latest kernel available in a live fedora from usb, so I don’t think this is a kernel/hardware bug.

$ inxi -Fzxx
System:
  Kernel: 6.7.11-200.fc39.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.40-14.fc39
  Desktop: i3 v: 4.23 dm: GDM Distro: Fedora Linux 40 (Workstation Edition)
Machine:
  Type: Laptop System: ASUSTeK product: ROG Strix G513QY_G513QY v: 1.0
    serial: <superuser required>
  Mobo: ASUSTeK model: G513QY v: 1.0 serial: <superuser required>
    UEFI: American Megatrends LLC. v: G513QY.331 date: 02/24/2023
Battery:
  ID-1: BAT0 charge: 67.2 Wh (89.0%) condition: 75.5/90.0 Wh (83.9%)
    volts: 16.3 min: 15.9 model: AS3GWAF3KC GA50358 serial: <filter>
    status: not charging
CPU:
  Info: 8-core model: AMD Ryzen 9 5900HX with Radeon Graphics bits: 64
    type: MT MCP arch: Zen 3 rev: 0 cache: L1: 512 KiB L2: 4 MiB L3: 16 MiB
  Speed (MHz): avg: 3685 high: 4482 min/max: 400/4890 cores: 1: 4475 2: 4482
    3: 3589 4: 400 5: 4040 6: 3691 7: 3927 8: 4278 9: 4467 10: 4465 11: 4472
    12: 400 13: 3618 14: 3733 15: 4465 16: 4465 bogomips: 105409
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
    vendor: ASUSTeK driver: amdgpu v: kernel arch: RDNA-2 pcie: speed: 16 GT/s
    lanes: 16 ports: active: DP-1 empty: none bus-ID: 03:00.0
    chip-ID: 1002:73df
  Device-2: AMD Cezanne [Radeon Vega Series / Radeon Mobile Series]
    vendor: ASUSTeK driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s
    lanes: 16 ports: active: eDP-1 empty: HDMI-A-1 bus-ID: 08:00.0
    chip-ID: 1002:1638 temp: 61.0 C
  Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 24.1.0 driver: X:
    loaded: amdgpu dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 96
  Monitor-1: DP-1 mapped: DisplayPort-1-0 model: LG (GoldStar) ULTRAGEAR
    res: 2560x1440 dpi: 93 diag: 800mm (31.5")
  Monitor-2: eDP-1 mapped: eDP pos: primary model: ChiMei InnoLux 0x152a
    res: 2560x1440 dpi: 189 diag: 394mm (15.5")
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.1.2 glx-v: 1.4 es-v: 3.2
    direct-render: yes renderer: AMD Radeon Graphics (radeonsi renoir LLVM
    18.1.6 DRM 3.57 6.7.11-200.fc39.x86_64) device-ID: 1002:1638
  API: Vulkan v: 1.3.283 surfaces: xcb,xlib device: 0 type: integrated-gpu
    driver: N/A device-ID: 1002:1638 device: 1 type: discrete-gpu driver: N/A
    device-ID: 1002:73df device: 2 type: cpu driver: N/A device-ID: 10005:0000
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
  Device-1: AMD Navi 21/23 HDMI/DP Audio vendor: ASUSTeK driver: snd_hda_intel
    v: kernel pcie: speed: 16 GT/s lanes: 16 bus-ID: 03:00.1 chip-ID: 1002:ab28
  Device-2: AMD Renoir Radeon High Definition Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 08:00.1 chip-ID: 1002:1637
  Device-3: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: ASUSTeK
    driver: N/A pcie: speed: 8 GT/s lanes: 16 bus-ID: 08:00.5 chip-ID: 1022:15e2
  Device-4: AMD Family 17h/19h HD Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 08:00.6 chip-ID: 1022:15e3
  API: ALSA v: k6.7.11-200.fc39.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.0.7 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: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: ASUSTeK driver: r8169 v: kernel pcie: speed: 2.5 GT/s lanes: 1
    port: f000 bus-ID: 04:00.0 chip-ID: 10ec:8168
  IF: enp4s0 state: up speed: 100 Mbps duplex: full mac: <filter>
  Device-2: MEDIATEK MT7921 802.11ax PCI Express Wireless Network Adapter
    vendor: AzureWave driver: mt7921e v: kernel pcie: speed: 5 GT/s lanes: 1
    bus-ID: 05:00.0 chip-ID: 14c3:7961
  IF: wlp5s0 state: up mac: <filter>
  Device-3: Microsoft Xbox 360 Wireless Adapter driver: xpad type: USB
    rev: 2.0 speed: 12 Mb/s lanes: 1 bus-ID: 3-1.2.3:7 chip-ID: 045e:0719
  IF-ID-1: ztr2qrlmdf state: unknown speed: 10000 Mbps duplex: full
    mac: <filter>
Bluetooth:
  Device-1: IMC Networks Wireless_Device driver: btusb v: 0.8 type: USB
    rev: 2.1 speed: 480 Mb/s lanes: 1 bus-ID: 3-4:3 chip-ID: 13d3:3563
  Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.2
    lmp-v: 11
Drives:
  Local Storage: total: 2.79 TiB used: 2.57 TiB (92.0%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLQ1T0HBLB-00B00
    size: 953.87 GiB speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 28.9 C
  ID-2: /dev/nvme1n1 vendor: Samsung model: MZVLB2T0HMLB-000H1
    size: 1.86 TiB speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 30.9 C
Partition:
  ID-1: / size: 2.63 TiB used: 1.88 TiB (71.5%) fs: btrfs dev: /dev/dm-0
    mapped: luks-ba7654bc-d6e4-4d12-bf25-e053c4a36a87
  ID-2: /boot size: 973.4 MiB used: 466.6 MiB (47.9%) fs: ext4
    dev: /dev/nvme0n1p7
  ID-3: /boot/efi size: 256 MiB used: 44.7 MiB (17.5%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 2.63 TiB used: 1.88 TiB (71.5%) fs: btrfs dev: /dev/dm-0
    mapped: luks-ba7654bc-d6e4-4d12-bf25-e053c4a36a87
Swap:
  ID-1: swap-1 type: zram size: 47.06 GiB used: 1.8 MiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 82.0 C mobo: N/A
  Fan Speeds (rpm): cpu: 5100
  GPU: device: amdgpu temp: 54.0 C mem: 54.0 C fan: 0 device: amdgpu
    temp: 64.0 C
Info:
  Memory: total: 32 GiB note: est. available: 30.75 GiB used: 8.69 GiB (28.2%)
  Processes: 512 Power: uptime: 12h 23m wakeups: 1 Init: systemd v: 255
    target: graphical (5) default: graphical
  Packages: pm: flatpak pkgs: 49 Compilers: clang: 18.1.6 alt: 17
    gcc: 14.1.1 Shell: Bash v: 5.2.26 running-in: gnome-terminal inxi: 3.3.34

Can you try running without the KVM? Do you use a cable with different types of connectors on each end?

The amdgpu module had some major changes for the 6.9 kernels. There have been issues with both radeon and amdgpu modules, but the amdgpu issues seem to getting more attention.

So the kernel is booting, but the display is not enabled. You can try booting the latest kernel by editing the kernel command-line in the grub2 editor to remove the rhbg quiet and appending a 3 at the end to boot to “multi-user” mode in a console.

Yes, as long as the system is updated so the current selinux policies are in place before running that.

Can you try running without the KVM? Do you use a cable with different types of connectors on each end?

If you’re referring to kvm as in this, then I don’t have any. Why would you think that? Do you see it anywhere in the logs? At most, I have a usb hub and a usb-c adapter. Are you referring to those?

You can try booting the latest kernel by editing the kernel command-line in the grub2 editor to remove the rhbg quiet and appending a 3 at the end to boot to “multi-user” mode in a console.

I tried it. It yields the same result as single (the system is kind of functional and I can login to the tty). The difference is that I no longer need ctrl+alt+F2, the login prompt happens in the same tty. Is that the expected result?

I’m guessing I’d need to change the selinux policy to enforcing before doing it.
I’ll give it a try tomorrow and let you know.

There was a mention of KVM in a prior response – I use one and had blank screen issues with the update 6.9.6 that went away when I cycled power to the KVM. There are problematic “smart” cables that convert USB-C to HDMI, etc.

You should see messages from the kernel as the system starts. If not, that is a significant symptom.

No, as long as you do the touch /.autorelabel before a reboot it should relabel all the file system with current selinux context regardless of the mode currently used.

I would suggest you look at /etc/selinux/config and verify the setting is either permissive or enforcing (not disabled) though. If you set it as permissive then the use of selinux=0 on the kernel command line should not be necessary.

I would suggest you look at /etc/selinux/config and verify the setting is either permissive or enforcing (not disabled) though. If you set it as permissive then the use of selinux=0 on the kernel command line should not be necessary.

Yes, I booted 6.7 wit the .autorelabel file while using a config selinux=permissive and now I can boot on 6.7 with selinux=enforcing. I think that solved the selinux problem, thanks!

There was a mention of KVM in a prior response – I use one and had blank screen issues with the update 6.9.6 that went away when I cycled power to the KVM. There are problematic “smart” cables that convert USB-C to HDMI, etc.
You should see messages from the kernel as the system starts. If not, that is a significant symptom.

I’m not sure how KVM relates to my case, but I just tried the latest kernel (6.9.6) while disconnecting ALL devices/displays and it didn’t seem to have any effect.

Also, I’m not sure what you’re saying applies to me, my system is booting with single and with 3 kernel args. I can see the kernel/systemd log while it is booting (I posted the logs above). However, the remount-fs service seems to fail and the filesystem is mounted in read-only mode, so I can’t do much. What I mean to say is that I don’t get a blank screen as you describe, it just doesn’t properly finish booting the graphical mode, only tty.

I remember seeing BTRFS has “error:12” in the logs (both kernel versions), though I didn’t see the service fails in the 1st set of logs as they were 404 by the time I saw the post.
Perhaps try btrfs check on the boot device from the live USB?

1 Like

Using fpaste they are no longer visible, not can anyone with a similar problem find them. You are more likely to get answers if you can identify a short section with the key details of the issue – for example:

which should be: ENOMEM 12 Cannot allocate memory. From your inxi -Fzxx:


Swap:
  ID-1: swap-1 type: zram size: 47.06 GiB used: 1.8 MiB (0.0%) priority: 100
    dev: /dev/zram0

but:

Info:
  Memory: total: 32 GiB note: est. available: 30.75 GiB used: 8.69 GiB (28.2%)

Per /usr/lib/systemd/zram-generator.conf, zram swap should not exceed 8GB.

zram swap should not exceed 8GB.

I’m not sure I understand.
Do you mean to say I should reduce the swap or increase the max value in zram-generator.conf?

Using fpaste they are no longer visible

Sorry, I didn’t know, I’ll try to regenerate them soon, though I think they might be too long to paste here.

which should be: ENOMEM 12 Cannot allocate memory .

If I understand you correctly, you seem to think that either the ram is not enough or the swap is not being used?

See https://docs.kernel.org/admin-guide/blockdev/zram.html. The defaults work well for typical use cases. Did you encounter a problem using the default setting?

The ENOMEM error means “zram was not able to allocate enough memory to fulfil your needs”.

It is best if you can post just the key log entries as text. That way others with similar issues can find this topic and contribute to us understanding the issue.

You appear to have a non-default configuration that fails to boot because the requested zram size is too large. The system won’t run without swap. Here:

% cat /usr/lib/systemd/zram-generator.conf
# This config file enables a /dev/zram0 device with the default settings:
# — size — same as available RAM or 8GB, whichever is less
# — compression — most likely lzo-rle
#
# To disable, uninstall zram-generator-defaults or create empty
# /etc/systemd/zram-generator.conf file.
[zram0]
zram-size = min(ram, 8192)]
% cat /sys/block/zram0/disksize
8589934592

This setting should apply to all kernel versions. You may find some useful details by comparing journalctl output for a failed boot with newer kernel and a working boot for 6.7.11.

This is what I get on 6.7.11

$ cat /usr/lib/systemd/zram-generator.conf
# This config file enables a /dev/zram0 device with the default settings:
# — size — same as available RAM or 8GB, whichever is less
# — compression — most likely lzo-rle
#
# To disable, uninstall zram-generator-defaults or create empty
# /etc/systemd/zram-generator.conf file.
[zram0]
zram-size = min(ram, 8192)



$ cat /sys/block/zram0/disksize
50532974592

I uninnstallled zram-generator to avoid the problem alltogether and it didn’t seem to have any effect.
I logged into 6.9.7 and checked the log of remount-fs:

× systemd-remount-fs.service - Remount Root and Kernel File Systems
     Loaded: loaded (/usr/lib/systemd/system/systemd-remount-fs.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Tue 2024-07-09 11:31:55 CEST; 1min 20s ago
       Docs: man:systemd-remount-fs.service(8)
             https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
    Process: 1447 ExecStart=/usr/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE)
   Main PID: 1447 (code=exited, status=1/FAILURE)
        CPU: 8ms

Jul 09 11:31:55 fedora systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Jul 09 11:31:55 fedora systemd-remount-fs[1457]: mount: /: fsconfig system call failed: No such file or directory.
Jul 09 11:31:55 fedora systemd-remount-fs[1457]:        dmesg(1) may have more information after failed mount system call.
Jul 09 11:31:55 fedora systemd-remount-fs[1447]: /usr/bin/mount for / exited with exit status 32.
Jul 09 11:31:55 fedora systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE
Jul 09 11:31:55 fedora systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
Jul 09 11:31:55 fedora systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.

Is this the same for both 6.7.11 and newer kernels? zram size is being set to a huge value somewhere other than the documented location. Please show us your kernel command line (cat /proc/cmdline) for booting 6.7.11 and from your newest kernel (booted with 3) (usually only the kernel version will differ, aside from the 3).

Kernel.org Admin Guide ZRAM has ways to check status and configure zram using the command-line. It could help to look at the zram configuration using those tools and even try creating 8GB zram and run sudo systemctl isolate graphical.target to get the GUI.

I suggest booting 6.7.11 and installing updates to get the latest kernel and related tools (systemd) in case this is a bug that has been fixed. You should use grubby to set the 6.7.11 kernel as your default so it won’t be deleted with updates – see Fedora Kernel Booting.

For 6.7.11 it’s in this comment. I’ll get back to you for the other kernel.

I suggest booting 6.7.11 and installing updates to get the latest kernel and related tools (systemd) in case this is a bug that has been fixed

I do that regularly. I just executed dnf remove zram-generator-defaults to remove zram-generator all together and eliminate this as the cause. Should I reinstall and try to configure it?

So regarding your question if the zram0/disksize is the same in both kernels, I can’tsee it after removing the package (on neither kernel) and I didn’t try it on the non-working ones. Should I?

You should use grubby to set the 6.7.11 kernel as your default so it won’t be deleted with updates

I do. However, every time there’s an update, the latest one gets set as a default. No big deal though, I just set it back.