Quick setup: I dual boot Win10 and CentOS7. Nothing exotic about
partitioning- ESP on 1st partition of the lone disk.
For the past week or so, I've been having a problem with rEFInd only
showing the banner at boot, no icons of any sort- efi loaders, stubs, tools,
etc.
I am not sure what caused this to happen. I've managed to boot back into
Windows to check update history but nothing, especially not
firmware/ESP-related patches, have been applied. I've managed to boot to
CentOS to do some cursory checking but nothing jumps out. I've done fs
checks and the ESP is clean. In terms of structure, everything is there.
At some point I was able to get rEFInd to behave normally- show icons,
boot, do what it's supposed to do. I suspect some combination of
reinstalling rEFInd to the ESP (both manually and using refind-install) got
me working again. However, reEFInd is doing it again- only showing the
banner and no I can't see m to get it to work at all.
I'm almost at wits end. Has anyone got any insight?
My best guess is that your ESP (or conceivably some other partition) is suffering from filesystem damage. Running dosfsck on it in Linux, or CHKDSK in Windows, may correct the problem. In extreme cases, backing it up, creating a fresh filesystem, and restoring it may be required.
If this type of problem keeps recurring, you should look into whether Windows is configured to use its "Fast Startup" feature, which turns shutdowns into suspend-to-disk operations. This feature is enabled by default, but it's a real problem for dual-boot configurations because it leaves the Windows filesystems (including the ESP) in an inconsistent state, which means that when another OS accesses the filesystem, it can result in filesystem damage. This page covers how to disable this feature. You may also need to disable the Hibernate feature, too. Note that the Windows Fast Startup feature is distinct from a feature that's often given a similar name in many computers' EFIs. The Windows feature does as I've just described, whereas the EFI feature typically takes "shortcuts" in hardware initialization to reduce boot times. This EFI feature can sometimes render keyboards unresponsive, but is unlikely to cause filesystem damage.
Of course, other things can cause recurring filesystem damage, too, including improper shutdowns of Linux, a disk that's failing, buggy drivers, etc. Most Linux distributions leave the ESP mounted at all times, which can cause problems if your Linux installation is unstable or if Windows is leaving it in an unsafe state. Using autofs to mount the ESP only when it's accessed might help in such situations -- or you can leave the ESP unmounted and manually mount it only when you need to do so. Note that this is not a substitute for disabling Fast Startup in Windows, since you may need to access the ESP in Linux, and since you may also want or need to access a shared data partition in both OSes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quick setup: I dual boot Win10 and CentOS7. Nothing exotic about
partitioning- ESP on 1st partition of the lone disk.
For the past week or so, I've been having a problem with rEFInd only
showing the banner at boot, no icons of any sort- efi loaders, stubs, tools,
etc.
I am not sure what caused this to happen. I've managed to boot back into
Windows to check update history but nothing, especially not
firmware/ESP-related patches, have been applied. I've managed to boot to
CentOS to do some cursory checking but nothing jumps out. I've done fs
checks and the ESP is clean. In terms of structure, everything is there.
At some point I was able to get rEFInd to behave normally- show icons,
boot, do what it's supposed to do. I suspect some combination of
reinstalling rEFInd to the ESP (both manually and using refind-install) got
me working again. However, reEFInd is doing it again- only showing the
banner and no I can't see m to get it to work at all.
I'm almost at wits end. Has anyone got any insight?
-z
Last edit: zackiedd 2018-12-10
My best guess is that your ESP (or conceivably some other partition) is suffering from filesystem damage. Running
dosfsckon it in Linux, orCHKDSKin Windows, may correct the problem. In extreme cases, backing it up, creating a fresh filesystem, and restoring it may be required.If this type of problem keeps recurring, you should look into whether Windows is configured to use its "Fast Startup" feature, which turns shutdowns into suspend-to-disk operations. This feature is enabled by default, but it's a real problem for dual-boot configurations because it leaves the Windows filesystems (including the ESP) in an inconsistent state, which means that when another OS accesses the filesystem, it can result in filesystem damage. This page covers how to disable this feature. You may also need to disable the Hibernate feature, too. Note that the Windows Fast Startup feature is distinct from a feature that's often given a similar name in many computers' EFIs. The Windows feature does as I've just described, whereas the EFI feature typically takes "shortcuts" in hardware initialization to reduce boot times. This EFI feature can sometimes render keyboards unresponsive, but is unlikely to cause filesystem damage.
Of course, other things can cause recurring filesystem damage, too, including improper shutdowns of Linux, a disk that's failing, buggy drivers, etc. Most Linux distributions leave the ESP mounted at all times, which can cause problems if your Linux installation is unstable or if Windows is leaving it in an unsafe state. Using autofs to mount the ESP only when it's accessed might help in such situations -- or you can leave the ESP unmounted and manually mount it only when you need to do so. Note that this is not a substitute for disabling Fast Startup in Windows, since you may need to access the ESP in Linux, and since you may also want or need to access a shared data partition in both OSes.