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

flake support #129

Closed
wants to merge 1 commit into from
Closed

flake support #129

wants to merge 1 commit into from

Conversation

mlyxshi
Copy link

@mlyxshi mlyxshi commented Dec 23, 2023

Compared to #128, systemd-initrd and traditional initrd are both supported. flake and systemd-initrd are non-mandatory.

I haven't tested the traditional initrd, I think it should work.

The problem here is that /Volumes/EFI - NIXOS/vendorfw/firmware.cpio can become out of date when asahi-fwextract gets upgraded. But so too can the all_firmware.tar.gz and the macOS stub partition. All three have happened so far.

My preferred solution would be to have a derivation download and extract the firmware from the Apple recovery image, but that's pretty gnarly and does not solve the third problem.

This is a temporary solution for better flake user experience.

@tpwrules
Copy link
Owner

This is better than #94 but I think it's still susceptible to race conditions.

I think there's some way for the kernel to load the .cpio directly? Maybe we need to fiddle with the bootloader config.

Please allow me a bit to play around and think how best to accomplish this. I understand the concern with flakes but I think it would be easy to subtly break things by changing how this is done.

@zzywysm
Copy link
Contributor

zzywysm commented Dec 30, 2023

Some code review notes:

  1. You should be using /lib/firmware/vendor, not /lib/firmware . This is documented in https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-Macs , and has been clearly supported for a long time thanks to AsahiLinux/linux@07db737
  2. The firmware.cpio file is intended to be loaded directly, as @tpwrules mentioned above. Until we figure out how to do that, it seems much simpler to use the firmware.tar file. This way, you can avoid creating and removing a /tmp/.fwsetup/ directory, and instead do something like:

tar -xf /sysroot/boot/vendorfw/firmware.tar -C /sysroot/lib/firmware/vendor

(Obviously, you'll need to grab tar from the gnutar package instead of cpio from the cpio package.)

@zzywysm
Copy link
Contributor

zzywysm commented Dec 30, 2023

2. The firmware.cpio file is intended to be loaded directly, as @tpwrules mentioned above. Until we figure out how to do that...

I think I figured the broad outline out, but NixOS is going to fight us.

If you look at /boot/loader/entries/nixos-generation-*.conf, they follow this format:

title NixOS
version Generation 52 NixOS Uakari 24.05pre561409.54aac082a4d9 (Linux 6.6.0-asahi), built on 2023-12-29
linux /efi/nixos/v1a8mj7fhs60rjdwx8jxd33whx8b54ig-linux-6.6.0-asahi-Image.efi
initrd /efi/nixos/a2pdvxdrigzyfj3wfc3mfrisvpqal6m9-initrd-linux-6.6.0-asahi-initrd.efi
options init=/nix/store/pgmngxjb4lbagd9szv5gxb50hrmxgga8-nixos-system-greenrosetta-24.05pre561409.54aac082a4d9/init [BOOTARGS ELIDED]
machine-id [ELIDED]

The documentation of this format (https://uapi-group.org/specifications/specs/boot_loader_specification/ ) says that you can have more than one initrd entry, and that they are expected to be in cpio format.

The problem is that the nixpkgs code that generates these .conf files (https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py ) only ever expects to include one initrd entry. And because it's written in Python and not Nix, this severely limits the code's extensibility.

I think unless we modify how NixOS interacts with systemd-boot, we should stick with firmware.tar and ignore firmware.cpio.

@mlyxshi mlyxshi closed this by deleting the head repository Jan 30, 2024
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

Successfully merging this pull request may close these issues.

3 participants