or in }\texttt{\DIFadd{\{boot\}/loader/entries/*.conf}}\DIFadd{files (for instance }\texttt{\DIFadd{/boot/loader/entries/*.conf}}\DIFadd{).
The former layout -- pure Boot Loader Specification, using kernel files on the EFI System Partition or
Extended Boot Loader Partition -- is specific to systemd-boot, the latter
layout with kernel files typically on the partition which will be mounted as }\texttt{\DIFadd{/boot}}
\DIFadd{applies to most Fedora-related distros including Fedora itself, RHEL and variants.
}
\DIFadd{BootLoaderSpecByDefault includes the possibility of expanding GRUB variables
in its }\texttt{\DIFadd{*.conf}}\DIFadd{files -- and this is used in practice in certain distros such as CentOS.
In order to correctly handle this, }\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{extracts all variables from
}\texttt{\DIFadd{\{boot\}/grub2/grubenv}}\DIFadd{and any unconditionally set variables from }\texttt{\DIFadd{\{boot\}/grub2/grub.cfg}}\DIFadd{.
This has proved sufficient in practice to extract the required variables seen so far in distros which use this
GRUB-specific feature.
}
\DIFadd{For distributions which do not use either of the above schemes, }\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{will autodetect and
boot }\texttt{\DIFadd{\{boot\}/vmlinuz*}}\DIFadd{kernel files directly, after linking these automatically -- based on the
kernel version in the filename -- to their associated }\texttt{\DIFadd{\{boot\}/init*}}\DIFadd{ramdisk files, and after
searching in }\texttt{\DIFadd{/etc/default/grub}}\DIFadd{for kernel boot options and }\texttt{\DIFadd{/etc/os-release}}\DIFadd{for the
distro name.
This layout applies to most Debian-related distros, including Debian itself, Ubuntu and variants.
}
\DIFadd{The method of starting the kernel relies on it being compiled with EFISTUB, however this applies
to almost all modern distros, particularly those which use systemd. Most modern distros
use systemd as their system manager (even though at the same time most do }\emph{\DIFadd{not}}\DIFadd{use systemd-boot as
their bootloader).
}
\DIFadd{The latest kernel version of a given install is always shown in the boot menu. Additional versions,
recovery versions, etc. are added as auxiliary boot entries, so depending on OpenCore's
}\texttt{\DIFadd{HideAuxiliary}}\DIFadd{setting may not be shown until the space key is pressed.
}
\emph{\DIFadd{Note 1}}\DIFadd{: }\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{requires filesystem drivers that may not be available in
firmware such as EXT4 and BTRFS drivers. These drivers can be obtained from external sources.
Drivers tested in basic scenarios can be downloaded from }\href{https://github.com/acidanthera/OcBinaryData}{\DIFadd{OcBinaryData}}\DIFadd{.
Be aware that these drivers are neither tested for reliability in all scenarious, nor underwent any
tamper-resistance testing, therefore have may carry potential security or data-loss risks.
}
\DIFadd{Most Linux distributions keep their boot files on the EXT4 file system even when the distribution's
main filesystem is something else such as BTRFS, therefore a suitable UEFI EXT4 file system
driver such as }\href{https://github.com/acidanthera/OcBinaryData}{\texttt{\DIFadd{ext4\_x64}}}\DIFadd{is normally required.
A BTRFS driver such as }\href{https://github.com/acidanthera/OcBinaryData}{\texttt{\DIFadd{btrfs\_x64}}}
\DIFadd{will be required in a somewhat less standard setup where the boot files are on a BTRFS partition,
e.g. as by default in openSUSE.
}
\DIFadd{Pure Boot Loader Spec (e.g. as implemented by systemd-boot) keeps all kernel and ramdisk images directly
on the EFI System Partition (or an Extended Boot Loader Partition), therefore it requires no additional
filesystem driver - but it is not widely used except in Arch Linux.
}
\emph{\DIFadd{Note 2}}\DIFadd{: systemd-boot users (probably almost exclusively Arch Linux users) should be aware that }\texttt{\DIFadd{OpenLinuxBoot}}
\DIFadd{does not support the systemd-boot--specific }\href{https://systemd.io/BOOT\_LOADER\_INTERFACE/}{\DIFadd{Boot Loader Interface}}\DIFadd{;
therefore use }\texttt{\DIFadd{efibootmgr}}\DIFadd{rather than }\texttt{\DIFadd{bootctl}}\DIFadd{for any low-level Linux command line interaction with
the boot menu.
}
\DIFadd{The default parameter values should work well, but if you need to parameterise this driver the following
options may be specified in }\texttt{\DIFadd{UEFI/Drivers/Arguments}}\DIFadd{:
}
\begin{itemize}
\tightlist
\item\texttt{\DIFadd{flags}}\DIFadd{- Default: all flags except }\texttt{\DIFadd{LINUX\_BOOT\_ADD\_DEBUG\_INFO}}\DIFadd{are set. }\medskip
\emph{\DIFadd{Note}}\DIFadd{: The }\texttt{\DIFadd{partuuid}}\DIFadd{value to be specified here is typically the same as the }\texttt{\DIFadd{PARTUUID}}
\DIFadd{seen in }\texttt{\DIFadd{root=PARTUUID=...}}\DIFadd{in the Linux kernel boot options (view using
}\texttt{\DIFadd{cat /proc/cmdline}}\DIFadd{) for autodetected Debian-style distros, but is NOT the same for
Fedora-style distros booted from }\texttt{\DIFadd{/loader/entries/*.conf}}\DIFadd{files. }\medskip
\DIFadd{Typically you should not need this option in the latter case, but in case you do, to find out the unique
partition uuid to use, look for }\texttt{\DIFadd{LNX:}}\DIFadd{entries in the OpenCore debug log file. Alternatively, and
for more advanced scenarios, you may wish to examine how your drives are mounted using the
Linux }\texttt{\DIFadd{mount}}\DIFadd{command, and then find out the partuuid of relevant mounted drives by examining the
output of }\texttt{\DIFadd{ls -l /dev/disk/by-partuuid}}\DIFadd{. }\medskip
\item\texttt{\DIFadd{autoopts}[\DIFadd{+}]\DIFadd{="\{options\}"}}\DIFadd{- Default: None specified. The kernel options to use
for autodetected Linux only. The value here is never used for entries created from
}\texttt{\DIFadd{/loader/entries/*.conf}}\DIFadd{files. }\texttt{\DIFadd{partuuidopts}}\DIFadd{may be more suitable where there are multiple
distros, but }\texttt{\DIFadd{autoopts}}\DIFadd{with no PARTUUID required is more convenient for just one distro.
If specified with }\texttt{\DIFadd{+=}}\DIFadd{then these are used in addition to autodetected options, if specified
with }\texttt{\DIFadd{=}}\DIFadd{they are used instead. As example usage, it is possible to use }\texttt{\DIFadd{+=}}\DIFadd{format to add
a }\texttt{\DIFadd{vt.handoff}}\DIFadd{options, such as }\texttt{\DIFadd{autopts+="vt.handoff=7"}}\DIFadd{or }\texttt{\DIFadd{autopts+="vt.handoff=3"}}
\DIFadd{(check }\texttt{\DIFadd{cat /proc/cmdline}}\DIFadd{when booted via your existing bootloader) on Ubuntu and related distros,
in order to add the }\texttt{\DIFadd{vt.handoff}}\DIFadd{option to the auto-detected GRUB defaults, and avoid a flash of text
showing before the distro splash screen.
}\medskip
\DIFadd{Users may wish to compare their Linux boot options (shown with }\texttt{\DIFadd{cat /proc/cmdline}}\DIFadd{) seen when booting via
}\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{and via their distro's original bootloader, which is normally GRUB (but might also be e.g.
systemd-boot or EXTLINUX). Expect the options generated by }\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{not to
contain a }\texttt{\DIFadd{BOOT\_IMAGE=...}}\DIFadd{value where GRUB options do, and to contain an
}\texttt{\DIFadd{initrd=...}}\DIFadd{value where the GRUB options do not, since GRUB hands over ramdisks in a different way.
All remaining parameters should match, however -- perhaps excluding less important graphics handover options,
such as in the Ubuntu example given in }\texttt{\DIFadd{autoopts}}\DIFadd{.
}\texttt{\DIFadd{OpenLinuxBoot}}\DIFadd{will not start a distro unless it can find some configured options to use, therefore in
the hopefully unlikely case where no auto-detectable options are available, the user will need to specify the correct options
with }\texttt{\DIFadd{partuuidopts}}\DIFadd{or }\texttt{\DIFadd{autoopts}}\DIFadd{before the distro will boot. Examine the OpenCore debug log
for }\texttt{\DIFadd{LNX:}}\DIFadd{entries containing further information about what was found.
