Loading issue? rEFInd Dual Boot Arch, Win10

[John]

Hopefully someone here can help, or point me in the right direction.

About 3-4 months ago I switched from systemd-boot to rEFInd for my dual-boot system. Physically, it's a Thinkpad T420 and I dual-boot between Arch Linux and Windows 10.

Migrating from systemd-boot to rEFInd was mostly a smooth experience. There was some time spent learning how to setup the boot entries in the config file(s), but mostly that was to simplify and remove redundancies. When rEFInd was installed the first time, it worked immediately - it showed Arch and Windows 10 without any tweaking on my part. After I had the configuration set the way I liked it, it was stable and reliable for months (until just recently.)

About 1 week ago, my laptop battery ran out and I must have had my Windows 10 desktop suspended or hibernating before it ran out.   When I started the computer up, I got a screen similar (probably exactly the same) as the one that currently plagues me; rEFInd showed no entries, no tools, no options - nothing.  

https://imgur.com/a/lmu5snX

I assumed rEFInd was confused due to the circumstances, so I manually turned my laptop off and back on again, held F12 to use Lenovo's boot manager, chose the "Windows Boot Manager" entry and booted straight into Windows.   Since my desktop loaded with a few different applications/windows open, I assume I was correct about previously suspending/hibernating the laptop before the battery ran down.   I closed out of all my windows, and properly shut the computer down.

When I rebooted, rEFInd showed all of the proper entries again. I assumed all was well and chose my Windows partition and went on my way.

About 1-2 days later, when I decided to boot into my Arch desktop, I was presented with the same issue as before - rEFInd seems to load, but basically just presents itself as a blank screen (just the background wallpaper.) I tried booting into Windows and making sure I properly shut it down again, but it had no effect this time.

I've been racking my brain all week trying to solve this, without a shred of luck. I used an Ubuntu live USB just to check the configs - everything looked fine. I tried archiving my configs (adding arbitrary extensions) and recopied the sample configs with proper renames, and into the proper locations. I just tried an Arch Linux bootable USB and jumped through all the hoops to mount all of the partitions (even the necessary EFI parts) and chrooted into my file-system; I did a full system upgrade/update, uninstalled rEFInd, reinstalled rEFInd - the whole nine yards. And still no dice.

After that didn't work, I found this forum and saw that there's a USB/CD image for a separate bootable instance of rEFInd - so I tried that. It boots off the USB fine (using the F12 Lenovo boot manager), but I'm still presented with exactly the same screen. Just the rEFInd wallpaper.

Does anyone have any ideas as to what could be the problem? I feel like I've done just about everything I can do on my own, and I really don't want to entertain the idea of going back to systemd-boot.

Thanks in advance for any help or suggestions you can provide.

[Roderick W. Smith]

The usual cause of this sort of problem is a filesystem problem. This can be the installation of an unnecessary filesystem driver, a buggy filesystem driver, a damaged filesystem, or a filesystem that's using features that the filesystem driver doesn't support. Thus, I suggest you do the following:

1. Check the EFI filesystem drivers in rEFInd's drivers or drivers_x64 subdirectory (normally a subdirectory of /boot/efi/EFI/refind or /boot/EFI/refind in Linux). Be sure that this directory holds only the filesystem driver(s) that you really need. In your case, that's probably just ext4_x64.efi, although it could be something else, depending on where your Linux kernel is held. (If, like many Arch users, you mount your ESP at /boot, you should have no filesystem drivers at all.) Note that rEFInd does not need an NTFS driver to boot Windows. rEFInd includes such a driver for some rather obscure conditions, not for use on all Windows installations. Delete any drivers that are unnecessary and try again.
2. If there are no unnecessary drivers or if deleting them doesn't help, try moving or deleting the necessary driver(s) anyhow, just as a test. This will help you isolate the problem; if the system continues to behave poorly, then chances are the problem is not related to the driver(s) or the filesystem(s) they read, but to something else.
3. Use fsck or similar tools to repair the filesystem(s) that rEFInd reads. This will include the ESP itself, any other FAT partition(s) on your system, and anything readable by the filesystem driver(s) you use. Depending on the tool you use, you may need to explicitly pass it options to make changes. You may also need to unmount the filesystem or re-mount it read-only, in order to make changes. Thus, you may need to do this work from an emergency disk.
4. In some cases, damage to the ESP is best handled by backing up the ESP, unmounting it, creating a fresh filesystem on it, mounting it, and restoring the data. The ESP is normally pretty small, so this whole process shouldn't take very long -- but be careful! The ESP holds rEFInd, the Windows boot loader, and possibly other critical files, so a mistake can be difficult to fix.
5. Review to be sure that the Windows fast startup feature is disabled. This feature can cause filesystem damage when dual-booting, since it leaves filesystems in an inconsistent state when "shutting down" (really suspending to disk) the computer. It's possible that this feature, if enabled, is causing damage to the ESP or to some other partition, and this damage is causing the EFI (and therefore rEFInd) to flake out.
6. Check for physical damage to the disk by running a SMART utility on it. Personally, I use GSmartControl in Linux, but the first link in this list item emphasizes Windows tools. If the disk is physically damaged, it could be creating filesystem damage or causing the EFI (and therefore rEFInd) to flake out when it tries to read a critical file.

[John]

Awesome, thank you so much for the quick and detailed response. I looked everywhere for new ideas and didn't find anything like these suggested tests - I really appreciate it.

I haven't had an opportunity to try and work through these suggestions yet, but as soon as I get the chance I will try it all out and report back with my results. Thanks again!