Talk:Systemd-boot

From ArchWiki
Jump to navigation Jump to search

About reboot into firmware configuration interface

If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? Moviuro (talk) 12:41, 15 March 2015 (UTC)

AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected efiboomgr entry which appears when Windows is installed and the entries I defined manually. -- wget (talk) 13:08, 15 March 2015 (UTC)
I spent some time googleing about this issue. Without success. So it would save time and pain to add some working example. It's a useful feature. --Cschlote (talk) 00:26, 16 March 2015 (UTC)
http://wstaw.org/w/3gSV/ And I don't have a Reboot into device firmware entry, nor the EFI default loader Moviuro (talk) 22:35, 21 March 2015 (UTC)
I already found several real machines, which will either show none of these entries, or just one of them. Only a VM shows all entries. --Cschlote (talk) 12:32, 23 March 2015 (UTC)
Well, this picture was taken on my Dell Latitude (E6430). Moviuro (talk) 15:28, 23 March 2015 (UTC)

$esp pseudo-var

I'd suggest replacing $esp that's prominent in the article with the standard /boot, i.e. replace

$esp is used to denote the mountpoint in this article.

with

In this article, /boot is used as the mountpoint.

And replace $esp instances accordingly. Changing the mountpoint is immediate to anyone who wants to do so, so another pseudo-var isn't required.

In addition, it's confusing to those who wish to go with the recommended /boot mountpoint. -- Alad (talk) 10:33, 5 January 2016 (UTC)

While that could make sense, we'd create an inconsistency with all the other boot loader articles, which do use $esp as well: GRUB, Syslinux, EFISTUB and rEFInd. Personally, I don't think that using a variable like that is creating confusion, especially after [1]. — Kynikos (talk) 07:12, 9 January 2016 (UTC)

Keys inside the boot menu, clarification

once you use keys to change timeout (-,T,+,t), this setting is saved in a non-volatile EFI variable; in this way `loader.conf` setting is overridden; a) how to clear the non-volatile EFI variable? b) how to show values of non-volatile EFI variables? --nTia89 (talk) 14:22, 27 May 2016 (UTC)

https://bbs.archlinux.org/viewtopic.php?pid=1733461#p1733461
a) maybe reflashing the bios ^^ or efivar -w (be carefully you can brick your motherboard) b) also with efivar --name var -p
—This unsigned comment is by Fallback (talk) 21:13, 31 August 2017‎. Please sign your posts with ~~~~!

The section about Windows 8+ overriding boot settings is incorrect

I have a dual boot with Windows 10 and it does not override your boot settings or make Windows the default at each boot as explained in the wiki (it might during a major upgrade that work more or less as a new install, like Windows 8 -> Windows 10).

The fact is that, Windows normally manage the default boot efi file $esp\boot\efi\bootx64.efi and keep it identical to $esp/EFI/Microsoft/Boot/bootmgfw.efi . This file is often updated (I don't know if it is at every boot, but very often). The default installation of systemd-boot put also a copy of itself at the default $esp\boot\efi\bootx64.efi and this can gives a conflict because it will be overwritten by Windows. If we manage to correctly put a default boot entry in the firmware that is not $esp\boot\efi\bootx64.efi, there will be no problems. If we have a motherboard that can only boot $esp\boot\efi\bootx64.efi then and only then we are in trouble and the work around described in the wiki can make sense. It would be safer not touching $esp\boot\efi\bootx64.efi, I think Windows expect we do not touch this file.

splash

add a section which talks about splash feature. --nTia89 (talk) 09:40, 9 July 2016 (UTC)

loader.conf: timeout 0?

Missing (for me) is what happens when "timeout 0" is set in loader.conf

—This unsigned comment is by Probackup-nl (talk) 11:09, 22 November 2017‎. Please sign your posts with ~~~~!

boot into windows once?

Does anyone know whether there is a way to reboot into windows once from linux using a command line. I.e. instead of "reboot", but "reboot-windows", which will boot into windows without me choosing anything at the boot menu. And on next reboot reboot into linux as the default sets?

—This unsigned comment is by Minxu (talk) 21:06, 28 January 2018‎. Please sign your posts with ~~~~!

run efibootmgr, note the number of the entry you want to boot next, run efibootmgr -n $number, that sets the boot entry as BootNext.Taifleh (talk) 11:20, 7 March 2018 (UTC)

objcopy use with intel-ucode.img

as it is nowhere to be found, i am clueless. how do i integrate the intel-ucode-img within an efi file in that manner? Taifleh (talk) 01:35, 7 March 2018 (UTC)

See Microcode#EFI_boot_stub_.2F_EFI_handover. -- Lahwaacz (talk) 07:18, 7 March 2018 (UTC)
Well, this was a kind of obvious solution. Thank you for sharing! Taifleh (talk) 09:58, 7 March 2018 (UTC)

I'm still having problems with this. Since we incorporate the ucode and initramfs within the binary EFI file, how do we reference it in the kernel-command-line.txt? What is the expected syntax for that file? Is it the same as /proc/cmdline contains? What about escaping the backslash character? I feel like this should be explained somewhere. When I try this, the kernel commandline is not being processed. Boot fails for my root partition cannot be mounted to /new_root. So initramfs is being loaded, and ucode is loaded as well. So it seems, it's not neccessary to mention initrd parameters in the kernel-command-line.txt. So how do I add my parameters (root=UUID=someuuid)... ? Taifleh (talk) 15:32, 7 March 2018 (UTC)

All you need to do is to concatenate the ucode file and your initrd with the ucode file being first. Then you use that combined file as I initrd. No need to for kernel command line arguments or anything. Hunger

arch.conf explanation could use some clearing up

Wouldn't it make a lot more sense to have the example options as `options root=/dev/sdxY rw` as opposed to some label? Also, in the explanation above it says `initrd=efipath` is a required option but I have never used this and booting into Arch works fine. Tonij (talk) 10:12, 5 December 2018 (UTC)

That's usually not a good idea, see Persistent_block_device_naming. -- Lahwaacz (talk) 23:03, 5 December 2018 (UTC)

System Rescue CD on ESP

Just like the already here "GRML on ESP" i tried to do the same with System Rescue CD (version 5.3.2). And unexpectedly it works! I followed the steps in the GRML section [2]:

- copied these files to

/boot/srcd/initram.igz
/boot/srcd/rescue64
/boot/srcd/systemrescuecd-x86-5.3.2.iso

- added an entry

title   SRCD
linux   /srcd/rescue64
initrd  /srcd/initram.igz
options docache setkmap=it isoloop=srcd/systemrescuecd-x86-5.3.2.iso

Before promoting to the main page, I'd like to have some feedback, thank you.

nTia89 (talk) 08:02, 23 September 2019 (UTC)

Let's not do this. As you have (unconsciously? why would you expect it not to work?) noticed yourself, the GRML section serves as an example that can be generalized easily enough. Robg (talk) 15:14, 23 September 2019 (UTC)
It was unexpected to me because I have just used that instructions for SRCD but I do not know neither what those files do nor have a theoretical base... It could have been easily a fluke! That's the reason why I wrote here. If you know it is logic and generic to every other distro, I'd like to add it to the section: I do not want to add a section for SRCD, a section for another distro, etc. but rework the section making it generic and keep GRML as example, because currently the section does not talk about it is a generic procedure! nTia89 (talk) 15:38, 23 September 2019 (UTC)
It is not generic, but you can easily find out yourself what are the proper file names for the kernel image and initial ramdisk, as well as what are the required kernel options. This page certainly won't become what we had before on the Multiboot USB drive page, one example is more than enough. -- Lahwaacz (talk) 20:59, 23 September 2019 (UTC)
I absolutely agree with you Lahwaacz, a notice box is enough but needed as well. nTia89 (talk) 21:08, 23 September 2019 (UTC)
I can live with a notice. Why don't you add one, NTia89, and me or Lahwaacz will adjust it if necessary. A single sentence of the kind "the below example can be generalized to..." should do. Robg (talk) 12:40, 24 September 2019 (UTC)
Done nTia89 (talk) 12:51, 24 September 2019 (UTC)