Installing EFI bootloaders during pacstrap is broken right now, as is installing manually in arch-chroot. Therefore, mount efivarfs if the host kernel supports it. --- common | 1 + 1 file changed, 1 insertion(+)
diff --git a/common b/common index 950b452..2078b56 100644 --- a/common +++ b/common @@ -66,6 +66,7 @@ api_fs_mount() { { mountpoint -q "$1" || track_mount "$1" "$1" --bind; } && track_mount proc "$1/proc" -t proc -o nosuid,noexec,nodev && track_mount sys "$1/sys" -t sysfs -o nosuid,noexec,nodev && + { [[ -d "$1/sys/firmware/efi/efivars" ]] && track_mount efivarfs "$1/sys/firmware/efi/efivars" -t efivarfs -o nosuid,noexec,nodev || true; } && track_mount udev "$1/dev" -t devtmpfs -o mode=0755,nosuid && track_mount devpts "$1/dev/pts" -t devpts -o mode=0620,gid=5,nosuid,noexec && track_mount shm "$1/dev/shm" -t tmpfs -o mode=1777,nosuid,nodev &&
On Thu, Nov 14, 2013 at 07:15:31PM +0100, Thomas Bächler wrote:
Installing EFI bootloaders during pacstrap is broken right now, as is installing manually in arch-chroot. Therefore, mount efivarfs if the host kernel supports it.
Thanks, I pushed a different version of this patch which uses a new convenience function I added, mount_conditionally:
https://projects.archlinux.org/arch-install-scripts.git/commit/?id=8f2bd395e https://projects.archlinux.org/arch-install-scripts.git/commit/?id=c746f87fc
common | 1 + 1 file changed, 1 insertion(+)
diff --git a/common b/common index 950b452..2078b56 100644 --- a/common +++ b/common @@ -66,6 +66,7 @@ api_fs_mount() { { mountpoint -q "$1" || track_mount "$1" "$1" --bind; } && track_mount proc "$1/proc" -t proc -o nosuid,noexec,nodev && track_mount sys "$1/sys" -t sysfs -o nosuid,noexec,nodev &&
- { [[ -d "$1/sys/firmware/efi/efivars" ]] && track_mount efivarfs "$1/sys/firmware/efi/efivars" -t efivarfs -o nosuid,noexec,nodev || true; } && track_mount udev "$1/dev" -t devtmpfs -o mode=0755,nosuid && track_mount devpts "$1/dev/pts" -t devpts -o mode=0620,gid=5,nosuid,noexec && track_mount shm "$1/dev/shm" -t tmpfs -o mode=1777,nosuid,nodev &&
-- 1.8.4.2
Am 14.11.2013 20:58, schrieb Dave Reisner:
On Thu, Nov 14, 2013 at 07:15:31PM +0100, Thomas Bächler wrote:
Installing EFI bootloaders during pacstrap is broken right now, as is installing manually in arch-chroot. Therefore, mount efivarfs if the host kernel supports it.
Thanks, I pushed a different version of this patch which uses a new convenience function I added, mount_conditionally:
https://projects.archlinux.org/arch-install-scripts.git/commit/?id=8f2bd395e https://projects.archlinux.org/arch-install-scripts.git/commit/?id=c746f87fc
The last patch will still bail out if /sys/firmware/efi/efivars exists, but mounting efivarfs fails for some odd reason. While not mounting efivarfs is an undesirable situation, bailing out completely due to this failure is worse IMO.
That's why I originally added '{ cmd || true } &&'
On Nov 15, 2013 5:09 AM, "Thomas Bächler" thomas@archlinux.org wrote:
Am 14.11.2013 20:58, schrieb Dave Reisner:
On Thu, Nov 14, 2013 at 07:15:31PM +0100, Thomas Bächler wrote:
Installing EFI bootloaders during pacstrap is broken right now, as is installing manually in arch-chroot. Therefore, mount efivarfs if the host kernel supports it.
Thanks, I pushed a different version of this patch which uses a new convenience function I added, mount_conditionally:
https://projects.archlinux.org/arch-install-scripts.git/commit/?id=8f2bd395e
https://projects.archlinux.org/arch-install-scripts.git/commit/?id=c746f87fc
The last patch will still bail out if /sys/firmware/efi/efivars exists, but mounting efivarfs fails for some odd reason. While not mounting efivarfs is an undesirable situation, bailing out completely due to this failure is worse IMO.
That's why I originally added '{ cmd || true } &&'
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?
You actually needed the || true logic regardless in your patch. If the dir didn't exist on the host you'd break the mount chain. Some of us still run ancient motherboards with bios only ;)
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).
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.
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
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?
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).
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.
On Nov 16, 2013 3:35 AM, "Thomas Bächler" thomas@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
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...
Am 16.11.2013 16:01, schrieb Dave Reisner:
So, to summarize:
- the presence of the sysfs dir indicates support for efivarfs.
No, it indicates that the kernel is booted in EFI mode, nothing more. efivarfs can still be disabled.
- mounting efivarfs should only fail when it isn't supported.
I don't think we need any changes here...
On Nov 16, 2013 1:38 PM, "Thomas Bächler" thomas@archlinux.org wrote:
Am 16.11.2013 16:01, schrieb Dave Reisner:
So, to summarize:
- the presence of the sysfs dir indicates support for efivarfs.
No, it indicates that the kernel is booted in EFI mode, nothing more. efivarfs can still be disabled.
Aha! Ok, I'll fix this before the release.
- mounting efivarfs should only fail when it isn't supported.
I don't think we need any changes here...
arch-releng@lists.archlinux.org