Talk:EFI System Partition

From Gentoo Wiki
Jump to:navigation Jump to:search
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 17:20, 18 June 2024 (UTC)
:: Your reply ~~~~

openrc efivars

Talk status
This discussion is done.

As per gentoo-dev mailing list,

The documentation should be updated to say that with OpenRC 0.28 that you'll have to remount efivars as RW before you can install the bootloader (e.g., grub-install)

The command I use locally to remount rw (since I have configured efivars to be mounted read-only in fstab) is

mount -o remount,rw /sys/firmware/efi/efivars


--Rage (talk) 01:16, 13 July 2017 (UTC)

That's off-topic here. Stuff specific to bootloaders should go to the respective bootloader article. --Charles17 (talk) 05:50, 13 July 2017 (UTC)

Kernel EFI framebuffer support

Any kernels being loaded in an ESP will need "EFI-based Framebuffer Support" enabled in the kernel. This kernel requirement is not listed anywhere on EFI pages or pages for EFI-based services, such as rEFInd, GRUB2, or the EFI stub. It is also not on the wiki's Framebuffer page. Discovering that it's a hard requirement for loading a kernel from an ESP was an especially painful and difficult process for me, as this setting happened to be disabled when I tried to migrate from legacy BIOS to an EFI-based boot. The help thread where I struggled with the problem and identified this requirement is here:

This kernel requirement should absolutely be present in the Gentoo wiki, however I am not 100% sure where to put it. I elected to add it here as it is general a requirement for use of the gentoo kernel from an ESP generally and not specific to an individual service. However, I could also add it to each of the EFI-based services pages instead, such as the rEFInd, GRUB2 and EFI stub pages. It just needs to be somewhere where a user attempting to migrate from a legacy bios with potentially old kernel settings will see it as they make their migration. A user would not, for example, be expected to know to visit a page about framebuffers during the EFI migration process.


--AECFXI (talk) 08:54, 25 August 2021 (UTC)

This is an important point and you may want to add it at least to EFI_stub where you could add it directly above the EFI_stub#Installation section, restricting it to computers that need a graphical interface (Or, doe also servers need that setting?). An additional mention in the Framebuffer article would be a good idea.
However, on the EFI_System_Partition article it was definitely misplaced as is has nothing to do with that partition.
--Vaukai (talk) 11:18, 25 August 2021 (UTC)
This kernel configuration requirement is necessary for the kernel to display any output. This includes any kind of text output or shell access. One user report seems to indicate there is a kernel panic after attempting to load due to flashing keyboard lights, but it is difficult to more definitively assess if the kernel is even running as it cannot even output a kernel panic dialog.
I don't understand why you would say this has nothing to do with the ESP if the ESP cannot be utilized by Gentoo linux without this kernel setting being enabled. There is no way I'm aware of that an ESP function without it being set, the setting is named EFI and this is the most general EFI page. At some point point all EFI users must to be pointed to this framebuffer setting. It could just be a line of text with a link to the Framebuffer article, but would that really make sense for just one kernel setting that should always be enabled by EFI users with no further nuance or actions? With all that said, I will go ahead add it to the pages for all the discrete EFI services for now.
--AECFXI (talk) 12:28, 25 August 2021 (UTC)
"EFI Framebuffer" has nothing to do with an ESP itself. A system booting to EFI must have a framebuffer of some sort to display video, but not necessarily "EFI framebuffer". It could be specific to their graphics chip such as DRM_I915, DRM_AMDGPU, or DRM_NOUVEAU. An ESP is simply a partition with certain UUID attached to it. An EFI boot will look for that UUID. Again, having an ESP does not require "EFI Framebuffer" at all. With the current articles on the wiki, I am unsure the best place to explain it. Here is certainly not the best place. Ideally, a well written section/addition to the Handbook would be the best (e.g. Handbook:AMD64/Installation/Kernel#Architecture_specific_kernel_configuration ) Technically, it is not required to output video if the system is headless as well --Grknight (talk) 12:57, 25 August 2021 (UTC)
" A system booting to EFI must have a framebuffer of some sort to display video, but not necessarily "EFI framebuffer". " I tested a number of different kernels with varied framebuffer settings instead of EFI framebuffer, such as "nVidia Framebuffer Support" (I run an nvidia card with nvidia-drivers), "Simple framebuffer support", and "VESA VGA graphics support". In all cases, kernel behavior reverted to its no-output, possibly panicked state. So this does not appear to be true from the testing I performed. There was also the evidence that there was a kernel panic via flashing keyboard lights as well, re:running in a headless state.
I agree that it is somewhat awkward to find a place for this kernel requirement, however what is most important is that users migrating from legacy BIOS to an EFI boot encounter the requirement on pages they can reasonably be expected to visit or they may be left without a working system that is nearly impossible to diagnose. I can absolutely add this as as an item to the handbook, but few if any users will think to visit the handbook's architecture specific kernel configuration page when encountering a problem that is very difficult to diagnose. (Does it even make sense for the handbook to include a kernel requirement if (U)EFI is used to boot the system, and then not include that requirement on the EFI page?) A compromise I would suggest is to close the EFI System Partition article with a "Troubleshooting" section with information about this kernel setting requirement. Would this be acceptable to you?
--AECFXI (talk) 13:46, 25 August 2021 (UTC)
First off, no one should ever use "nVidia Framebuffer" unless the machine is ancient and not using nvidia-drivers. There is no kernel panic by not having "EFI Framebuffer" enabled but to know what panicked requires other setups such as a serial console or ssh via initramfs. The most common panic is a system not being able to find the rootfs without an initramfs which again has nothing to do with ESP or EFI just poor configuration. "Simple framebuffer" requires the graphics be setup by something else such as GRUB which will leave the graphics mode in a state to be read. "VESA" is not an option in EFI since there is no VGA output. As to finding this in troubleshooting, I am doubtful that users will look for this article much at all when looking for panic /no graphics solutions. My best advice for any "conversion" is have an initramfs to avoid panics and load any necessary framebuffer (EFI, Simple, or vendor DRM/KMS (not vendor framebuffer directly)). --Grknight (talk) 14:04, 25 August 2021 (UTC)
I appreciate you explaining these framebuffer kernel options to me and helping me better understand how I might construct working EFI system without the EFI-based framebuffer setting. This is useful knowledge for how I can best communicate the system requirement and help support others. I'm trying to make this contribution because I myself was an intermediate level user on this and other EFI pages trying to create an EFI boot on a previously working legacy system and got stuck for a few days trying to figure out what its problem was, and I want people like me to be informed in the way I was not. Having this requirement on the discrete EFI service pages with your adjusted wording serves this purpose, however. I will introduce the requirement on the noted handbook page or its discussion after some further testing on my system to make sure there is a reasonable case for including it.
--AECFXI (talk) 15:03, 25 August 2021 (UTC)