The link to documentation on freedesktop is currently giving a 503 and providing "guru meditation". Does anybody happen to be a guru and available to meditate on XID: 890648862? --cfr (talk) 03:22, 24 March 2013 (UTC)
This was recently added to the installation process.
# umount /sys/firmware/efi/efivars # modprobe -r efivars # modprobe efivarfs # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Anyone care to explain what this is supposed to do and why it would be necessary? These commands look non-sense to me and I installed gummiboot on half a dozen machines without ever needing this. I mean, executing these commands doesn't actually change anything on the system, what am I missing? 65kid (talk) 15:46, 28 August 2013 (UTC)
@65kid: Refer Unified_Extensible_Firmware_Interface#Inconsistency_between_efivarfs_and_sysfs-efivars for more info. Keshav Padram Amburay (talk) 16:20, 28 August 2013 (UTC)
- But UEFI#UEFI Variables Support in Kernel states: However since core/linux 3.10 efivarfs is built-in and efivars is again a separate module. So, aren't the above commands totally superfluous?
- Edit: Efivarfs is indeed mounted per default, so there is really no need to run the above commands. If one installs gummiboot in a chroot, one has to mount efivarfs per hand, but in the chroot, not before entering the chroot (the current installation instructions are therefore misleading and should be changed). Furthermore, mounting efivarfs in the chroot should be handled automatically by
arch-chroot, shouldn't it? -- Dfe (talk) 13:06, 13 September 2013 (UTC)
- From my understanding from the discussion from arch-dev-public, the efibootmgr in [testing] now uses the new efi interface and support for the old interface could then be completely removed from the kernel, solving this big mess. I also don't get the note regarding the LTS kernel, afaik it can't be booted via gummiboot anyway because it doesn't support efistub. 65kid (talk) 12:08, 14 September 2013 (UTC)
Mount /boot and efivarfs
Now systemd automatic detect ESP and mount it as
/boot. Also systemd mount
efivarfs. You no longer mount
/boot manually or add entry in the
/etc/fstab. If you try mount
/boot manually or from
gummiboot install command will fail.
# findmnt /boot TARGET SOURCE FSTYPE OPTIONS /boot systemd-1 autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct # findmnt efivarfs TARGET SOURCE FSTYPE OPTIONS /sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
Please add this notes to the Article.
- ". If you try mount /boot manually or from /etc/fstab gummiboot install command will fail." That's just not true, gummiboot install should work fine either way. What kind of error message is this supposed to cause?
- Either way, I don't really like adding a note about the ESP automount yet for several reasons:
- * the fsck is missing in the generated mount unit (this is on systemd's TODO list)
- * it mounts /boot with 0700 permissions. Not sure if this is intended by upstream, but it is annoying and causes warnings from pacman.
- * this feature isn't even documented in systemd yet
- * This is a systemd feature, gummiboot just happens to be the only bootloader to export the EFI variables needed for this (for now). So it's probably debatable whether to put this on the systemd wiki or the gummiboot wiki.
- 65kid (talk) 07:51, 20 April 2013 (UTC)
Although not strictly false, I think the page is a bit misleading because somebody might well think that gummiboot can boot the LTS kernel provided only that you add the EFI menu entry manually. But as far as I know the LTS kernels cannot be booted this way because they lack the stub loader. Obviously that doesn't mean you can't install gummiboot to do something else (boot another kernel, boot a boot loader etc.) but it is a bit odd the way it is put? --cfr (talk) 23:41, 23 July 2013 (UTC)