On Fri, 8 Dec 2017 at 06:45, Roderick W. Smith <rodsm...@rodsbooks.com> wrote: > Running refind-install directly would produce more output, which might > be helpful; however, I'm 80% sure that this is a result of EFI > architecture limitations. Specifically, tools like efibootmgr, upon > which the refind-install script (and hence the package installation > procedure) depends, work for like architectures only. That is, I would > not expect efibootmgr in a 32-bit chroot environment on a 64-bit > platform to work. If efibootmgr is installed but doesn't work, then > refind-install will fail.
I've finally gotten around to reproducing this, and I was able to reproduce even on the 0.12.0-1 version. In order to try and trace it further, I reproduced interactively, and said "no" to the "Automatically install rEFInd to the ESP?" question so that I could run "refind-install" manually and look for clues. Here's what I get: | $ refind-install | The rEFInd binary file is missing! Aborting installation! However, if I run the install via "linux32" so that the kernel reports a 32bit architecture, it more appropriately bails with the expected error: | $ linux32 refind-install | ShimSource is none | Installing rEFInd on Linux.... | The ESP doesn't seem to be mounted! Trying to find it.... | // doesn't seem to be on a VFAT filesystem. The ESP must be | mounted at //boot, //efi, or //boot/efi, and it must be | VFAT (not msdos)! Aborting! | The computer appears to be running in BIOS mode and has no ESP. You should | create an ESP, and ideally boot in EFI mode, before installing rEFInd. So I think the problem is that "refind-install" appears to be using "uname -m" for architecture detection, which it then uses to try and find the rEFInd binary file? (and that failure is a non-zero exit code, versus the zero exit code that the "we can't install because we can't find EFI" error above gives) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
