Booting into kernel panic on 6.18.9-3, LTS 6.12.69-3 booting fine 🤔

A few minutes ago I did uname -r and realized that I was booted into the LTS kernel 6.12.69-3.

I’m using rEFInd as boot manager, which boots into the kernel with the latest timestamp and ls showed the LTS kernel 6.12.69-3 was indeed from today whereas the cachyos kernel was 4 days older.

So I did sudo touch /boot/initramfs-linux-cachyos /boot/vmlinuz-linux-cachyos to make them the latest.

That got me the first kernel panic.

So I booted into the LTS again and did a pacman -Syu, which now updated the Cachyos kernel to 6.18.9-3, but booting that also resulted in kernel panic (which I will take a picture of a little later).

Any ideas so far?

Edit: cachyos-bugreport.sh : 38d3cc5

would be much more helpful to see kernel panic log

Hmm.. when I look at

journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY                 
 -4 fe7f1a03968a4f589af8c270001bcb3f Thu 2026-02-12 06:48:51 CET Thu 2026-02-12 07:06:20 CET
 -3 7f9ff05dc58c421dbd6e67b9fc7e4982 Thu 2026-02-12 07:06:43 CET Thu 2026-02-12 19:25:09 CET
 -2 348b3e3b84bb4fffad210e9b72cfaae7 Thu 2026-02-12 19:33:50 CET Thu 2026-02-12 19:37:27 CET
 -1 3e9c3769b388410692465cc209e6f0fa Thu 2026-02-12 19:39:00 CET Thu 2026-02-12 19:42:44 CET
  0 ff59837dd12d472daba784bffe1a1f49 Thu 2026-02-12 19:44:08 CET Thu 2026-02-12 21:04:34 CET

I would reckon that -1, -2 or -3 would be the ones panicking, but to me, none of them looks like that:

journalctl -b -1: 02ce49c
journalctl -b -2: 474f610
journalctl -b -3: 75f9462

So I’m not sure if that helps?

Edit: I guess I need to continue this thread later, I’ll be off until Sunday.

if there was a kernel panic.. there should be some error. not just “kernel panic”. without it, I cannot even imagine what to say here.

I will now boot into the 6.18.x kernel and shoot a photo of the kernel panic. Then I’ll boot into the LTS kernel and provide journalctl -b -1. I guess this is the best I can do, right?

Here is the photo:

My journalctl --list-boots does not show that boot process at all! Should have been at around 11:19

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY                 
-12 c9273d11abe84f08afbe5b4f1cc20dd8 Mon 2026-02-09 08:12:10 CET Mon 2026-02-09 08:47:20 CET
-11 3d53f822433242729eb3de62bdb4ba74 Mon 2026-02-09 08:47:46 CET Mon 2026-02-09 09:54:05 CET
-10 21f9e9b727cb450ba3d39f347e72cd1b Mon 2026-02-09 09:54:29 CET Mon 2026-02-09 14:10:25 CET
 -9 43ebae29df6d48d8baf253aa50766839 Mon 2026-02-09 17:33:03 CET Mon 2026-02-09 20:41:04 CET
 -8 423eca8a8a944652bc550cad4eee399c Tue 2026-02-10 06:45:37 CET Tue 2026-02-10 17:00:30 CET
 -7 4976817285a34edca13a75479ea3b928 Wed 2026-02-11 06:49:56 CET Wed 2026-02-11 19:55:41 CET
 -6 fe7f1a03968a4f589af8c270001bcb3f Thu 2026-02-12 06:48:51 CET Thu 2026-02-12 07:06:20 CET
 -5 7f9ff05dc58c421dbd6e67b9fc7e4982 Thu 2026-02-12 07:06:43 CET Thu 2026-02-12 19:25:09 CET
 -4 348b3e3b84bb4fffad210e9b72cfaae7 Thu 2026-02-12 19:33:50 CET Thu 2026-02-12 19:37:27 CET
 -3 3e9c3769b388410692465cc209e6f0fa Thu 2026-02-12 19:39:00 CET Thu 2026-02-12 19:42:44 CET
 -2 ff59837dd12d472daba784bffe1a1f49 Thu 2026-02-12 19:44:08 CET Thu 2026-02-12 21:32:50 CET
 -1 0ab214ec4ae4459eba1f14c229e25e68 Fri 2026-02-13 06:51:05 CET Fri 2026-02-13 11:18:28 CET
  0 fdf8e4032f6f42d6849084c73fbe9baf Fri 2026-02-13 11:21:51 CET Fri 2026-02-13 11:24:41 CET

Again, I created a file from that with journalctl -b -1 > journalctl-b-1.log : 0797cd1

but that was a boot into the lts kernel. None of the boot logs show a booting into the 6.18.x. kernel.

I don’t understand that :frowning: maybe I need to do a limine-install again?

Whatever it is, I have to leave now for the weekend. Will be back on Sunday.

Edit: the photo talks about “Unable to mount root FS”, right? If that helps: this is a NVME drive. The other drives you see in the photo are HDDs with just data, no operating system. I have no idea where the “Unable to mount root FS” comes from, because when I boot the LTS kernel, it boots from exactly that drive.

This is like the 7th time this week someone’s had issues with the regular kernel but LTS works fine, after an update. I wonder if this should be escalated.

looks like these are some bugs in kernel.. not sure if cachyos has to do anything with it. maybe it will patched in future.

maybe you can submit this somewhere near kernel development. but overall I have no idea what to do except making new attempts when updated kernel comes out.

Am I seeing this right, the LTS kernel was just upgraded from 6.12.x to 6.18.x? Now I am really scared of the next pacman -Syu :fearful: somebody please tell me everything’s gonna be alright. Maybe I should add the lts kernel and initram to the IgnorePkg for a while?

I know this might not go too in-line with arch’s philosophy but personally I always skip every .0 iteration of every kernel release, and I think it’s saved me from many pains. Every .0 release I see I automatically go full freeze mode in my system until I see the kernel got to >.0 version (and then I wait a couple of days just to be sure) :laughing:

Yeah well, as you can see, it’s the 6.18.9-2 that kernel panics on my system, while the LTS is upgraded to 6.18.10-2, so there is no .0 version in the game. Still, I am actually scared to do an update now because if that does the same on my system, I will be left with an unbootable machine :grimacing:

It’s either risking your currently working lts kernel for a mainline version that might work or staying a little bit with your working lts kernel and give it more time to the 6.19 to become more stable before making the move… tough choice indeed.

@Eniaec : over in this thread, you asked some questions.

Are you currently running the latest available bios for your mobo?

Not really, no, because the last time I tried that, I was unable to boot at all, which had me downgrading the BIOS to an older version. From @Steeledpick I learned then that I just had to do a refind-install, but I refrained from trying the BIOS upgrade again. Maybe I will have to do that today.

Did you try installing different bios versions or rolling back to an older version?

I am currently 2 versions behind, I think.

Edit: just checked your post. Based on the kernel panic error you’re getting, it might be worth a try to change boot manager, since it’s a FS mounting issue.

Hooray, the next rabbit hole to jump into :expressionless_face:

So, here is my strategy for today:

  1. Add the packages linux-cachyos-lts, linux-cachyos-lts-headers, linux-cachyos-lts-nvidia-open to IgnorePkg in /etc/pacman.conf so that they don’t get updated (because this is my current fallback scenario and if I lose that because of an updated LTS kernel, I am screwed)
  2. Do a pacman -Syu
  3. If I still get a kernel panic: update the BIOS to 7E26v1L (and do the chroot → limine-install process as described here)
  4. If I still get a kernel panic: switch from rEFInd to limine (which I guess I should do anyway, seeing that the last update for rEFInd is nearly two years old! Seems like a dead project to me)
  5. If I still get a kernel panic: I am out of ideas :frowning:

@Eniaec @mad @Steeledpick Does that sound like a valid approach to you?

Short update:

  1. pacman -Syu updated the kernel to 6.19.0-2, which gives me the same Kernel Panic :frowning: I pinned the LTS kernel first, so I am currently booted into 6.12.69-3-cachyos-lts
  2. I didn’t upgrade the BIOS yet
  3. I wanted to switch to Limine, but I realized that I would have to resize my /boot partition from 2GB to at least 4GB (I’d make that 8GB), but I am scared to do that.

This is my current partition setup:

As you can see, it’s a mixture of fat32 (/boot) and btrfs. In order to resize /boot, I will have to shrink /home, then move swap, / and /home to the right on order to be able to grow /boot.

Is it safe to resize / move btrfs partitions?

I am really scared here :fearful:

If you need the safest option, don’t move Btrfs partition:

Just shrink your swap partition by 8 or 16 GiB (especially if you are using heavy Nvidia modules for early boot).

After that, create a new larger FAT32 partition.

  1. Run lsblk -fs to find the UUID of this new FAT32 partition.
  2. Edit /etc/fstab and replace the old UUID for /boot with the new one.
  3. Unmount and remount /boot:
sudo umount /boot && sudo mount /boot
  1. Set ESP_PATH=/boot in the /etc/default/limine config file.
  2. Reinstall Limine and verify everyhting works without errors:
paru -S limine-mkinitcpio-hook limine-snapper-sync

Note:
Do not reboot yet, first check lsblk -fs to see if the swap UUID changed after shrinking.
If it did, you need to update the swap UUID in /etc/fstab and your kernel cmdline in /etc/default/limine or /etc/kernel/cmdline.
Then run sudo limine-update to update limine.conf again

Thanks for the tutorial. So you are saying I am not resizing the existing boot partition but creating a new one? And I will just keep the old one which will then be kind of obsolete?

But before I can do all the things you said, I guess I need to install limine with pacman -S limine, right?

If you suspect a boot manager issue, maybe check that rEFI’s config didn’t get overwritten inadvertently (not that that is likely for a package that hasn’t seen an update in 2 years). There’s a specific config needed to recognize arch kernel/initramfs pairs properly, for example.

The existing boot partition is marked as old like a backup. You can copy files back from it later if needed. That is the safest option if you don’t want to take any risks.

limine is already included as a dependency in limine-mkinitcpio-hook, so pacman will install it automatically.

I am so far out of my league now, I don’t understand a word at the moment.

Currently, I am booted into the 202601 Live ISO (which proofs that my machine is able to boot into a newer Kernel with Grub, I guess?). Then I cachy-chrooted into my system and copied both /boot/refind-linux.conf and /boot/EFI/refind/refind.conf to the liveuser’s home dir to be able to publish them in paste.cachyos.org.

Here they are, to my untrained eye they look pretty okay:

refind.conf: d544427
refind-linux.conf: df76ff9

I have to leave now because I have an appointment, but I will probably come back to this later today (or, if I am too scared, I might even wait until the weekend).

@Zesko : thank you very much for your support. My only problem is that you are 110% into the topic while I have absolutely no idea what I am doing here :sweat_smile: I will try my best to follow your advice although I really feel like a fish trying to ride a bicycle here.

If you guys need any more info from me, just tell me and I’ll provide everything you need. Just be patient because - as I said - I need to leave for a few hours now.

they look fine to me as well - although admitedly I have found rEFInd pretty much foolproof and automagical in general use and never had to mess with it.

It’d be useful to see your mkinitcpio conf file as there have been people reporting odd, boot breaking issues with their hooks recently (regardless of boot manager)