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.
Although it would be possible to modify refind-install to work around
this limitation, I'm not sure that doing so would be advisable. For
context, be aware that refind-install WILL work in a BIOS boot mode, in
which efibootmgr also does not work; however, rEFInd will not actually
be fully installed in this case. The files will be installed to the ESP
using the fallback filename (EFI/BOOT/bootx64.efi), but the EFI NVRAM
entries won't be set. This is desirable because there are situations in
which you might need to install rEFInd from a BIOS-mode boot -- for
instance, if you accidentally installed your OS in BIOS mode rather than
in EFI mode. In this case, installing rEFInd to the ESP and then relying
on the fallback boot loader filename to boot may work, depending on what
else is installed; and even if something else takes precedence, there
may be ways to override that or adjust the default in the non-Linux OS.
OTOH, I don't see what the point of installing rEFInd from within a
32-bit (i386/IA32/x86) chroot on a 64-bit (AMD64/X64/x86-64)
installation would be. By definition, a 64-bit environment is available
on the computer, and a non-chroot environment is likely to be better for
handling low-level hardware configuration in any event, so why not use
it? If you can present a reasonable use case for why installing rEFInd
in a chroot environment rather than in the host environment is
desirable, then I'll consider adjusting refind-install to handle this
situation.
Of course, this assumes that my assumption about the cause is correct,
too; it could be that something else is going wrong. Even if that's the
case, though, the question of why you'd want to install a low-level
firmware-interfacing tool from within a chroot environment -- especially
one that doesn't match the EFI's bit depth.