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

[Thomas Bächler]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-releng/attachments/20131116/a0b2511f/attachment.asc>