[arch-releng] [arch-install-scripts] [PATCH] common: mount efivarfs if possible, but don't bail out if it fails

Dave Reisner d at falconindy.com
Sat Nov 16 10:01:00 EST 2013

On Nov 16, 2013 3:35 AM, "Thomas Bächler" <thomas at archlinux.org> 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
> >>> 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:
> >
> >
> 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...

More information about the arch-releng mailing list