Won't boot on 6.14.1-1-liquorix-amd64 kernel panic [Solved]

[Mauser]

I did the MX Linux update this morning and after reboot I noticed my computer didn't boot up with 6.14.1-1-liquorix-amd64 kernel and rechecked updates which it added an additional package. Then rebooted which then showed it tried to boot up with 6.14.1-1-liquorix-amd64 kernel which results in a kernel panic in the black screen with no further progress. I switched back to booting up with 6.13.8-4-liquorix-amd64 since the 6.14.1-1-liquorix-amd64 kernel doesn't work on my computer.

Code: Select all

System:
  Kernel: 6.13.8-4-liquorix-amd64 [6.13-9~mx23ahs] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: audit=0
    intel_pstate=disable amd_pstate=disable BOOT_IMAGE=/vmlinuz-6.13.8-4-liquorix-amd64
    root=UUID=<filter> ro quiet splash resume=UUID=<filter> resume_offset=29446144
  Desktop: Xfce v: 4.20.0 tk: Gtk v: 3.24.38 info: xfce4-panel wm: xfwm v: 4.20.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.5_x64 Libretto October 15  2023 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Desktop Mobo: Gigabyte model: B450 AORUS ELITE serial: <superuser required> UEFI: American
    Megatrends LLC. v: F64a date: 02/17/2022
CPU:
  Info: model: AMD Ryzen 7 2700X bits: 64 type: MT MCP arch: Zen+ gen: 2 level: v3 note: check
    built: 2018-21 process: GF 12nm family: 0x17 (23) model-id: 8 stepping: 2 microcode: 0x800820D
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache: L1: 768 KiB
    desc: d-8x32 KiB; i-8x64 KiB L2: 4 MiB desc: 8x512 KiB L3: 16 MiB desc: 2x8 MiB
  Speed (MHz): avg: 2149 high: 2200 min/max: 2200/3700 boost: enabled scaling:
    driver: acpi-cpufreq governor: ondemand cores: 1: 2200 2: 2000 3: 1977 4: 2200 5: 2135 6: 2192
    7: 2200 8: 2200 9: 2200 10: 2200 11: 1886 12: 2200 13: 2200 14: 2200 15: 2200 16: 2200
    bogomips: 118171
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: untrained return thunk; SMT vulnerable
  Type: spec_rstack_overflow mitigation: Safe RET
  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; STIBP: disabled; RSB filling;
    PBRSB-eIBRS: Not affected; BHI: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Baffin [Radeon RX 550 640SP / 560/560X] vendor: XFX Pine driver: amdgpu v: kernel
    arch: GCN-4 code: Arctic Islands process: GF 14nm built: 2016-20 pcie: gen: 3 speed: 8 GT/s
    lanes: 8 ports: active: DVI-D-1 empty: DP-1,HDMI-A-1 bus-ID: 07:00.0 chip-ID: 1002:67ff
    class-ID: 0300 temp: 46.0 C
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.20.0 driver: X: loaded: amdgpu
    dri: radeonsi gpu: amdgpu display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1536x864 s-dpi: 96 s-size: 407x229mm (16.02x9.02") s-diag: 467mm (18.39")
  Monitor-1: DVI-D-1 mapped: DVI-D-0 model: Acer S271HL serial: <filter> built: 2019
    res: 1536x864 hz: 60 dpi: 65 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 1920x1080 min: 720x400
  API: OpenGL v: 4.6 Mesa 24.2.8-1mx23ahs renderer: AMD Radeon RX 550 Series (radeonsi polaris11
    LLVM 15.0.6 DRM 3.61 6.13.8-4-liquorix-amd64) direct-render: Yes
Audio:
  Device-1: AMD Baffin HDMI/DP Audio [Radeon RX 550 640SP / 560/560X] vendor: XFX Pine
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 8 bus-ID: 07:00.1
    chip-ID: 1002:aae0 class-ID: 0403
  Device-2: AMD Family 17h HD Audio vendor: Gigabyte driver: snd_hda_intel v: kernel pcie: gen: 3
    speed: 8 GT/s lanes: 16 bus-ID: 09:00.3 chip-ID: 1022:1457 class-ID: 0403
  API: ALSA v: k6.13.8-4-liquorix-amd64 status: kernel-api tools: alsamixer,alsamixergui,amixer
  Server-1: PipeWire v: 1.0.0 status: off with: 1: pipewire-pulse status: off 2: wireplumber
    status: off 3: pw-jack type: plugin tools: pw-cat,pw-cli,wpctl
  Server-2: PulseAudio v: 16.1 status: active tools: pacat,pactl,pavucontrol
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet vendor: Gigabyte
    driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: f000 bus-ID: 03:00.0
    chip-ID: 10ec:8168 class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: wg0-mullvad state: unknown speed: N/A duplex: N/A mac: N/A
Drives:
  Local Storage: total: 22.3 TiB used: 6.91 TiB (31.0%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 model: PCIe SSD size: 476.94 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: ECFM22.9 temp: 28.9 C
    scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 870 QVO 8TB size: 7.28 TiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 2B6Q scheme: GPT
  ID-3: /dev/sdb maj-min: 8:16 vendor: HGST (Hitachi) model: HUS728T8TALE6L4 size: 7.28 TiB
    block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter>
    rev: W414 scheme: GPT
  ID-4: /dev/sdc maj-min: 8:32 vendor: SanDisk model: ST8000DM004-2CX188 size: 7.28 TiB
    block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 5425 serial: <filter>
    rev: 0001 scheme: GPT
Partition:
  ID-1: / raw-size: 475.68 GiB size: 467.14 GiB (98.21%) used: 54.21 GiB (11.6%) fs: ext4
    dev: /dev/dm-0 maj-min: 253:0 mapped: luks-<filter>
  ID-2: /boot raw-size: 1024 MiB size: 973.4 MiB (95.06%) used: 280.8 MiB (28.8%) fs: ext4
    dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-3: /boot/efi raw-size: 250 MiB size: 246.1 MiB (98.46%) used: 415 KiB (0.2%) fs: vfat
    dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-4: /home raw-size: 7.28 TiB size: 7.22 TiB (99.20%) used: 6.85 TiB (94.9%) fs: ext4
    dev: /dev/dm-1 maj-min: 253:1 mapped: luks-<filter>
Swap:
  Kernel: swappiness: 10 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 28.39 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 49.5 C mobo: N/A gpu: amdgpu temp: 46.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 198
Repos:
  Packages: 2611 pm: dpkg pkgs: 2591 libs: 1291
    tools: apt,apt-get,aptitude,gnome-software,nala,synaptic pm: rpm pkgs: 0 pm: flatpak pkgs: 20
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/brave-browser-release.list
    1: deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ stable main
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb https://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/google-chrome.list
    1: deb [arch=amd64] https://dl.google.com/linux/chrome/deb/ stable main
  Active apt repos in: /etc/apt/sources.list.d/google-earth-pro.list
    1: deb [arch=amd64] http://dl.google.com/linux/earth/deb/ stable main
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://ftp.osuosl.org/pub/mxlinux/mx/repo/ bookworm main non-free
    2: deb http://ftp.osuosl.org/pub/mxlinux/mx/repo/ bookworm ahs
  Active apt repos in: /etc/apt/sources.list.d/extrepo_librewolf.sources
    1: deb [arch=amd64 arm64] https://repo.librewolf.net librewolf main
Info:
  Processes: 398 Uptime: 14m wakeups: 1 Memory: 23.4 GiB used: 2.11 GiB (9.0%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

This is my update history from today that this issue started.

Code: Select all

2025-04-09  09:03:20  upgrade  linux-libc-dev                          all    6.12.20-1~mx23ahs                 6.12.21-1~mx23ahs
2025-04-09  09:03:09  remove   linux-image-6.13.8-2-liquorix-amd64     amd64  6.13-7~mx23ahs                    <none>
2025-04-09  09:03:08  remove   linux-headers-6.13.8-2-liquorix-amd64   amd64  6.13-7~mx23ahs                    <none>
2025-04-09  08:12:29  upgrade  mx-service-manager                      amd64  24.3.02                           25.4
2025-04-09  08:12:29  upgrade  linux-image-liquorix-amd64              amd64  6.13-9~mx23ahs                    6.14-2~mx23ahs
2025-04-09  08:12:29  upgrade  linux-headers-liquorix-amd64            amd64  6.13-9~mx23ahs                    6.14-2~mx23ahs
2025-04-09  08:12:28  upgrade  mx-packageinstaller                     amd64  25.3.02                           25.5
2025-04-09  08:12:25  install  linux-image-6.14.1-1-liquorix-amd64     amd64  <none>                            6.14-2~mx23ahs
2025-04-09  08:12:19  install  linux-headers-6.14.1-1-liquorix-amd64   amd64  <none>                            6.14-2~mx23ahs
2025-04-09  08:12:13  upgrade  google-chrome-stable 

[dolphin_oracle]

this kernel has been moved back to ahs-staging for now. it may take a while for the mirrors to pick up the change.

[Mauser]

Thanks dolphin_oracle.

[Stevo]

It may have failed to install completely if you have not removed any unused wi-fi-drivers with MX Cleanup. Then trying to boot to it will look like a kernel panic.

[Mauser]

I never had any issues with MX LINUX 23.5 on my Acer Laptop computer but since it was recommended to me that the liquorix kernel would be best to use for my Desktop computer as recommended by someone on the MX Forums claiming it runs better due the hardware my computer has. Instead, all this has done is resulted in various issues running any other kernel than the stock kernel. I went back to using the stock 6.1.0.32 kernel from MX LINUX 23.5 because I had many various issues in the past with using the liquorix kernel. I rather have a solid reliable computer than an unreliable computer that all it does is aggravate me. Thank you all.

[DukeComposed]

I never had any issues with MX LINUX 23.5 on my Acer Laptop computer but since it was recommended to me that the liquorix kernel would be best to use for my Desktop computer as recommended by someone on the MX Forums claiming it runs better due the hardware my computer has. Instead, all this has done is resulted in various issues running any other kernel than the stock kernel.

This is a great example of why "good for the goose, good for the gander" doesn't work when it comes to kernels. Some people run brand new Acer laptops, some people have old Acer laptops. Some people run high-end gaming rigs, some people have old hardware they're, nobly, trying to keep out of a landfill long after Windows 8 stopped running on it or something.

All kernels are not created equal.

Most software, not all, I admit, just gets better over time. Version 2.3 is going to fix the bugs that existed in version 2.2 and earlier, so version 6.14 of the kernel must fix all the bugs that existed in version 6.1, right? Right?

And, unfortunately, that isn't always the case. The Linux kernel is very much a product of its time: the newest "thing" in kernel development is meant to be forward-looking, by years if not decades. Because of the open source model, it's expected that old versions are always going to stick around somewhere, so hurting the retro computer enthusiasts is never a concern. Quite literally "if our new thing helps the next generation but hurts the old timers, that's OK. The old timers still have the old source code and they can still run it. Godspeed, old timers."

I think that this community is a great organization of real-life reports: if a newer kernel works on certain hardware, there are threads that outline how it can help. If a Liquorix kernel can improve performance, there are threads that outline how that works. But it's never an absolute. Your machine may be new, but if it has just one component that the linux-next branch doesn't like anymore, it's very likely to have a performance penalty.

Kernels are uneven. They don't just get uniformly better for everyone over time.

So finding the right mix between age and ability is always a balancing act. And, fortunately, the Linux kernel community keeps relatively ancient kernels around for an appreciably long time. Though, I will admit, I kind of wish there was still an old 2.2.x branch hanging around for the sticklers. You kids just don't appreciate how good the era of folks crowing about "how good 2.0.38 was" was.

[rambo919]

Would it not make more sense to identify what hardware exactly is causing this issue? It could be any rando i/o subsystem, if it is on the motherboard a bios update could solve it though I have no shortage of rants and ravings about how utterly useless bios changelogs are for figuring out what actually was changed.

If you know what is having a problem, then perhaps a better way is opening an issue at the right place on the kernel side instead of the distro side? Given their workload it won't necessarily get resolved but you might actually find that others have the same problem or have gotten fixes for it who knows. If the problem lies mostly at the door of someone like Realtek though you might have to hope and pray it gets resolved because these people mostly seem to resent Linux taking priority over Windows for anyone.

The problem is even for advanced users this way of fixing things can get "just too much at the same time", this has to be acknowledged. It's easy to look down on others because they don't do the same amount of effort as you do but everything is not in everyone's wheelhouse the same way and most people resolve the problem by service calls to the manufacturer and everyone ends up shouting past each other.

[Mauser]

Would it not make more sense to identify what hardware exactly is causing this issue? It could be any rando i/o subsystem, if it is on the motherboard a bios update could solve it though I have no shortage of rants and ravings about how utterly useless bios changelogs are for figuring out what actually was changed.

If you know what is having a problem, then perhaps a better way is opening an issue at the right place on the kernel side instead of the distro side? Given their workload it won't necessarily get resolved but you might actually find that others have the same problem or have gotten fixes for it who knows. If the problem lies mostly at the door of someone like Realtek though you might have to hope and pray it gets resolved because these people mostly seem to resent Linux taking priority over Windows for anyone.

The problem is even for advanced users this way of fixing things can get "just too much at the same time", this has to be acknowledged. It's easy to look down on others because they don't do the same amount of effort as you do but everything is not in everyone's wheelhouse the same way and most people resolve the problem by service calls to the manufacturer and everyone ends up shouting past each other.

No, because my computer runs fine on the stock kernel and also on the previous kernel which it was only after an update of the kernel that this issue occurred on.

I don't understand what you are talking about "right place on the kernel side instead of the distro side".

I am not an advanced user.

[rambo919]

No, because my computer runs fine on the stock kernel and also on the previous kernel which it was only after an update of the kernel that this issue occurred on.

This is what is called a regression, a bug introduced by an update. Updates are supposed to improve but sometimes they do the opposite. Much the same thing with GPU drivers.... Nvidia currently has a massive mess on both Windows and Linux with their latest releases.... the Linux side just happened to get worse before the Windows side did.

This can happen for any subsystem such as audio or ethernet. The difference is you cannot usually separately up or downgrade the driver because everything is included in the kernel.... so you up or downgrade the kernel.

This might be the first time you experienced a kernel being wholely unsuited to your hardware but it won't be the last.... people just get these spurts of blind hopefulness that kernels have reached a point of being stable enough for everyone at the same time.

Generally if a specific kernel works well for you and there is no tangible benefit to upgrading to a newer version..... you don't have to. You only really have to upgrade once a year if you have new AMD hardware which you don't, it could even be that your GPU has a problem with the latest kernel because AMD drivers are directly managed by the kernel (most likely the wrong way of putting this but cant remember the specifics) and not installed separately the way Nvidia drivers are. There are many reasons why a kernel could panic you have to either find out why this is happening or just not update the kernel for a while.

In fact if you don't have the very latest hardware why not just stick to LTS versions of the kernel? The best way of doing this is to uninstall the liquorix ahs updates package in the package manager.

On the other hand, it could just be that your hardware simply is not Liquorix friendly as they likely have a focus on the latest hardware. Unfortunately a lot of these things you have to figure out for yourself we can just try to help as best we can. Throw mud at the wall and see what sticks.

I don't understand what you are talking about "right place on the kernel side instead of the distro side".

The kernel is developed independently, the distro (MX in this case) only uses it. Except for the MX tools and adaptions to tie everything together that the MX team makes, nothing in MX is actually directly developed or managed by them.

You have the stock kernel that is compiled by the Debian team on one hand and the optimized kernel that is compiled and tweaked by the Liquorix team. MX just provides both but defaults to one.

I am not an advanced user.

This was part of my point.

[AVLinux]

In the absence of a known security exploit, on a fully supported and running system there is no reason to serially upgrade a kernel as you would do with Applications, they are not the same at all. In an automobile that is a few years old that runs and performs perfectly you might upgrade the stereo but unless you know there's a major problem you would not randomly plunk in a new engine every few weeks. FOMO drives a lot of bad decisions in Linuxdom, fully supported is fully supported regardless of what the kernel revision number is. MX has to be mindful of suiting the needs of potential Users and supporting people with new hardware while also keeping tabs on potential security issues so that is why they provide and do the legwork on keeping new Kernels available not because all existing Users with solid and secure hardware support need the latest Kernel, this is so misunderstood in general..