rEFInd General Discussion: Detecting Linux distro from an unified kernel image (original) (raw)

• Summary
• Files
• Reviews
• Support
• Code
• Discussion

Menu ▾ ▴

Detecting Linux distro from an unified kernel image

Created: 2020-02-13

Updated: 2020-02-19

• 
  rEFInd doesn't detect the Linux distribution from a unified kernel image placed in /EFI/Linux/.
  The file name of the EFI binary doesn't seem to matter.
  Would it be possible for rEFInd to gain the ability to detect the Linux distro from the unified kernel image's embeded os-release?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
• 
  I'd never before heard of this file format. I've only read it over once, but it looks like determining the distribution would require spelunking through the contents of the kernel file. I don't know offhand how much support EFI provides for separating out the various PE sections, vs. how much rEFInd would have to parse those itself. (Obviously, the EFI has to do some of this internally to launch a program, but I don't know if the EFI exposes such capabilities to running applications.) My hunch is that the EFI wouldn't be much help with this, given that the EFI itself needs this information only when it begins to launch an application.
  One downside to looking for this information is that it will take time -- whether the EFI can read an executable and expose the information to rEFInd or rEFInd would have to do it itself, reading a file takes time. Currently, rEFInd does read the first 512 bytes of every file it scans to determine if it's a valid EFI program file, but if implementing this new feature would require reading the entire file, the cost in time could be prohibitive, especially if the filesystem in question is slow. (Some EFIs, for reasons I don't fully understand, produce abysmal performance with some add-on drivers. The rEFInd ext2fs driver seems particularly troublesome in this respect.) Perhaps this deep scan could be restricted to kernels in the $BOOT/EFI/Linux/ directory, as noted in the Boot Loader Specification, to minimize the impact of this issue; or perhaps the information can be extracted from the first few KiB of the file, which would also minimize the impact.
  There's also the question of how useful this would be. I've been waiting for years for the systemd Boot Loader Specification to gain traction, but aside from a few niche distributions that have embraced it, it's not exactly taken off. This variant is therefore unlikely to become a big deal in the Linux ecosystem, although of course I could be wrong about that. The only thing that rEFInd does with information about the distribution associated with a kernel is to add an appropriate icon, so this isn't exactly core functionality, although it is admittedly useful information to present to users on a multi-distribution installation.
  The bottom line is that I'm sure rEFInd could be modified to support this feature, but I'm not sure it's worth it, especially for "eye candy." An easy alternative already exists: Creating .png files named identically to the kernels except for their extensions. This could be a bit tedious to maintain, depending on the OS's kernel-naming conventions, but it should work now. That said, I'll give it some thought and perhaps look into it. It's a pretty low priority for me personally, though. If you care to try yourself, I'll certainly consider a merge request or patch that adds this functionality. (Unfortunately, rEFInd's methods for setting tag icons are scattered about and need to be consolidated in a saner way, so figuring out that side of it will likely prove to be challenging, too.)
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  • 
    dracut, a popular initramfs generator, recently supports creating an EFI Unified Kernel Image (type #2 in the boot loader specification) by using the systemd EFI stub as its base and combining Microcode + Initramfs + Kernel + Kernel Parameters and then using sbsign to sign one single unified EFI executable. All of this done with one command, for example, after each kernel update.
    I think it is pretty neat to have it all in a single EFI executable and getting better support for parsing the EFI stub's vma section header from our favourite boot manager would be a big plus.
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  • 
    I am able to get the .osrel vma section of an EFI Unified Kernel Image built with systemd EFI stub with:

  objcopy /efi/EFI/archlinux/linux-signed.efi --dump-section .osrel=/dev/stdout

  NAME="Arch Linux"
  PRETTY_NAME="Arch Linux"
  ID=arch
  BUILD_ID=rolling
  ANSI_COLOR="0;36"
  HOME_URL="https://www.archlinux.org/"
  DOCUMENTATION_URL="https://wiki.archlinux.org/"
  SUPPORT_URL="https://bbs.archlinux.org/"
  BUG_REPORT_URL="https://bugs.archlinux.org/"
  LOGO=archlinux
  Last edit: Neurognostic 2020-02-17
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  *
  Unfortunately, getting the .osrel section in Linux is irrelevant; the trick is to get it from the EFI, which is where rEFInd does its scans. Extracting that would either need to be a standard feature provided by the EFI or code to do so would have to be added to rEFInd itself. (I suspect the EFI doesn't provide this feature; and if it did, it would probably require reading the whole binary, which would likely be time-prohibitive. Thus, I suspect rEFInd would have to parse the binary -- but I'm not at all certain of that.) Either way, I don't know how tricky it would be to get the data.
  Also, the fact that this binary format is being used may not be relevant. If the major distributions continue to put their boot loaders in their own /boot directories on their own root partitions, then rEFInd's existing code for detecting the distribution will continue to work fine. Extracting the information from the unified kernel binary would make sense if distributions switch to the Boot Loader Specification kernel placement (which could rob rEFInd of the context it uses to figure this out) or when kernels are on separate /boot partitions, which can remove some context (like /etc/os-release).
  In fact, it's occurred to me that modifying the refind_linux.conf file to provide an icon/distribution hint might be much easier than trying to dig the information out of the kernel binary itself. refind-install (or mkrlconf) could set this up pretty easily.
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  *
  I believe systemd-boot has an example extracting .osrel, I am not sure if they are reading the whole file or just navigating to and reading a specific offset ( I do not read C ).
  https://github.com/systemd/systemd/blob/d4ffda38716d33dbc17faaa12034ccb77d0ed68b/src/boot/efi/boot.c#L1932
  They use it, at least, for displaying the build_Id beside each EFISTUB automatically discovered in EFI/Linux.
  ---
  Using refind_linux.conf for hinting icon discovery could work for icons, but for distributions/users who try to follow the Boot Loader Specification (while they may or may not be few; idk) must rely on manual stanzas in refind.conf when the context needed for autodiscover is right there embeded in the kernel binary.
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

• 
  If it was possible to extract only the .osrel section, that would probably be ideal.
  Regarding the Boot Loader Specification, I don't think anyone's actually beleves it will gain any traction, but I think the unified kernel images (or at least the concept of it) is an exception.
  The unified kernel images are somewhat popular among Secure Boot users, as they alow to combine the kernel, initramfs and kernel command line in one file which can then be signed.
  Regarding specifications made by systemd, I just remebered another one, which rEFInd doesn't support: The Boot Loader Interface.
  I'm only interested in LoaderDevicePartUUID, so that systemd-gpt-auto-generator can automount the EFI system partition. I actually asked about this before https://sourceforge.net/p/refind/discussion/general/thread/4b29334c/#f9aa .
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.

Want the latest updates on software, tech news, and AI?

Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.