You are not logged in.
Hello,
English is not my native language, I do not quite understand the following note:
Note: The below command should be run additionally, before chroot, for any month's iso ($CHROOT denotes the chroot dir, obviously). This step is not required if chroot is not involved.
Could you rephrase or otherwise explain it to capture all the nuances?
Thank you for your help.
Offline
Hello,
English is not my native language, I do not quite understand the following note:Note: The below command should be run additionally, before chroot, for any month's iso ($CHROOT denotes the chroot dir, obviously). This step is not required if chroot is not involved.
Could you rephrase or otherwise explain it to capture all the nuances?
Thank you for your help.
Can you see if the instructions are clearer now? I didn't write the original but I think I understand the meaning and I've tried to clarify/simplify slightly.
Does anybody know why the instructions are different for GRUB? I assumed the edited version would apply to both gummiboot and GRUB but since I don't really understand all the issues involved, I'm far from certain of this.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
jean_no wrote:Hello,
English is not my native language, I do not quite understand the following note:Note: The below command should be run additionally, before chroot, for any month's iso ($CHROOT denotes the chroot dir, obviously). This step is not required if chroot is not involved.
Could you rephrase or otherwise explain it to capture all the nuances?
Thank you for your help.Can you see if the instructions are clearer now? I didn't write the original but I think I understand the meaning and I've tried to clarify/simplify slightly.
Yes, your changes communicate better than my initial text.
Does anybody know why the instructions are different for GRUB? I assumed the edited version would apply to both gummiboot and GRUB but since I don't really understand all the issues involved, I'm far from certain of this.
Here is a little bit of history:
The kernel initially had only sysfs-efivars interface for managing EFI Variables. This interface is exposed by efivars kernel module at /sys/firmware/efi/vars. This interface is limited to maximum size of 1024 byte of data per EFI Variable. This limitation existed in EFI Spec 0.9 (firmwares based on which have never been released). With the implementation of UEFI Secure Boot, this VAR size limitation in sysfs-efivars became a serious issue, so a different interface called efivarfs was introduced in kernel 3.8 . This interface can be mounted anywhere (like sysfs, procfs) but de-facto mounted at /sys/firmware/efi/efivars (not /sys/firmware/efi/vars to keep it distinct from sysfs-efivars). Initially this support was added as part of efivars kernel module itself (not as a separate module). In fact they were part of same source code files in the kernel.
The problem is both interfaces can be enabled simultaneously without any form of syncing done between each other built into the kernel. If both the interface are simultaneously accessed it can lead to inconsistency and confusion, at kernel and firmware level wrt EFI VAR data and may lead to boot failure (read dangerous). But since both are part of same kernel module (efivars) in kernel 3.8, it was possible to disable one when other is used.
The source files were split and efivarfs became a separate kernel module in kernel 3.10 series. This made it possible to run one interface with the other disabled. However since initially when the kernel is loaded both interfaces might have been enabled, I added the code in wiki which disabled both the interfaces and enable only the desired one. This disabling-enabling also refreshes the EFI VAR data in the kernel and interface (sysfs-efivars of efivarfs).
Gummiboot setup and systemd boot performance data tool were released only after efivarfs was introduced in the kernel, and therefore from the start supported only efivarfs. efibootmgr on the other hand being a old tool supported only sysfs-efivars. Both grub-install and refind-install actually use efibootmgr to add boot entry. Therefore for every loader except GRUB, which indirectly uses efibootmgr required sysfs-efivars while gummiboot setup requires efivarfs. This is what I meant when I said you (@cfr) copied wrong set of commands. You copied the commands to enable only sysfs-efivars even for gummiboot setup ( https://wiki.archlinux.org/index.php?ti … did=276204 ).
Upstream efibootmgr still does not support efivarfs, but there is a fork by Fedora's Peter Jones (vathpela) which contains support for efivarfs (via his own efivar library). I suggested switching to this fork for Arch's pkg which has been accepted and current efibootmgr in core is built from vathpela's code. Since efibootmgr was the only tool which still required sysfs-efivars and now with the forked code in [core], there is no need to retain sysfs-efivars and lead to all the inconsistency due to both interfaces running simultaneouly. Therefore starting from core/linux-3.11.1 pkg, efivars kernel module is no longer built, thus completely disabling sysfs-efivars support.
Now the current released archiso contains kernel 3.10.x and old efibootmgr, which requires disabling efivarfs and refreshing sysfs-efivars data, to make sure efibootmgr works properly. This step is not required if the latest pkgs from the [core] repo is used.
Now there is another issue unrelated to this efivarfs vs sysfs-efivars fight. The current arch-chroot does not mount sub-mounts in host's /sys within the chroot's /sys. This means efivarfs mounted in host's /sys/firmware/efi/efivars is not exposed in chroot's /sys/firmware/efi/efivars. So the user has to manually bind mount host's /sys/firmware/efi/efivars into chroot's /sys/firmware/efi/efivars, so that gummiboot setup or efibootmgr WITHIN THE CHROOT can create the required boot entries. This is required irrespective of which version of iso is used, since this need to be fixed in arch-chroot, which has not yet been done till now. This is what I meant, the wording of which @cfr edited to make it more clear.
Hope this clears all the confusion.
Offline
Oops. Yes, now I see what you mean. Sorry about that. I thought you meant the other instructions you changed for gummiboot.
I still don't really understand why the instructions are different for GRUB now than for gummiboot but it working is the main thing. I assume those instructions (for GRUB) will not work once the iso has kernel version > 3.11.1, though. So will they then need to be altered to a third thing? Or should they then match the instructions for gummiboot? (That is, the modprobe will presumably fail for > 3.11.1 since the kernel module will be disabled.)
Also, users in this thread are reporting failure with the 3.10.x kernel and the latest version of efibootmgr - not 3.10.x and an older version of efibootmgr. Is that expected?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I still don't really understand why the instructions are different for GRUB now than for gummiboot but it working is the main thing. I assume those instructions (for GRUB) will not work once the iso has kernel version > 3.11.1, though. So will they then need to be altered to a third thing? Or should they then match the instructions for gummiboot? (That is, the modprobe will presumably fail for > 3.11.1 since the kernel module will be disabled.)
Once iso has kernel 3.11.1 and the new efibootmgr, this whole hackery is no longer necessary. The user just need to check whether efivarfs is mounted at /sys/firmware/efi/efivars in the host (should be mostly done automatically by systemd), if not mount it, and then bind mount host's /sys/firmware/efi/efovars to chroot's /sys/firmware/efi/efivars. This is required for both GRUB and Gummiboot.
Also, users in this thread are reporting failure with the 3.10.x kernel and the latest version of efibootmgr - not 3.10.x and an older version of efibootmgr. Is that expected?
The latest efibootmgr has support for both sysfs-efivars and efivarfs, and the Arch pkg technically supports both. But due to removal of sysfs-efivars in core/linux-3.11.1 pkg it cannot be used. But kernel 3.10.x should work perfectly fine with both latest and old efibootmgr. In case of old efibootmgr , the user has no choice but to switch to sysfs-efivars (similar to current instructions for GRUB in Beginner's Guide). If using new efibootmgr, I suggest switching to efivarfs (similar to Gummiboot) and then try. There is generally better chance with efivarfs than sysfs-efivars.
I filed a feature request at https://bugs.archlinux.org/task/37073 to fix https://bbs.archlinux.org/viewtopic.php … 5#p1328225 .
Last edited by the.ridikulus.rat (2013-09-29 19:43:58)
Offline