-
-
Notifications
You must be signed in to change notification settings - Fork 158
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
553b132
commit 61d6957
Showing
1 changed file
with
89 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,89 @@ | ||
| --- | ||
| feature: uefi_boot_only | ||
| start-date: 2023-06-16 | ||
| author: Ryan Lahfa | ||
| co-authors: (find a buddy later to help out with the RFC) | ||
| shepherd-team: (names, to be nominated and accepted by RFC steering committee) | ||
| shepherd-leader: (name to be appointed by RFC steering committee) | ||
| related-issues: (will contain links to implementation PRs) | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| NixOS should drop support for legacy boot and assumes that | ||
| all systems can be booted off UEFI. | ||
| For legacy boot systems, an UEFI-providing environment bootloader should be used to polyfill | ||
| for UEFI features. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| Legacy boot is defined by the BIOS Boot specification, written in 1996: https://www.scs.stanford.edu/nyu/04fa/lab/specsbbs101.pdf. | ||
| Nowadays, computers are defaulting to UEFI more and more for the extended features provided (e.g. SecureBoot, native network boot, etc.). | ||
|
|
||
| Nevertheless, many legacy boots machines or machines that does not have support for UEFI are used with NixOS: Single Board Computers for example | ||
| on other architectures. | ||
|
|
||
| In nixpkgs, legacy boot forces a dichotomy between `boot.loader.efi` and... two legacy bootloaders: GRUB and a family of UBoot/extlinux-compatible/etc. | ||
|
|
||
| In the case of GRUB, there are increasing problems with this bootloader: | ||
|
|
||
| - Upstream do not do releases anymore: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/misc/grub/default.nix#L62-L350 | ||
| - Co-maintenance / release work with other ecosystems such as the kernel is simply not done: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/misc/grub/default.nix#L345-L349 causing GRUB's drivers to explode in production for our users: https://github.com/NixOS/nixpkgs/pull/235222 | ||
| - Our own maintenance of GRUB is subpar: https://github.com/NixOS/nixpkgs/pull/227741 https://github.com/NixOS/nixpkgs/pull/226821 https://github.com/NixOS/nixpkgs/pull/195805 https://github.com/NixOS/nixpkgs/pull/95901 https://github.com/NixOS/nixpkgs/pull/236027 | ||
| - GRUB installation procedure uses `install-grub.pl`, one of the remaining Perl script: https://github.com/NixOS/nixpkgs/pull/95901#issuecomment-756702696 offered to rewrite it with sponsoring, but no one took the offer yet, it is also very complicated to integrate with it: https://github.com/nix-community/lanzaboote/pull/96 | ||
| - GRUB installation procedure for UEFI-only is still confusing because our scripts does not handle well UEFI-only (you have to pass `nodev` and this is not very well documented). See https://github.com/NixOS/nixpkgs/issues/222491 | ||
|
|
||
| The worse about this, is this is our **default** bootloader for our install images **because** of legacy boot. | ||
|
|
||
| In the case of UBoot/extlinux-compatible/etc. : we should definitely keep it as it is used by other ecosystems. | ||
|
|
||
| Getting rid of legacy boot opens up the way to get rid of GRUB as a default and enable all our users to benefit from UEFI-in-mind developed abstractions. | ||
|
|
||
| BIOS also hold back all improvements in the boot story, considering we are not held back by this, is very interesting for NixOS. | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| Legacy boot is booted via UBoot or any bootloader able to provide an UEFI environment. | ||
|
|
||
| Then, we boot using any usual bootloader, e.g. systemd-boot. | ||
|
|
||
| # Examples and Interactions | ||
| [examples-and-interactions]: #examples-and-interactions | ||
|
|
||
| Fedora is considering doing this: https://lists.fedoraproject.org/archives/list/[email protected]/thread/GOETDM5SWINBX5ZDV37SWMHIPRRUVVTT/. | ||
|
|
||
| Asahi Linux is booting UEFI via UBoot without EFI variables and it has been great for them. | ||
|
|
||
| People who want to boot off strange partitions at boot-time can exploit UEFI drivers capability to load any filesystem driver and | ||
| open the EFI System Partition in ZFS if they really insist. | ||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| - 2-stage boot for legacy BIOS systems is more than 1-stage boot | ||
| - Increased internal complexity in the boot story of NixOS | ||
| - Increased load and reliance on UBoot | ||
| - The runtime service `SetVariable` will probably stay highly unstable for a while (variable storage) | ||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - Keeping legacy BIOS and hoping someday it will be a bit more maintained | ||
| - Getting rid of legacy BIOS without other options | ||
|
|
||
| Then, if we don't do this, we will continue to have users relying on bootloaders with shady maintenance stories and a skewed perception of what a bootloader can do (e.g. boot on a ZFS partition?). | ||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| - When to do it? | ||
| - What to do about variable storage (Asahi Linux showed this is not that important for a start)? | ||
| - Design architecture in nixpkgs? | ||
|
|
||
| # Future work | ||
| [future]: #future-work | ||
|
|
||
| - Improved support for UEFI features on non-UEFI native systems |