Talk:EFISTUB

From ArchWiki
Jump to: navigation, search

Why so overly complicated?

Why not just use the EFI system partition as /boot? This makes setting up direct boot via efistub as easy as efibootmgr -c -l /vmlinuz-linux -u "$(cat /proc/cmdline)" (assuming the ESP is on /dev/sda1). Creshal (talk) 16:44, 17 August 2013 (UTC)

This would be great if it worked reliably. Unfortunately there are too many consumer boards at market right now with NVRAM issues, and I think efibootmgr has rather famously bricked boards in the past. UEFI just isn't that reliable yet. On the other hand, direct firmware boot-loading is nice, and rEFInd is tiny and pretty, so I think it's a good compromise. Also, most Linux users are used to a configurable bootloader so it fits.
Also, your solution, as elegant as it is, doesn't allow for much organization of multiple installs, and you neglected to mention the obligatory /etc/fstab entry.
Still, I think you're right. I've never understood the need for special scripts and services either. /etc/fstab is proven, simple, and portable and can easily handle transparently mounting our /boot for us. And of course, UEFI has already imposed the esp on us so we might as well use it, right?
Yesterday I added the /etc/fstab bind mount section under Sync EFISTUB Kernel. It assumes a separate bootloader, and specifically mentions rEFInd in examples, but requires only an initial configuration and is afterwards managed the same as any other installation would be.
In a nut shell:
$ mkdir -p /esp; mount -L {,/}esp
$ mkdir -p /esp/EFI/boot/new_system/; mv /boot/* $_; mount --bind $_ /boot
$ cat <<'EOF' >/etc/fstab
LABEL=new_rootfs / fstype defaults 0 0
LABEL=esp /esp vfat defaults 0 0
/esp/EFI/boot/new_system /boot none defaults,bind 0 0
EOF
$ sed -ri 's/root=[^ ]*/root=LABEL=new_rootfs/g' /boot/refind_linux.conf
Probably that code works. Anyway, it's as simple as mounting your ESP somewhere on your filesystem, creating a separate folder on your ESP for the current install, then bind mounting that folder to /boot. Reflect the config in /etc/fstab and your bootloader.conf and you're done. For good.
Mikeserv (talk) 06:50, 30 September 2013 (UTC)

Why to move from /boot to /boot/esp/EFI/arch ?

I do not well know the boot process, but if I understand, in the Alternative ESP Mount Points, it is write to move or copy kernel and initramfs from /boot/vmlinuz-linux to /boot/esp/EFI/arch/vmlinuz-linux. Isn't possible to simply put in mkinitcpi.d/linux.preset something like

 ESP_DIR="/boot/efi/EFI/arch"
 ALL_kver="${ESP_DIR}/vmlinuz-linux"
 fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"

and to get rid of the copy/move part ?

—This unsigned comment is by Ryuta (talk) 07:06, 2017 July 8‎. Please sign your posts with ~~~~!

That looks like a much better solution to me. If you have confirmed that such a setup works, I would go ahead and replace the currently suggested methods. Silverhammermba (talk) 20:59, 8 July 2017 (UTC)

Issue with the Systemd Automation script

Beta990 has some reason questioning the Systemd Automation script's line:

 cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/  && ## update bin and dirs

As it is on the wiki, it just prints this when launched:

 /usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable

[in English: unvalid identifier]. Unfortunately editing that single line as follow changes nothing:

 cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs

Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):

 Tip: Enable the systemd path unit by running :
 # systemctl enable refind_update.path;

kozaki (talk) 23:31, 3 February 2013 (UTC)

There are at least 2 further issues with these instructions. First, the unit files should really not be installed in /usr. The systemd unit files, for example, should go in /etc/systemd/system/. Second, this won't work any more now rEFInd is entirely in /usr/share/refind rather than split with /usr/lib. Since I don't use any of this, I'm reluctant to change it, though. (I do use systemd units but not the ones here and not with any script.) Could somebody who uses it go through and update it and then test the result? --cfr (talk) 02:25, 25 July 2013 (UTC)
Why not adding refind-install as a (root) cronjob? This checks if an installation exists, and updates it. No need for 'complicated' systemd scripts anymore, right? :)
I use the refind-install method a couple of times, so far no problems.
Could someone please check if this is a better solution?
Thanks. -- Beta990 (talk) 20:56, 11 February 2014 (UTC)

MKinitcpio update hook not working

The mkinitcpio auto-update hook does not work. I get the following output: "Synced to /boot/efi/EFI/arch", along with some cp errors. Obviously, the parameters are not passed.

If i replace the script with the static cp commands from incron, i get the following output, indicating that the image is copied BEFORE the new one is written:

     -> Running build hook: [efistub-update]
   Synced new kernel and initrd to EFIStub.
   ==> Generating module dependencies
   ==> Creating gzip initcpio image: /boot/initramfs-linux.img
   ==> Image generation successful

As a result, my scripts now look as follows:

   /usr/lib/initcpio/install/efistub-update    

   #!/bin/sh
   
   build() {
       /usr/local/sbin/efistub-update &
   }
   
   help() {
       cat <<HELPEOF
   This hook simply waits for mkinitcpio to finish and copies the finished ramdisk and kernel to UEFI
   HELPEOF
   }

and

   /usr/local/sbin/efistub-update

   #!/bin/sh
   
   while [ [ -d "/proc/$PPID" ]]; do
       sleep 1
   done
   
   /bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/EFIStub/vmlinuz-arch.efi
   /bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/EFIStub/initramfs-arch.img
   /bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/EFIStub/initramfs-arch-fallback.img
   
   echo "Synced new kernel and initrd to EFIStub."

Also, the watch.sh does not get chmod +x'ed in the existing example.

--Denoyse (talk) 16:08, 15 February 2013 (UTC)

I think the potential race condition (files being copied before update is done) could also be avoided by changing the watched path to simply /boot. Systemd might be smart enough to only run the service once all changes to the path are complete (i.e. all boot files have been updated). Can a brave user with their ESP not at /boot try this out?
Silverhammermba (talk) 20:46, 7 August 2014 (UTC)
I updated the scripts reflecting Denoyse's suggestions, but the scripts still copy all of the files twice: first after building the regular image and again after building the fallback image. Is there a way to make it only run once, or to have different hooks for each image?
Silverhammermba (talk) 04:14, 1 March 2013 (UTC)

Sync EFISTUB Kernel scripts need to be updated because of the move to /usr/bin

Hi everyone,

I think the sync EFISTUB Kernel scripts should be updated. All of them point to /bin/cp, but since the move to /usr/bin they should be pointing to /usr/bin/cp.

I can do it but I was just wondering if it would be agood idea to add a warning somewhere to tell people to update their scripts.

Cheers Femtomatic (talk) 19:32, 15 June 2013 (UTC)

+1 for a note about the change. -- Fengchao (talk) 03:02, 21 June 2013 (UTC)

fix paths on direct boot script

vmlinux and initramfs files path on direct boot script are not the same as on the other scripts on the page, I think it's better to change the direct boot script as follow

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars              # ignore if already mounted
# efibootmgr -d /dev/sdX -p Y -c -L "Arch Linux" -l '\EFI\arch\vmlinuz-linux' -u "root=/dev/sda2 rw initrd=/EFI/arch/initramfs-linux.img"

Lejenome (talk) 14:43, 10 May 2014 (UTC)

I think it's too complicated

I fount the page very confusing and it failed to explain the baisc mechanisms of EFI direct booting. I couldn't understand the need (or not) of a boot loader.

There should be an explaining on why to choose each of this options. Even perhaps, explaining a basic cenario and the the toubleshoot and necessity of alternative approaches. It could figure it out much easier by following this more straightforward guide:

Basic cenario

The following command installs booting structure into an qualified ESP:

bootctl --path=/boot install

Configure bootloader by creating /boot/loader/entries/arch.conf such as

title	Arch Linux
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options resume=/dev/mapper/vg0-swap root=/dev/mapper/vg0-root rw quiet

Edit /boot/loader/loader.conf

timeout 0
default arch
editor 0

Edit /etc/mkinitcpio.conf as you need, rebuild your initramfs, exit and boot:

mkinitcpio -p linux
exit
umount -R /mnt
reboot

Iuriatan (talk) 18:55, 11 January 2018 (UTC)

Your "basic scenario" uses the systemd-boot loader, not the direct EFI loading. There is an EFISTUB#Using_a_boot_manager section directing the readers to the "straightforward" methods which are described each on a separate page. -- Lahwaacz (talk) 19:31, 11 January 2018 (UTC)
You comprehend the notion on systemd and boot loader much better than me. I appreciate... but my opinion may help in terms of organization of the page. I think the focus on setting up EFI booting should conduct the analisys... With no harm to the current content. After all, as the installation guide is systemd structured out of the box, the "basic scenario" procedure looked swell to me. I could help by writing a section if you think so... When we don't understand all the approaches and methods, the idea of "simplify the process of UEFI booting" (as the refered section say) is a bit abstract. thanks anyway! Iuriatan (talk) 23:21, 11 January 2018 (UTC)
The Installation guide directs to the Category:Boot loaders page which compares all available options. So if you find EFISTUB too complicated or you got stuck somehow, the logical step is to try another option from the table. There is no point in doing the comparison on every page when one is enough. -- Lahwaacz (talk) 08:02, 12 January 2018 (UTC)

Can UUIDs be used as the --disk and --part parameters in efibootmgr?

(My first ever Arch Wiki discussion comment!)

I like the idea of using UUIDs wherever possible. I got EFISTUB booting working last night with this command (and so I updated the wiki page to add the syntax for reference):

# efibootmgr --disk /dev/sdX --part Y --create --gpt --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=UUID=00000000-0000-0000-0000-000000000000 rw initrd=\initramfs-linux.img'

But can UUIDs be used on the --disk and --part parameters? If so, what's the syntax? I'd like to update the new UUID example I just added using only UUIDs if this is possible.

—This unsigned comment is by Gaelanlloyd (talk) 15:18, 12 April 2018‎. Please sign your posts with ~~~~!

why "you can use it as last resort" ? it's 100% legit

the method described is simple and works. why call it a last resort? If it does the trick, it is legit, while a lot complicated stuff tends to break and is less legit. UBF6 (talk) 15:57, 7 November 2018 (UTC)