Thanks for the reply. It pulled me out of a rabbit-hole. Through misdirected trial and error I had 'found' that executing 'pacman-key --init' and 'pacman-key --populate archlinux' IMMEDIATEly after the initial failure, then exiting and restarting the installer would give a successful result...MOST OF THE TIME.
I assume that you did not exit the installer after the initial failure, but rather immediately executed 'obarun-install' (which gives consistant success) instead of exiting and restarting from the oblive desktop.
However, I have been thwarted in my attempts to boot from a BTRFS subvolume using rEFInd.
In reviewing the 'documentation' (
https://wiki.obarun.org/doku.php?id=uefi) and some of the mis-statements, I question how UEFI is being addressed.
There is no conflict between UEFI and MBR; Microsoft's refusal to support the combination is a corporate, not technical decision.
UEFI (Unified Extensible Firmware Interface) is NOT firmware - it is a STANDARD (
https://uefi.org) to which firmware purporting to be UCF (Uefi Compliant Firmware as opposed to being BIOS - a Basic Input Output System functionally matching that which was originally created by IBM and reverse engineered by others).
Part of that UEFI standard decrees that a UCF provide a specific bootMASTER capability, i.e. it is able to select and chain-load to a following bootMASTER or bootLOADER.
REFInd is a bootMASTER; it must select and chain-load to a following bootMASTER or bootLOADER.
GRUB is a bootMASTER and/or a bootLOADER. If it doesn't chain-load to a following bootMASTER or bootLOADER, it actually LOADS the OS kernel.
EFISTUB is NOT a component of a UCF, but a module that can be (and almost always is) compiled into the Linux kernal. It allows the kernel to selfLOAD (i.e. be its own bootLOADER).
Returning to the bootMASTER capability of UCF; if it is given NO instruction/information, it will seek for a partition that:
a) is flagged as bootable and efi
b) is formatted with a 'FAT' file-system
c) contains at the file-system mount-point the directory 'boot' or 'EFI' (if the directory is 'EFI', the path EFI/boot' is also considered)
d) that contains an executable with a 'magic' name (for Intel-based x86_64 motherboards, it is 'bootx64.efi')
and chain-load that 'magic' name with no parameters.
As one would expect, this is a plethora of opportunities...for DISASTER.
First, it is dismaying the number of 'distros' that presume they can erase and insert whatever they want into YOUR UCF's nvram. (distro-hopping is now a form of Russian roulette.)
Second, which then chain-loads to GRUB.
Third, which in turn chain-loads to a EFISTUB enabled kernel.
Try to find where the undocumented kernel parameters are hidden....
And when it comes to BTRFS, you're lucky if the installer included it, let alone addressed its use. (Why BTRFS? A single file-system, encompassing ALL drives in a simple RAID1 system that can allow for loss of two (out of three) or three (out of four) drives with NO 'write-hole' worries, providing near 'instant' temporal backups (within the file-system) and background copying of those backups to a separate physical archive, with multiple separate 'distros' in their own subvolumes, vast error detection and correction (rarely found after a power failure), that has NEVER failed me in over four years.)
For pure simplicity, nothing beats leaving the UCF nvram empty, creating an EFI partition on a USB stick and installing rEFInd which is then renamed to the 'magic' name.
And poof, without the USB stick the system won't boot and with it, the UCF 'finds' the 'magic' name, chain-loads (the renamed) rEFInd, which graphically shows all possible choices (assuming multiple EFI partitions). Of course, if things are more complex, specific 'stanzas' have to be defined. The difficulty is not in writing the 'stanza' but finding where the needed boot parameters were hidden in the 'distro'.
However, for pure complexity and detail, nothing beats rEFInd...DOCUMENTATION. ('refind.conf' itself is a script which is 99.9% explanation and 0.1% code, and the web site (
https://www.rodsbooks.com/refind/) is worse (99.99% documentation, 0.01% executables)
Yikes! This turned into a real TL;DR
Anyway, obarun has improved, but it needs more focus on basic installibility, ahead of super init systems. (An unadultered runit as a lure for us noobs???)
