BIOS remains locked in RAID mode (Intel RST) and cannot transition to AHCI.
BIOS remains locked in RAID mode (Intel RST) and cannot transition to AHCI.
Recently, an unusual event occurred on my Dell Inspiron 5401 laptop. I've been using a dual-boot setup with Windows 10 and Manjaro Linux for nearly a year without any issues. Recently, I took the machine on vacation without a charger and it remained inactive for about four days. I also passed through airport security several times. Upon returning home, I was unable to boot into either operating system. The GRUB menu displayed an error: device UUID=*****... not found. I skipped the fs ck step. Now I’m being directed into a troubleshooting shell. In BIOS, I noticed the SATA interface was configured as RAID ON. Since I only have one built-in NVMe drive, it seems unlikely this was RAID. It appears Manjaro couldn’t be installed in RAID mode, so it must have been using AHCI before. However, when I tried to select AHCI and saved the changes, the system would revert to RAID on the next boot. The BIOS version I saw was 1.1.0, which is from early 2020. I had been checking for BIOS updates periodically in Windows to ensure everything was current. I found an article about a similar problem on another laptop and suggested updating the BIOS. I followed that advice and updated it, but the issue persisted. Could there be something wrong with the CMOS battery? I was able to flash BIOS updates and preserve other settings successfully, so that seems unlikely. My NVMe drive is also visible in BIOS, indicating no hardware failure there either. Any guidance would be greatly appreciated. Thank you.
Replace the CMOS battery, then adjust the system settings in the BIOS as instructed. This seems to be the correct procedure. If it fails to retain your preferences, that’s the expected outcome.
Raid mode uses AHCI for drives you haven’t set up a raid array for. They should function identically, particularly when just one drive is installed. If your M.2 SSD is NVMe and not SATA, this becomes irrelevant. An NVMe device plugs into the PCIe bus and bypasses the traditional SATA interface in your PC. On my machine with a single NVMe drive, I turned off SATA in the BIOS and it worked perfectly. Verify UEFI compatibility is off and secure boot is enabled (or possibly turned off, as not all Linux distributions support it). Ensure you’re running in pure UEFI mode and test both secure boot states. The GRUB error “device UUID=*****... not found” suggests GRUB couldn’t find the partition by its UUID. GPT partitions assign unique IDs to each partition, which change during a format or partition operation. This might point to issues with your drive’s data or a BIOS setting shift to compatibility mode instead of UEFI-only.
Hi, thank you for your message. You're right about the SATA interface not being relevant for a PCIe drive—this was something I considered but didn't find clearly documented. The BIOS behaving oddly with RAID settings is unusual, and it seems the system automatically switches back to RAID after a restart. When I booted into Manjaro Live USB, my NVMe drive wasn't visible despite being listed in the BIOS as a boot device. It doesn’t appear in lsblk, df, or fdisk. Since it shows up in BIOS but not in file systems, it might be functional but misconfigured. Setting it to AHCI could help, though I’m unsure if that would resolve the issue. If not, let me know if you have other suggestions.
I have the manufacturer's bios menu on my laptop. I turned off the SATA port there. As you found out, this isn't typically an option in the main menu. If the drive appears in bios, it shouldn't be completely inactive. Do you have Windows installation media? You can reach for DiskPart in the troubleshooting area to see if Windows can recognize it. Just to confirm, are there any usable partitions left?
If you have a Windows bootable USB, try it out. Please note if you already know this, we can skip unnecessary back-and-forth. At region/language selection, choose your preferred settings and proceed to the next screen. You should notice a prominent Install button in the center, avoid paying attention to the bottom left "Repair my computer" link. Click that then select Troubleshoot - Command Prompt. In the command prompt, type diskpart. When it starts, type list disk. If another disk besides your USB is listed, it’s likely your NVMe drive. Check its size to confirm. There should be an asterisk in the Gpt column if the boot sector is intact. Type sel disk followed by the number you think matches your NVMe device. This will show a list of partitions. On my machine this looks like: List disk: Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- Disk 0 Online 1863 GB 1024 KB * list part: Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 System 100 MB 1024 KB Partition 2 Reserved 16 MB 101 MB Partition 3 Primary 194 GB 117 MB Partition 4 Recovery 517 MB 194 GB Partition 5 Primary 1667 GB 195 GB If you can’t locate your device here, it’s likely a serious issue. I suspect the drive itself may be faulty, so consider testing it on another computer if possible.
You have a Windows 10 bootable setup working. You used the DISPT utility to list disks and confirmed your NVMe drive is present. The system shows three partitions: one for System, another unknown type, and a primary partition. This indicates the drive is functional but not recognized as a block device in Linux. To resolve this, you may need to create a bootable USB with a Linux distribution or check if the drive needs a different partitioning method.
Now you understand how to get the drive working again beyond BIOS. Diskpart struggles with Linux partitions, so begin by using recovery software from a Linux live installation. Focus on restoring the partition table first. Assume any damage is resolved if you manage to recover it. If Manjaro isn’t responding, try another distribution. If no important data exists or backups are missing, you might need to erase the drive and start fresh. (In Diskpart, typing 'clean' will delete the boot sector—proceed with caution)
Thank you for your kind words. I'm glad I could assist more than anticipated. Keep exploring!