On Nov 16, 2013 3:35 AM, "Thomas Bächler" <[email protected]> wrote: > > 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. >
So, to summarize: - the presence of the sysfs dir indicates support for efivarfs. - mounting efivarfs should only fail when it isn't supported. I don't think we need any changes here...
