| View previous topic :: View next topic |
| Author |
Message |
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2181
|
 Posted: Fri Sep 22, 2023 9:33 am Post subject: |
 |
|
This probably counts as an aside, as it certainly isn't part of the current threads in this topic. Consider it the ravings of an old man.
After a brief look at this UAPI thing (which really should be LUAPI, as it's specifically Linux - I thought at first it was the group that defined UEFI, but no, this is a new group from April 23, and not a standards body IIUC), I can see (a) some moderate benefits of doing things their way and (b) some IMHO unnecessary overspecification.
The benefits could be that you could write a universal GRUB configuration (or other bootloader) because you get a limited range of places to look for kernels, and the installation process at least becomes consistent across different linuxen. Actually, I suspect a universal GRUB configuration is possible now, using the scripting language, if you have sufficient patience to cover all the weird setups - the issues arising when you get into booting RAID and crypto configurations that can't be inspected without some GRUB-time processing.
The overspecification starts with deciding mountpoints within the linux system - I really don't see it's anyone business where I want to mount my EFI - the boot manager certainly isn't interested, as linux isn't running then, and once linux is running, there's /etc/fstab. (These people (or at least some of them) have prior form; the excitement and "benefits" of combined /usr and whatever /usr/bin is for. and the complete lack of comprehension over the distinction and use of /bin and /sbin.)
Then there's a different UUID for each partition (fine) for each architecture (huh?). AFAIK there's no consumer hardware platforms with a boot-time choice of architecture, so this fine-grained labelling just adds complexity.
But IIUC there's a bigger issue: say I have two PCs, both conforming to this architecture, and a hardware problem means I want to mount the drive from one machine on the other for repair. Now I have partitions with duplicate UUIDs. The UAPI spec says this will be of benefit where there are containers. What? I now have "n" sets of partitions with the same UUID. How the feck do I decide what to mount? They seem to be talking of "disk images", so perhaps I'm misunderstanding. This all seems to be aimed at simplifying a setup where the OS kernel is a service, and the disk images clients to be mounted and run, which is fine for cloud providers (though they probably already have all the standards and tools they need) but irrelevant for the discrete box user.
It's not as if the new process will be much simpler or less error-prone than editing /etc/fstab - you'll now have to choose from a menu of partition types in some super-fdisk.
I note it seems to be defined for systemd's automounting process. That doesn't fill me with enthusiasm.
_________________
Greybeard |
|
| Back to top |
|
 |
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 497
|
| Posted: Fri Sep 22, 2023 9:36 am Post subject: Re: Mountpoint for the ESP |
|
|
| pjp wrote: | | sMueggli wrote: | | The EFI System Partition (ESP) contains always a directory called EFI. And in the UEFI specification the file \EFI\BOOT\BOOTx64.EFI (in case of amd64 architecture) is used as a default file path especially for removable media (see UEFI spec 2.9, chapter 3.5.1.1). In practice the file is also used as a fallback. So if a EFI binary is installed it will be usually installed inside \EFI\$distribution\$name.efi and often also under \EFI/BOOT\BOOTx64.EFI to provide a fallback. |
Hmm. So as long as BOOTx64.EFI is "correct" in its contents, it doesn't matter which program provided it? With removable media, is the the concern that the file exist in that path and by that name? |
The normal case is to have exactly one ESP for the whole system. So the firmware needs to check only one partition to find the EFI binary to load.
If you want to install a new system, you very likely use a USB drive (removable media). In this case you would copy the bootloader to the "one-and-only" ESP of your system. And you would need to create also a boot entry in the NVRAM so that the firmware is aware of the new EFI binary and its location.
But that is not very user-friendly. So it is possible that a USB drive with a FAT partition is also considered as a valid location for a bootloader.
In other words, as long as the USB drive contains a FAT partition with a file \EFI\BOOT\BOOTx64.EFI your firmware should be able to load the EFI binary. You can also have bootloaders for other architectures under \EFI\BOOT.
| pjp wrote: |
| sMueggli wrote: | My recommendation:
Do not put your main EFI binary to \EFI\BOOT\BOOTx64.efi on your ESP as this might be overwritten by another bootloader/operating system. For the ESP mountpoint, choose one of: /boot, /boot/efi or /efi (or /esp if you are otherwise confused). |
That's more confusing. However the file got to /boot/EFI/BOOT/bootx64.efi, it wasn't with intention beyond running a command that did it on its own. If a location must be specified, I would guess I followed documentation.
|
Yes, if you have a \EFI\BOOT\BOOTx64.EFI file, the firmware should be able to load it. But it is not guaranteed that the binary is the one you expect.
Let's assume you have a system with Windows, Fedora and Gentoo installed. Gentoo is the last system you installed and you are using \EFI\BOOT\BOOTx64.EFI for your (Gentoo) bootloader. This will work for a while. But if Windows or Fedora are installing newer versions of the bootloader, it is very likely that they overwrite also the bootloader at location \EFI\BOOT\BOOTx64.EFI as a fallback.
The fallback could be needed if you have a "no disk space" error during the installation of a bootloader at location \EFI\SUPERDISTRO\BOOTx64.EFI. And there are surely other reasons why a UEFI boot can fail. |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 497
|
| Posted: Fri Sep 22, 2023 9:47 am Post subject: Re: Mountpoint for the ESP |
|
|
| ozcircuit wrote: | | The /boot partition is not encrypted and can be accessed with a rescue disk. I wonder /boot can me moved to the LUKS encrypted volume though ? |
You cannot move /boot as /boot is always /boot. If your bootloader can decrypt the LUKS encrypted partition where /boot is located (either the partition with / or a separate partition for /boot), it is possible to encrypt /boot.
For example Grub2 can do that (surely with LUKS1, LUKS2 maybe also). The part that is loaded by the firmware cannot be encrypted. For BIOS boot mode you cannot encrypt the bootloader code in the MBR and for UEFI boot you cannot encrypt the EFI binary to load.
Last edited by sMueggli on Fri Sep 22, 2023 10:59 am; edited 1 time in total |
|
| Back to top |
|
|
De-Javu
n00b
Joined: 30 Mar 2009
Posts: 24
Location: USA
|
| Posted: Fri Sep 22, 2023 10:15 am Post subject: Re: Mountpoint for the ESP |
|
|
Hello all,
I know ESP can be a bit confusing coming from a non-UEFI background. I'd like to clear up a few things,
| sMueggli wrote: | | If you want to install a new system, you very likely use a USB drive (removable media). In this case you would copy the bootloader to the "one-and-only" ESP of your system. And you would need to create also a boot entry in the NVRAM so that the firmware is aware of the new EFI binary and its location. |
- If BOOTx64.EFI does not exist, the first UEFI bootloader installed to the PC will provide it.
- With GRUB, once you have the files properly copied into ESP, you can re-run grub-install and you should see the new boot entry detected in the output of grub-install. However, I haven't used GRUB in over a year, so don't take my word as fact. I do believe you may still have to make custom entries pointing to the proper UEFI executable and then run grub-install. systemd-boot is similar. LILO i am unfamiliar with.
- It seems that some UEFI BIOS "remember" the old entries in ESP and need to have any non-existent EFI entries manually removed, I don't think this is common; most of my UEFI PC's do not ever exhibit this issue; the two machines I have which suffer this issue are HP prebuilt.
| sMueggli wrote: | Yes, if you have a \EFI\BOOT\BOOTx64.EFI file, the firmware should be able to load it. But it is not guaranteed that the binary is the one you expect.
Let's assume you have a system with Windows, Fedora and Gentoo installed. Gentoo is the last system you installed and you are using \EFI\BOOT\BOOTx64.EFI for your (Gentoo) bootloader. This will work for a while. But if Windows or Fedora are installing newer versions of the bootloader, it is very likely that they overwrite also the bootloader at location \EFI\BOOT\BOOTx64.EFI as a fallback.
The fallback could be needed if you have a "no disk space" error during the installation of a bootloader at location \EFI\SUPERDISTRO\BOOTx64.EFI. And there are surely other reasons why a UEFI boot can fail. |
I wouldn't worry about this. \EFI\BOOT\BOOTx64.EFI is never used unless it is absolutely necessary. It is the last choice bootloader.
- If you have an EFI bootloader installed (GRUB/LILO/systemd-boot) and you don't have a BOOTx64.EFI, it will put one there.
- If you already had Windows installed before the Linux bootloader, it will already have put a BOOTx64.EFI, but again, it's not used unless there are no other options for the PC to boot anything.
- If another Linux distro writes its own BOOTx64.EFI, not a worry because it simply tells the PC where to find GRUB/LILO/systemd-boot/etc if it needs help. If your bootloader is properly configured you will still see all OS options if your GRUB/LILO/systemd-boot is invoked by BOOTx64.EFI.
- You can always have Linux overwrite the existing BOOTx64.EFI if something happened that you don't like - perhaps Windows overwrites it - then you use your bootloader's command to force overwrite the existing BOOTx64.EFI. For example,
| Code: | | grub-install --removable |
will specifically target BOOTx64.EFI. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Fri Sep 22, 2023 11:27 am Post subject: Re: Mountpoint for the ESP |
|
|
| De-Javu wrote: | | If BOOTx64.EFI does not exist, the first UEFI bootloader installed to the PC will provide it. |
This is wrong. Mainly the UEFI specification of a bootx64.efi exists to boot from a removable storage medium (USB stick, CDROM) without having to create a UEFI entry first (which would be nonsense of course). You CAN of course also use it to boot from a hard disk without making an explicit UEFI entry. Some manufacturers also "abuse" it to install an "emergency program".
But it is by no means the case that a system needs this bootx64.efi. See below my system ! Also the installation routine of all known boot managers try to make a UEFI entry and do NOT install additionally in \efi\boot\ this bootx64.efi. Your other explanations confuse me a bit as a UEFI expert ...
| Code: | # efibootmgr
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Secure HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\secure\bzImage.efi)
Boot0001* gentoo HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\EFI\gentoo\grubx64.efi)
Boot0002* Unlocked HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\efi\unlocked\bzImage.efi) |
| Code: | # ll /boot/efi
insgesamt 2
drwxr-xr-x 2 root root 512 27. Apr 19:26 gentoo
drwxr-xr-x 2 root root 512 6. Mai 19:54 secure
drwxr-xr-x 2 root root 512 14. Sep 19:59 unlocked |
You see there is no \efi\boot\bootx64.efi |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1260
Location: Richmond Hill, Canada
|
| Posted: Fri Sep 22, 2023 1:30 pm Post subject: |
|
|
| pietinger wrote: | | pingtoo wrote: | | But I think may be you but for sure Neddy always advise when install Gentoo failed, Do NOT erase and start from fresh. Always try to go back and find where is problem and understand it, learn from it. |
Yes, I also learned this from Neddy. But I do not understand the connection now. |
pietinger,
My apology, I did not make myself clear.
You are correct that my post have no direct relation with this thread topic. It is just one man rant.
I just notice recently many new user (first time poster) want to use Gentoo but apparently thinking is just the same as other binary distro except need to compile from source. But this is a wrong impression, I don't know where this impression generated, Maybe those YouTuber that show "How to install gentoo" in one short film?
If you wish we can open a different topic/thread about Gentoo. But let's stop posting in this thread to overtake this topic. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6158
Location: Dallas area
|
| Posted: Fri Sep 22, 2023 1:55 pm Post subject: |
|
|
| Quote: | | But it is by no means the case that a system needs this bootx64.efi. |
No, not necessary, but it's typically there as a default shell, in case something goes wrong during boot, it's like the shell you can use from grub (in grub booting)
So bottom line for UEFI/EFI (no matter the OS)
disk format gpt/mbr (with mbr disk size limitations and # of partitions)
partition needs to be tagged ESP, typically only one per server (no matter how many disks)
some efi program that is executable (unless you're just testing booting to uefi mode and then stopping  )
Mount points don't matter (to uefi) it's an OS thing, call it what you wish, or the OS allows (windows?)
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1710
Location: South America
|
| Posted: Fri Sep 22, 2023 2:00 pm Post subject: Re: Mountpoint for the ESP |
|
|
| pietinger wrote: | | Mainly the UEFI specification of a bootx64.efi exists to boot from a removable storage medium (USB stick, CDROM) without having to create a UEFI entry first (which would be nonsense of course). You CAN of course also use it to boot from a hard disk without making an explicit UEFI entry. Some manufacturers also "abuse" it to install an "emergency program". |
It is not an abuse, it is a legitimate (and convenient in my opinion) use of bootx64.efi on a nonremovable medium:
| Anon-E-moose wrote: | | [...] it's typically there as a default shell, in case something goes wrong during boot, it's like the shell you can use from grub (in grub booting) |
Goverp also said that before.
| Goverp wrote: | | UEFI says the default boot manager is called EFI/Boot/bootx64.efi (replace x64 with your hardware platform). If all else fails, UEFI will run that. On my laptop, that's the hp boot manager (which is about what the UEFI spec implies). Note the implication: if your UEFI configuration is broke, you get the default manufacturer's boot manager, which typically provides recovery options. |
And that is why I wrote earlier that one should not, in general, install anything to the ESP with that name.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
De-Javu
n00b
Joined: 30 Mar 2009
Posts: 24
Location: USA
|
| Posted: Fri Sep 22, 2023 2:26 pm Post subject: Re: Mountpoint for the ESP |
|
|
| pietinger wrote: | | De-Javu wrote: | | If BOOTx64.EFI does not exist, the first UEFI bootloader installed to the PC will provide it. |
This is wrong. [...] But it is by no means the case that a system needs this bootx64.efi. See below my system ! Also the installation routine of all known boot managers try to make a UEFI entry and do NOT install additionally in \efi\boot\ this bootx64.efi. Your other explanations confuse me a bit as a UEFI expert [...] You see there is no \efi\boot\bootx64.efi |
Hi pietinger,
You're correct that BOOTx64.EFI is not needed. My statement which you quoted wasn't to say BOOTx64.EFI must exist for a working EFI install. I meant that it's common behavior for the bootloader to place BOOTx64.EFI in that location if it doesn't already exist there.
In your case, since you don't have a BOOTx64.EFI, if all other options fail, it doesn't have a fallback option. If all other options are configured properly, it should never be a problem that you don't have BOOTx64.EFI, and besides, you understand EFI well enough that you won't need the fallback option, I think you will agree
Some very old PC with early & rudimentary UEFI implementations do require you manually enter the location of the boot EFI file in NVRAM, others (such as some older Acer and HP prebuilt PC's) are hardcoded to look for BOOTx64.EFI.
I don't use GRUB or LILO, but I thought those will generate a BOOTx64.EFI if it does not exist. Perhaps I am wrong about this! If I am wrong about this, I can accept that. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Fri Sep 22, 2023 2:28 pm Post subject: |
|
|
| pingtoo wrote: | | My apology, I did not make myself clear. |
Its okay - dont worry ! 
| pingtoo wrote: | | I just notice recently many new user (first time poster) want to use Gentoo but apparently thinking is just the same as other binary distro except need to compile from source. But this is a wrong impression, I don't know where this impression generated, Maybe those YouTuber that show "How to install gentoo" in one short film? |
Maybe. By accident I found just yesterday a wiki article from our wiki editor @maffblaster ... for me this should be the first page in our AMD64 handbook:
https://wiki.gentoo.org/wiki/User:Maffblaster/Drafts/Gentoo_Primers/The_Gentoo_Primer
| pingtoo wrote: | | If you wish we can open a different topic/thread about Gentoo. But let's stop posting in this thread to overtake this topic. |
Yes - fully ack. But ... I think we/Gentoo/nobody can do something against YT-videos ... I dont know what I could say ...  |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Fri Sep 22, 2023 2:32 pm Post subject: Re: Mountpoint for the ESP |
|
|
| GDH-gentoo wrote: | | It is not an abuse, it is a legitimate (and convenient in my opinion) use of bootx64.efi on a nonremovable medium: |
Yes - you are right. I tried to put it in "" to make it understandable ... I am sorry for my poor english 
| GDH-gentoo wrote: | | Goverp wrote: | | UEFI says the default boot manager is called EFI/Boot/bootx64.efi (replace x64 with your hardware platform). If all else fails, UEFI will run that. On my laptop, that's the hp boot manager (which is about what the UEFI spec implies). Note the implication: if your UEFI configuration is broke, you get the default manufacturer's boot manager, which typically provides recovery options. |
And that is why I wrote earlier that one should not, in general, install anything to the ESP with that name. |
++
YES ! Using the parameter "--removable" when installing grub should be done with care. 
Last edited by pietinger on Fri Sep 22, 2023 5:32 pm; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Fri Sep 22, 2023 2:37 pm Post subject: Re: Mountpoint for the ESP |
|
|
| De-Javu wrote: | | I don't use GRUB or LILO, but I thought those will generate a BOOTx64.EFI if it does not exist. Perhaps I am wrong about this! If I am wrong about this, I can accept that. |
You have an option when you install grub ... please see my previous post ... but this parameter "removable" should be used with care (to not overwrite an existant bootx64.efi from e.g manufactor), the default entry grub-install will do is (EXAMPLE):
| Code: | | BootXXXX* gentoo HD(1,GPT,0adcbfee-21aa-42ea-9a9a-2e53bd05e6a2,0x800,0x7f800)/File(\EFI\gentoo\grubx64.efi) |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Fri Sep 22, 2023 2:45 pm Post subject: Re: Mountpoint for the ESP |
|
|
| De-Javu wrote: | | Some very old PC with early & rudimentary UEFI implementations do require you manually enter the location of the boot EFI file in NVRAM, others (such as some older Acer and HP prebuilt PC's) are hardcoded to look for BOOTx64.EFI. |
Yes - I know .... We had even (many years ago) a UEFI BIOS where the start from Windows was hardcoded, and this UEFI even didnt accept a bootx64.efi ... only \EFI\Microsoft\Boot\bootmgfw.efi ...  |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1710
Location: South America
|
| Posted: Fri Sep 22, 2023 3:49 pm Post subject: Re: Mountpoint for the ESP |
|
|
| pietinger wrote: | | De-Javu wrote: | | Some very old PC with early & rudimentary UEFI implementations do require you manually enter the location of the boot EFI file in NVRAM, others (such as some older Acer and HP prebuilt PC's) are hardcoded to look for BOOTx64.EFI. |
Yes - I know .... We had even (many years ago) a UEFI BIOS where the start from Windows was hardcoded, and this UEFI even didnt accept a bootx64.efi ... only \EFI\Microsoft\Boot\bootmgfw.efi ... |
And the suspicious case of one firmware that would seemingly only accept the name shimx64.efi (perhaps in addition to the Windows loader), not arbitrary names.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20486
|
| Posted: Fri Sep 22, 2023 9:49 pm Post subject: |
|
|
| szatox wrote: | | Quote: | | Using a tool to do something I can do with a text file seems unnecessary. But as per one of the above comments, I apparently not supposed to edit refind.conf (even though that file indicates otherwise). What I'd really like is to stop the "automagic" and manage the configuration myself. This is the main complaint I have with rEFInd, but I admit to not understanding how it works |
Wait, what? Why? |
I don't like automagic configuration. It appeared that refind.conf could be used to mange the boot menu of kernels, so I did. What I see is presented by rEFInd is that has some kernels reference "found by menu" or something like that, while other entries do not. I presume the "other" entries are discovered by the automagic. I consider it clutter because it's doing the "wrong" thing. I'm not sure if that's what you were asking about. After responding to other points, those may clarify what you are asking.
| szatox wrote: | Efibootmgr talks to your mobo, not to refind.
The alternative to efibootmgr is reboot into bios* and enter or select the default boot option there. |
I use neither efibootmgr nor BIOS, so I guess the menu in refind.conf works? Well, BIOS may reference a boot disk, but certainly not a kernel. The system (laptop) only has 1 disk also, so that may be relevant. I've maintained refind.conf in a similar manner that I maintain /boot/grub/grub.cfg on a different system. That is, I add a "menuentry" for the new kernel version, and depending on my expectations of whether or not it will work, I add it first (default boot) or second (for manual selection in case it doesn't boot). rEFInd may work a bit differently.
| szatox wrote: | Refind config file allows you to provide a list of kernel command line arguments which will be passed on to the newest (by modification date) kernel detected at boot time
OR ALTERNATIVELY (I think, didn't use this one)
define full boot entries, including the kernel and arguments, which should result in a cleaner menu for running multiple OS on a single machine. In this case you'll probably have to update your boot list after kernel update, unless you do some magic with pattern matching. Which I don't know whether or not is supported, but would not surprise me if it was. |
I use the full boot entry method. The same (or nearly) as I do with grub.cfg. I have no idea how the "list of kernel command line arguments" method works.
| szatox wrote: | I don't think there is any tool for creating refind configs outside of all the text editors out there.
Refind effectively replaces mobo's builtin efi. Well, I think it's technically chainloaded, but it's not really much of a difference. |
I copy the menuentry of the active kernel and change version references. Based on previous comments, I misunderstood the purpose of efibootmgr. I perceived the comments to indicate that it controlled what kernel was used, or what kernels were available to choose from the boot menu. Since I don't use it, I'm still not clear on its purpose.
| szatox wrote: | | * I don't care how it's called now, I mean the mobo's builtin configuration utility you can branch to by interrupting boot sequence before loading your bootloader of choice, everyone here knows what I'm talking about. Efi or no efi, every single board has an eeprom with that thing. |
The only thing like that I know if is to choose internal disks, USB, CD-ROM, etc. The only time I ever use that is if I'm setting up a new system or otherwise have to boot from a USB drive (typically on a new system). I don't know what that has to do with how kernels are presented in the rEFInd menu. I believe what happens after that menu is that /boot/EFI/BOOT/bootx64.efi does whatever it is supposed to do, Since I see a rEFInd menu, I presumed that's what bootx645.efi provided (excluding icons and keys, only that file and a couple of versions of refind.conf exist under /boot/EFI).
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20486
|
| Posted: Fri Sep 22, 2023 10:43 pm Post subject: Re: Mountpoint for the ESP |
|
|
@pingtoo:
Thanks. I understand all of that except for the efivars and related elements. I may have had a slightly better understanding when I first configured it, but as I've not needed to use efibootmgr (if I ever did), I need to re-learn that.
| GDH-gentoo wrote: | | pjp wrote: | | pietinger wrote: | | With efibootmgr from sys-boot/efibootmgr you can ADD, DELETE and CHANGE your UEFI-boot-entries ... AND you can LOOK which entries you have (therefore I recommend to install it always). |
I have it installed, but I don't think I ever used it. |
If at some point you used GRUB on a UEFI machine, grub-install calls it automatically (unless you tell it not to with an option), so that might be why you don't recall using it. However, you should have used it for setting up rEFInd, you don't remember that? |
I configured it in late 2017, so no, I don't. If it is required, then I must have. I don't believe I ever used Grub on this system, but hadn't decided what to use when I had to create partitions. I _think_ I chose rEFInd but wanted to be able to use GRUB if I decided to not stay with rEFInd.
| GDH-gentoo wrote: | | Um, that automagic (discovering "boot loaders", including EFI stub kernels, and presenting them in the boot menu without explicit configuration) is one of rEFInd's selling points... |
:) I think documentation only lists a few options. At the time, many seemed to like rEFInd. It's not so bad that it needs to be replaced, but I don't anticipate using it again on my next system.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20486
|
| Posted: Fri Sep 22, 2023 11:07 pm Post subject: Re: Mountpoint for the ESP |
|
|
| sMueggli wrote: | | But that is not very user-friendly. |
Thank you for the explanation. It doesn't seem like "user friendly" made it into the design plan. I think it would have been hard to make it worse without intention.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3445
|
| Posted: Fri Sep 22, 2023 11:14 pm Post subject: |
|
|
| Quote: | | I don't like automagic configuration |
I get that part. What surprised me there was the idea that you're not supposed to edit refind config manually.
| Quote: | I use neither efibootmgr nor BIOS, so I guess the menu in refind.conf works?
[...]Based on previous comments, I misunderstood the purpose of efibootmgr. I perceived the comments to indicate that it controlled what kernel was used, or what kernels were available to choose from the boot menu |
Yes, refind works.
Efibootmgr does control what kernel is used, BUT! only if you use a direct boot to efi stub kernel.
And only if the kernel's name or boot args change. Anything else is "set once and never touch it again", so your system doesn't really need any way to set efi variables.
Since changing your boot line from within BIOS is a PITA at best and impossible at worst, pretty much everyone uses an on-disk bootloader instead, for added flexibility. At this point choosing the boot device in BIOS is totally enough.
| Quote: | | I have no idea how the "list of kernel command line arguments" method works. |
I'll give you an example:
| Code: | # cat /boot/refind_linux.conf
"Boot with standard options" "dolvm root=/dev/vg_os/root ro splash"
"Boot to single-user mode" "dolvm root=/dev/vg_os/root ro single"
|
/boot/EFI/refind/refind.conf only contains menu timeout.
At boot, refind detects kernel and offers to boot the newest one and offers to boot it with standard options - this will also be the default action upon timeout.
If you opt to enter the full menu, you'll find generated options like this:
newest kernel - boot with standard options
newest kernel - boot to single-user mode
second-newest kernel - boot with standard options
second-newest kernel - boot to single-user mode
The list goes on. The labels are user-defined, you can put any string you like. The number of entries is also arbitrary. One line is all you _need_, but you can have as many options as you want.
Also, if I have any other bootable media attached, refind offers to chainload them (without passing my custom arguments), be it efi-enabled medium or a legacy-boot. |
|
| Back to top |
|
|
De-Javu
n00b
Joined: 30 Mar 2009
Posts: 24
Location: USA
|
| Posted: Sat Sep 23, 2023 12:24 am Post subject: Re: Mountpoint for the ESP |
|
|
| pjp wrote: | | I think documentation only lists a few options. At the time, many seemed to like rEFInd. It's not so bad that it needs to be replaced, but I don't anticipate using it again on my next system. |
Yes, rEFInd is a bit dejected at this point in time. It was mostly popular during the heyday of Hackintosh because it worked well with that platform. It's not the easiest bootloader to configure anymore, and it lacks features compared to the more commonly used bootloaders. I wouldn't suggest a user to load it into their new install in 2023 or later.
So long as you can boot into your Linux system, nothing stopping you from blasting away rEFInd and replacing with GRUB, if that's your goal. Just make a backup of the drive first, same as preparing for a deep @world update But it shouldn't break anything and it should be very quick & simple to install a different bootloader over rEFInd. You can always manually remove /refind from ESP afterwards, too.
If you don't wish to change the bootloader at all, certainly I recommend using efibootmgr to shift things into place so your bootloader at least does the job it should.
| szatox wrote: | | What surprised me there was the idea that you're not supposed to edit refind config manually. |
You certainly can edit your refind.conf manually, but it's very easy to break it that way too. 
It's recommended to use efibootmgr to manage it.
I rarely touch efibootmgr - generally I prefer to make my boot entries myself, then re-install the entire bootloader, so it has my changes applied. It's very quick to do this so I haven't bothered with efibootmgr unless it is needed for a specific task. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20486
|
| Posted: Sat Sep 23, 2023 2:04 am Post subject: |
|
|
| szatox wrote: | | Quote: | | I don't like automagic configuration |
I get that part. What surprised me there was the idea that you're not supposed to edit refind config manually. |
The comment may have been oriented more toward "let it happen automatically" and I read "not supposed to do that" in a literal sense.
| szatox wrote: | Efibootmgr does control what kernel is used, BUT! only if you use a direct boot to efi stub kernel.
And only if the kernel's name or boot args change. Anything else is "set once and never touch it again", so your system doesn't really need any way to set efi variables. |
I'll have to do some reading about how it works, combined with some testing. I don't use efibootmgr, but I do use version numbers in my kernel image file names (vmlinuz-version.img). So it would appear that the handoff to rEFInd is sufficient without use of efigootmgr.
| szatox wrote: | I'll give you an example:
| Code: | # cat /boot/refind_linux.conf
"Boot with standard options" "dolvm root=/dev/vg_os/root ro splash"
"Boot to single-user mode" "dolvm root=/dev/vg_os/root ro single"
|
/boot/EFI/refind/refind.conf only contains menu timeout.
At boot, refind detects kernel and offers to boot the newest one and offers to boot it with standard options - this will also be the default action upon timeout.
If you opt to enter the full menu, you'll find generated options like this:
newest kernel - boot with standard options
newest kernel - boot to single-user mode
second-newest kernel - boot with standard options
second-newest kernel - boot to single-user mode
The list goes on. The labels are user-defined, you can put any string you like. The number of entries is also arbitrary. One line is all you _need_, but you can have as many options as you want.
Also, if I have any other bootable media attached, refind offers to chainload them (without passing my custom arguments), be it efi-enabled medium or a legacy-boot. |
I do like the idea of being able to choose single-user mode in that manner without need of a dedicated full menu entry. I don't have one currently, but I have used them in the past. Thanks. I'll look into trying that method.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20486
|
| Posted: Sat Sep 23, 2023 2:13 am Post subject: Re: Mountpoint for the ESP |
|
|
| De-Javu wrote: | | Yes, rEFInd is a bit dejected at this point in time. It was mostly popular during the heyday of Hackintosh because it worked well with that platform. It's not the easiest bootloader to configure anymore, and it lacks features compared to the more commonly used bootloaders. I wouldn't suggest a user to load it into their new install in 2023 or later. |
It's primary advantage was not being Grub.
| De-Javu wrote: | | it shouldn't break anything |
I generally try to not break things that are currently working, and "shouldn't" is a theory often better left untested. ;)
| De-Javu wrote: | | I recommend using efibootmgr to shift things into place so your bootloader at least does the job it should. |
And therein is what I need to read about. That it works without me using efibootmgr makes me inclined to not want to start using it. I haven't been using it for ~6 years, why start now? It could be that I've just been very lucky.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1710
Location: South America
|
| Posted: Sat Sep 23, 2023 12:28 pm Post subject: |
|
|
| pjp wrote: | | szatox wrote: | | Quote: | | I don't like automagic configuration |
I get that part. What surprised me there was the idea that you're not supposed to edit refind config manually. |
The comment may have been oriented more toward "let it happen automatically" and I read "not supposed to do that" in a literal sense. |
Yes. In my earlier posts, I meant by that "you shouldn't create manual boot stanzas for Linux kernels (with menuentry) in rEFInd's global configuration file".
http://www.rodsbooks.com/refind/configfile.html#stanzas
| Quote: | | Note: Don't create manual boot stanzas unless you need to do so! Many people try to create them when rEFInd's auto-detection mechanisms will do the job just as well and with less hassle and chance of error. (Note that you can pass kernel options to a Linux kernel in the /boot/refind_linux.conf file; see the Methods of Booting Linux page for details.) Efforts to create manual boot stanzas when auto-detection can do the job just create pointless work for yourself! |
| De-Javu wrote: | If you don't wish to change the bootloader at all, certainly I recommend using efibootmgr to shift things into place so your bootloader at least does the job it should.
| szatox wrote: | | What surprised me there was the idea that you're not supposed to edit refind config manually. |
You certainly can edit your refind.conf manually, but it's very easy to break it that way too.
It's recommended to use efibootmgr to manage it.
I rarely touch efibootmgr - generally I prefer to make my boot entries myself, then re-install the entire bootloader, so it has my changes applied. It's very quick to do this so I haven't bothered with efibootmgr unless it is needed for a specific task. |
I don't understand this at all. When using GRUB or rEFInd, efibootmgr is needed only once, when the bootloader you plan to use is installed for the first time. And, like I said, in GRUB's case, grub-install does that for you behind the scenes.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3445
|
| Posted: Sat Sep 23, 2023 12:50 pm Post subject: Re: Mountpoint for the ESP |
|
|
| De-Javu wrote: |
| szatox wrote: | | What surprised me there was the idea that you're not supposed to edit refind config manually. |
You certainly can edit your refind.conf manually, but it's very easy to break it that way too.
It's recommended to use efibootmgr to manage it.
|
Please explain that part 'cause it doesn't add up on my end. Are we talking about some very different setups, like on-disk refind vs refind embedded in mobo's eeprom?
Why use efibootmgr for managing refind; how is it even supposed to work, when they are 2 different ways of achieving the same goal? What am I missing here? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6158
Location: Dallas area
|
| Posted: Sat Sep 23, 2023 2:26 pm Post subject: |
|
|
If you want to use the MB based uefi, then efibootmgr is what you want.
If you want a disk based uefi, then several manager will work, systemd-boot/gummiboot, refind, grub, etc.
I suppose you could use efibootmgr with something like refind, but the question that comes to my mind is "why?"
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
De-Javu
n00b
Joined: 30 Mar 2009
Posts: 24
Location: USA
|
| Posted: Sat Sep 23, 2023 10:25 pm Post subject: Re: Mountpoint for the ESP |
|
|
| szatox wrote: | Are we talking about some very different setups, like on-disk refind vs refind embedded in mobo's eeprom?
Why use efibootmgr for managing refind; how is it even supposed to work, when they are 2 different ways of achieving the same goal? What am I missing here? |
Yes, exactly - and Anon-E-moose basically answered this. Nobody puts GRUB/LILO/systemd-boot directly to a USB Stick, for example, 
However, to answer your other question, typically rEFInd is installed using efibootmgr, and you pass the options for configuration to efibootmgr for install. In this context, imagine efibootmgr as doing "grub-install" 's job. Edit: Responding to sMueggli on the next page: You use efibootmgr to install rEFInd, remember!
By "on-disk" I assume you mean installed to the internal HDD/SSD instead of removable media like a USB Stick or SD Card. rEFInd being used as an on-disk boot manager instead of GRUB/LILO/systemd-boot is very rare. 7, 8 years ago, there was more reason to use rEFInd for your on-disk install. Nowadays, and in the last few years - not at all.
Last edited by De-Javu on Sun Sep 24, 2023 10:13 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
