Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XBOOTLDR support #173

Open
colemickens opened this issue May 3, 2023 · 11 comments
Open

XBOOTLDR support #173

colemickens opened this issue May 3, 2023 · 11 comments
Milestone

Comments

@colemickens
Copy link
Member

As far as I can tell, there's no option to tell Lanzaboot to install the bootloader entries to /boot, with the bootloader itself residing on /efi.

This is necessary for systems that are dual-boot and have to deal with Windows anemic 512MB ESP.

This is something I implemented for systemd-boot in : NixOS/nixpkgs#226692

@colemickens
Copy link
Member Author

From a quick skim, I guess that most places where esp_paths is propagated to/through Installer, a similar variable, entries_path(s) could be added for this parameters.

@colemickens
Copy link
Member Author

Ope, maybe I'm wrong, this looks like a lot of paths... hm.

pub fn new(esp: impl AsRef<Path>) -> Self {

@colemickens
Copy link
Member Author

colemickens commented May 3, 2023

Just to illuminate this quickly for anyone unfamiliar with it:

  • /boot is a specially marked vfat part
  • /efi is the ESP part

╭ zeph  ~/code/nixcfg 0.01s
╰─▶ exa -al --tree --level 3 /boot
drwxr-xr-x    - root 31 Dec  1969 /boot
drwxr-xr-x    - root 23 Apr 15:14 ├── EFI
drwxr-xr-x    - root  2 Jan 22:59 │  ├── Linux
drwxr-xr-x    - root  2 May 16:33 │  └── nixos
drwxr-xr-x    - root  2 May 16:33 │     ├── .extra-files
.rwxr-xr-x  52M root  2 May 16:33 │     ├── 9920dchp0yjc0dqx34yag9fq2ifdmv8l-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x  51M root  2 May 16:33 │     ├── a4i5wblhjhqgb7qfqh8lypqybqd8h2dg-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x  51M root  2 May 16:33 │     ├── acn81cicvkrqv202r1njwrn7qxvc1xyd-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x  49M root  2 May 16:33 │     ├── ars088s92c751rg5mv2l5hhpb1qcp22a-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x  52M root  2 May 16:33 │     ├── aypnb0n4608vgx7jcppv21mpqriz97cp-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x  52M root  2 May 16:33 │     ├── c4sfzink5na1vrid6mglk3rhs5mrfg14-initrd-linux-6.2.13-initrd.efi
.rwxr-xr-x 9.8M root  2 May 16:33 │     ├── dwfs0ayw1jnjvrjk7903sw4xr6bssc7r-linux-6.2.13-bzImage.efi
.rwxr-xr-x 9.8M root  2 May 16:33 │     ├── h5a07lsxf0ywn6ryj3zxracb88wyfbf6-linux-6.2.13-bzImage.efi
.rwxr-xr-x  49M root  2 May 16:33 │     ├── jzfibarpqvsv34qci8lihski6q8b0h4z-initrd-linux-6.2.13-initrd.efi
drwxr-xr-x    - root  2 Apr 04:47 └── loader
drwxr-xr-x    - root  2 May 16:33    ├── entries
.rwxr-xr-x  464 root  2 May 16:33    │  ├── nixos-generation-4-specialisation-legacyboot.conf
.rwxr-xr-x  466 root  2 May 16:33    │  ├── nixos-generation-4-specialisation-sysd-netboot.conf
.rwxr-xr-x  451 root  2 May 16:33    │  ├── nixos-generation-4.conf
.rwxr-xr-x  464 root  2 May 16:33    │  ├── nixos-generation-5-specialisation-legacyboot.conf
.rwxr-xr-x  466 root  2 May 16:33    │  ├── nixos-generation-5-specialisation-sysd-netboot.conf
.rwxr-xr-x  451 root  2 May 16:33    │  ├── nixos-generation-5.conf
.rwxr-xr-x  464 root  2 May 16:33    │  ├── nixos-generation-6-specialisation-legacyboot.conf
.rwxr-xr-x  466 root  2 May 16:33    │  ├── nixos-generation-6-specialisation-sysd-netboot.conf
.rwxr-xr-x  451 root  2 May 16:33    │  └── nixos-generation-6.conf
.rwxr-xr-x    6 root 31 Dec  2022    └── entries.srel

╭ zeph  ~/code/nixcfg 0.01s
╰─▶ exa -al --tree --level 3 /efi
drwxr-xr-x   - root 31 Dec  1969 /efi
drwxr-xr-x   - root  2 May 19:05 ├── EFI
drwxr-xr-x   - root 27 Apr 11:19 │  ├── Boot
.rwxr-xr-x 99k root 31 Dec  1979 │  │  └── bootx64.efi
drwxr-xr-x   - root 30 Jan  2022 │  ├── Microsoft
drwxr-xr-x   - root 30 Jan  2022 │  │  ├── Boot
drwxr-xr-x   - root 30 Jan  2022 │  │  └── Recovery
drwxr-xr-x   - root 27 Apr 11:19 │  └── systemd
.rwxr-xr-x 99k root 31 Dec  1979 │     └── systemd-bootx64.efi
drwxr-xr-x   - root  2 May 16:33 ├── loader
.rwxr-xr-x  60 root  2 May 16:33 │  ├── loader.conf
.rwxr-xr-x  32 root  1 May 22:12 │  └── random-seed
drwxr-xr-x   - root 30 Jan  2022 └── System Volume Information

@colemickens
Copy link
Member Author

(A small note, the Windows default ESP now seems to be about 100MB, making this more important for such systems)

@colemickens
Copy link
Member Author

last update: for now this works for me:

config = {
  fileSystems = {
     # ..
      "/efi/EFI/Linux" = { device = "/boot/EFI/Linux"; options = ["bind"];};
      "/efi/EFI/nixos" = { device = "/boot/EFI/nixos"; options = ["bind"];};
    };
}

otherwise things went well according to the quickstart! thanks!

@RaitoBezarius
Copy link
Member

Is there any action we should do to your opinion to enable better support of XBOOTLDR?

@colemickens
Copy link
Member Author

@RaitoBezarius I'm not really sure! I think, generally, NixOS should make this pattern easier to achieve, and as far as I know, it's basically just not supported (without my PR for systemd-boot anyway). And thus similarly lanzaboot.

Personally, I would prefer lanzaboot to not require me to (manually) set up bind mounts, when they're really only here to workaround what feels like a feature deficit in Lanzaboot. I do feel like the "right" solution is for Lanzaboot to internally have a concept of "payloadPath" (maybe, rather than entriesPath) since in this case lanzaboot is installing EFI binaries, rather than entries conf files). And then this would be exposed out to the nixos module.

So, in my opinion, ideally I'd be able to remove the bind mount and then set boot.lanzaboot.payloadPath = "/boot" and have it work.

@RaitoBezarius
Copy link
Member

cc @nikstur

I don't really like payloadPath, I think we should have the extension extendedPath in bootspec (no pun) and keep the efiSysMountPoint parameter (which already exist) and rely on this for EFI.

And then, we could have extendedPath as part of boot.extendedPath and be it an sanctioned nixpkgs extension of bootspec.

@colemickens
Copy link
Member Author

I haven't fully had a chance to grok what is "in scope" of bootspec, vs extensions, vs left up to the "installer", so I can't offer an opinion. But I do like the last sentence, anyway. I do think I'm a bit nervous about what I'd argue is core functionality in extensions, but I also haven't had a chance to wrap my head around extensions, how they work, if there's a graduation path for them, etc.

Personally, I think most tools around bootloaders make some invalid assumptions that everything goes into the ESP (see, nixpkgs/lanzaboot having the ability to configure the ESP path, but not the path for installing payloads). This isn't true with xbootldr, and I'd argue, it's "cleaner" this way too. I like my ESP just containing the bootloader and then the /boot partition containing the actual payloads.

@RaitoBezarius RaitoBezarius added this to the Release 2.0.0 milestone May 18, 2023
@bb010g
Copy link

bb010g commented Mar 11, 2024

Note that NixOS/nixpkgs#285401 has finally been merged.

@JohnRTitor
Copy link

Note: the PR to support xbootldr partition has been accepted into nixpkgs, it's available as a option. boot.loader.systemd-boot.xbootldrMountPoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants