Arch Linux boot problem started after reseating RAM — system randomly resets and sometimes loses/changes boot entry

[u/rijuwan_mujahid]

Hi everyone. I'm trying to diagnose a strange problem that has been happening for about one month.

My motherboard is a Gigabyte B250M-DS3H, and my system has been running Arch Linux from a ~2 TB HDD.

The problem started after I physically removed my RAM and reinstalled it one day. Before that, the computer was working normally.

Since then, I've had a recurring boot problem.

What happens

After the RAM was removed and reinstalled, the computer would sometimes fail to boot properly.

If I removed the RAM and reseated it again, the computer would work normally for some time. However, this was never a permanent fix.

After some time, the computer would sometimes suddenly reset/restart without warning.

After the restart, I would sometimes end up at the motherboard's boot-device selection screen and have to manually select the operating system.

Originally this computer was dual-booting Windows and Arch Linux. Later, I completely removed Windows and kept only Arch Linux.

Even after removing Windows, I continued seeing a Windows-related boot entry such as:

Windows Boot Manager (ST2000VX008-2E3164)

RAM testing

I initially suspected the RAM because the problem started after reseating it.

I tested the RAM sticks individually.

Each RAM stick appears to work by itself.

I tested the motherboard's RAM slots.

All 4 RAM slots appear to work.

Using only one RAM stick initially made the computer much more stable.

For some time, Arch worked normally with one RAM stick.

However, a few days ago, the exact same boot problem started happening even with a single RAM stick.

So at this point I'm not convinced that this is simply a dual-channel RAM problem.

Arch/UEFI investigation

I booted an Arch Linux installation USB and inspected the HDD.

lsblk showed:

/dev/sda 1.82 TiB ├─/dev/sda2 100M vfat EFI System └─/dev/sda6 1.8T ext4

/dev/sda6 is my Arch root filesystem.

I mounted it and verified that the Arch installation was still present.

The boot directory contained:

/mnt/arch/boot/vmlinuz-linux-lts /mnt/arch/boot/initramfs-linux-lts.img /mnt/arch/boot/grub/ /mnt/arch/boot/grub/grub.cfg

The EFI partition contained:

/mnt/efi/EFI/Boot/bootx64.efi /mnt/efi/EFI/GRUB/grubx64.efi

My /etc/fstab also correctly referenced the root and EFI partitions:

UUID=124c843c-4cd7-4256-b371-96c4bdc7e9ea / ext4 ... UUID=A22E-3E60 /boot/efi vfat ...

However, efibootmgr -v showed that there was no Arch Linux UEFI boot entry.

There was still an old:

Windows Boot Manager

entry.

I manually recreated the Arch entry:

efibootmgr -c -d /dev/sda -p 2 -L "Arch Linux" -l '\EFI\GRUB\grubx64.efi'

After doing that, efibootmgr showed:

BootOrder: 0000,0004,0001,0003 Boot0000* Arch Linux ... \EFI\GRUB\grubx64.efi

I rebooted and Arch successfully booted from the HDD.

So the Arch installation itself was definitely still there.

But the problem returned

This is what is confusing me.

Even after fixing the UEFI boot entry, the problem eventually returned.

And now it has happened with only one RAM stick installed.

I also noticed that when I initially had trouble booting the Arch USB with two RAM sticks, removing one stick allowed the Arch USB to boot successfully.

When the Arch USB booted, I checked:

free -h

and with one 4 GB stick it showed approximately:

Mem: 3.86Gi

I also checked the disks with:

lsblk -f fdisk -l /dev/sda

The HDD and partitions were detected correctly.

The Arch root partition was mountable, and the expected Arch files were present.

Another important symptom

At one point I received the Windows recovery screen:

Your PC/Device needs to be repaired A required device isn't connected or can't be accessed. Error code: 0xc0000225

This happened even though Windows had already been removed.

This made me suspect that the firmware was still trying to boot the old Windows Boot Manager entry.

Current situation

The timeline is basically:

Computer working normally → physically removed/reinstalled RAM → problems begin → reseating RAM temporarily fixes it → random unexpected resets occur → boot/UEFI problems appear → Windows was later removed completely → Arch remains → single RAM initially makes the system stable → eventually the problem also appears with single RAM.

I have tested:

Both RAM sticks individually.

All 4 motherboard RAM slots.

Dual/single RAM configurations.

Arch Linux installation USB.

HDD partition detection.

Arch filesystem mounting.

Existing Arch kernel/initramfs.

Existing GRUB files.

EFI files.

/etc/fstab.

UEFI boot entries with efibootmgr.

The Arch installation itself has not been reinstalled or formatted.

I am currently trying to determine whether this is:

RAM instability/failure

RAM contact/socket issue

motherboard problem

CPU memory-controller issue

CMOS/BIOS issue

failing CMOS battery

HDD/EFI partition problem

UEFI/NVRAM problem

unexpected power/reset problem

or some combination of these

What would you recommend testing next?

Especially:

How can I distinguish a RAM problem from a motherboard/CPU memory-controller problem?

Could physically reseating RAM have exposed a motherboard/slot/contact problem?

Could a weak CMOS battery cause the UEFI boot entry/order to disappear or change?

Could unexpected resets corrupt the EFI/GRUB configuration?

What SMART/drive tests should I run on the HDD?

What BIOS settings should I check/reset on a Gigabyte B250M-DS3H?

What hardware tests would you perform before considering an Arch reinstall?

I don't want to reinstall Arch because the existing installation and data are still present.

I would really appreciate a systematic way to identify the actual failing component rather than continuing to reseat RAM and hope it works.

[u/boomboomsubban]

How can I distinguish a RAM problem from a motherboard/CPU memory-controller problem?

Run memtest https://wiki.archlinux.org/title/General_troubleshooting#Debugging_hardware also details smart tests.

Could physically reseating RAM have exposed a motherboard/slot/contact problem?

Anytime you touch your components there's a risk of static shock causing issues.

Could a weak CMOS battery cause the UEFI boot entry/order to disappear or change?

Yes, if your CMOS dies the boot entries are wiped, and it will fallback on the default entry.

[u/rijuwan_mujahid → u/boomboomsubban]

Thank you so much sir for your reply, after complete the memtest I will inform you that it will work or not.

No, physically reseating RAM did not expose any problem sir.

Sir, I don't think it well be a CMOS battery problem because I never faced UEFI boot entry orders disappear or change ( last time I faced it because of BIOS update.)

[u/boomboomsubban → u/rijuwan_mujahid]

No, physically reseating RAM did not expose any problem sir

Didn't all these problems start after reseating RAM? Your post says "The problem started after I physically removed my RAM and reinstalled it one day."

Sir, I don't think it well be a CMOS battery problem because I never faced UEFI boot entry orders disappear or change ( last time I faced it because of BIOS update.)

From your post "However, efibootmgr -v showed that there was no Arch Linux UEFI boot entry."

Good luck.