Am 15.11.2013 17:12, schrieb Dave Reisner:
On Fri, Nov 15, 2013 at 04:52:12PM +0100, Thomas Bächler wrote:
Am 15.11.2013 16:31, schrieb Dave Reisner:
What makes this mount so special that we should avoid failing if it doesn't mount? Why would it be any more or less prone to failure if it was successfully mounted in the host?
Nobody says that it was mounted on the host.
When a recent kernel boots in EFI mode, it always creates the directory /sys/firmware/efi/efivars/, regardless whether support for efivarfs was configured in the kernel (see drivers/firmware/efi/efi.c).
Sounds like the trigger should be /sys/firmware/efi/efivars being a mountpoint, then. Our live media, booted in EFI mode, will automatically mount efivars thanks to systemd:
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n107
Our live medium is not the only place where arch-chroot and friends are used. The arch-bootstrap tarball comes to mind. When using the arch-bootstrap tarball on a foreign system, we should ignore as many non-critical failures as possible.
That means that we might have the directory and the mount will still always fail. Anyway, failing to mount efivarfs should not prevent you from using arch-chroot, as it only prevents you from manipulating efi variables, but not from performing other important tasks.
If you boot the install media in EFI mode and plan to install the target with an EFI bootloader, is this possible without efivarsfs mounted in the chroot?
Installing the bootloader to its default location is possible, as that only involves copying the file to $esp/EFI/Boot/BOOTX64.EFI or $esp/EFI/Boot/BOOTIA32.EFI. However, adding a new boot entry to the firmware is impossible.
I'm still curious what would cause an API filesystem to fail to mount aside from a bad option or complete lack of support (which shouldn't be encountered here).
No, it can only fail if the efivarfs file system is not supported.