Difference between revisions of "Talk:Systemd-boot"

From ArchWiki
Jump to: navigation, search
(Installing changes)
(Installing changes)
Line 20: Line 20:
  
 
: the new efibootmgr just hit core and the kernel in testing already has the old efi interface disabled, so we can get rid of this non-sense when the new kernel hits core. [[User:65kid|65kid]] ([[User talk:65kid|talk]]) 12:50, 16 September 2013 (UTC)
 
: the new efibootmgr just hit core and the kernel in testing already has the old efi interface disabled, so we can get rid of this non-sense when the new kernel hits core. [[User:65kid|65kid]] ([[User talk:65kid|talk]]) 12:50, 16 September 2013 (UTC)
 +
 +
:: Great! I suppose that [[UEFI#UEFI Variables Support in Kernel]] and [[Beginners' Guide/Installation#For UEFI motherboards]] can also be updated then. -- [[User:Dfe|Dfe]] ([[User talk:Dfe|talk]]) 21:05, 16 September 2013 (UTC)
  
 
== Mount /boot and efivarfs ==
 
== Mount /boot and efivarfs ==

Revision as of 21:05, 16 September 2013

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)

Installing changes

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)
the new efibootmgr just hit core and the kernel in testing already has the old efi interface disabled, so we can get rid of this non-sense when the new kernel hits core. 65kid (talk) 12:50, 16 September 2013 (UTC)
Great! I suppose that UEFI#UEFI Variables Support in Kernel and Beginners' Guide/Installation#For UEFI motherboards can also be updated then. -- Dfe (talk) 21:05, 16 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 /etc/fstab gummiboot install command will fail.

Details:

# 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.

Unikum (talk) 05:44, 20 April 2013 (UTC)

". 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)
Thanks for the explanation.
Unikum (talk) 11:54, 20 April 2013 (UTC)

LTS kernels

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)