Arch Linux

urie

Member

Registered: 2026-01-21

Posts: 3

Kernel panic after forced poweroff:VFS unable to mount rootfs on Btrfs

Hi,

I need help debugging an intermittent boot failure on my Arch Linux system.

Hardware / setup:
- Laptop: ASUS TUF Gaming F15 FX507ZE
- Root disk: NVMe
- Root filesystem: Btrfs
- Bootloader: GRUB, UEFI
- EFI partition: /dev/nvme0n1p1
- Btrfs root partition: /dev/nvme0n1p3
- Kernel selected by GRUB: linux-lts 6.18.24-1-lts
- There is also a regular linux kernel installed.

What happened:
The system became completely frozen after memory usage was exhausted. I had to force power off the laptop. After that, Arch no longer boots reliably.

Current behavior:
When I boot Arch from GRUB, I first get a GRUB error:

This GRUB "out of memory" error is still present.

If I press Enter on that error screen, it continues to another screen and then reaches a kernel panic / blue screen:

However, I noticed something strange: after doing nothing except powering off from the blue screen and rebooting several times, the system eventually booted successfully once. So the issue seems intermittent rather than completely deterministic.

I am not sure whether this means:
- GRUB sometimes fails to load the initramfs correctly.
- The EFI partition or /boot contents are partially corrupted.
- The initramfs is oversized or damaged.
- The UEFI firmware memory layout changes between boots.
- The kernel panic is just a consequence of the initramfs not being fully loaded.
- Or there is another underlying issue with /boot, GRUB, Btrfs, or the NVMe drive.

What I have already tried:
- Booted from an Arch ISO.
- Mounted the Btrfs root subvolume and EFI partition.
- arch-chrooted into the installed system.
- Ran:

    mount -av

  The fstab entries mostly showed "already mounted" or "successfully mounted".

- Checked package integrity with:

    pacman -Qkk systemd systemd-libs glibc filesystem dbus bluez linux linux-lts linux-firmware mkinitcpio

  Most core packages showed 0 altered files. Some config files such as /etc/fstab, /etc/passwd, /etc/group, /etc/locale.gen were reported as modified backup files, which I assume is expected.

- Reinstalled or rebuilt the following:

    pacman -S linux linux-lts linux-firmware mkinitcpio grub efibootmgr btrfs-progs
    mkinitcpio -P
    grub-mkconfig -o /boot/grub/grub.cfg

- Regenerated GRUB configuration again.

However, the GRUB relocator out-of-memory error still appears, although the system managed to boot successfully once after several repeated power cycles/reboots.

Current GRUB generation output includes:

    Found linux image: /boot/vmlinuz-linux-lts
    Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux-lts.img
    Found linux image: /boot/vmlinuz-linux
    Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
    Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
    /usr/bin/grub-probe: warning: unknown device type nvme0n1.
    done

Notes:
- Because the problem started immediately after a hard poweroff, I suspect possible corruption of /boot, the EFI partition, initramfs, GRUB files, or Btrfs metadata.
- The intermittent successful boot makes me wonder whether this could be related to GRUB memory allocation, UEFI memory layout, or unreliable reading from the EFI partition / /boot.
- I am not sure whether the kernel panic is a separate issue, or just a consequence of GRUB failing to properly load the initramfs.

Questions:
1. Is the GRUB relocator out-of-memory error likely caused by a corrupted or oversized initramfs, a GRUB graphical/theme issue, EFI partition corruption, firmware memory layout, or something else?
2. Since pressing Enter after the GRUB error leads to a kernel panic, does that suggest that the initramfs was only partially loaded or not loaded correctly?
3. Could the fact that the system eventually booted after several repeated power cycles indicate an intermittent GRUB/UEFI memory allocation issue rather than permanent file corruption?
4. Could this be caused by /boot being mounted incorrectly during regeneration?
5. Should I manually add nvme, nvme_core, and btrfs to MODULES in /etc/mkinitcpio.conf?
6. Should I enable and generate fallback initramfs images in this situation?
7. Is the grub-probe warning about "unknown device type nvme0n1" relevant, or is it harmless os-prober noise?
8. What is the safest way to check and repair the EFI partition and /boot contents after a forced poweroff?
9. Are there additional checks I should run on Btrfs or the NVMe drive to rule out corruption or hardware issues?

Commands I can provide output for:

    lsblk -f
    blkid
    findmnt /boot
    findmnt /boot/efi
    cat /etc/fstab
    cat /etc/default/grub
    cat /etc/mkinitcpio.conf
    cat /etc/mkinitcpio.d/linux-lts.preset
    ls -lh /boot
    ls -lh /boot/vmlinuz-* /boot/initramfs-*.img /boot/*ucode.img
    grep -n "root=UUID" /boot/grub/grub.cfg | head -20
    grep -n "initrd" /boot/grub/grub.cfg | head -40
    lsinitcpio /boot/initramfs-linux-lts.img | grep -x init
    lsinitcpio /boot/initramfs-linux-lts.img | grep -Ei "btrfs|nvme"
    sudo btrfs scrub start -Bd /
    sudo btrfs device stats /
    sudo smartctl -a /dev/nvme0n1
    sudo nvme smart-log /dev/nvme0n1

Thanks.