| 22 May 2023 |
 @nikstur:matrix.org | With the exception of vfat where they do something similar to what we do in our iso images: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/cd-dvd/iso-image.nix#L437 | 16:20:08 |
| @nikstur:matrix.org | And XFS which I don't really understand | 16:20:22 |
 @elvishjerricco:matrix.org | TIL it's common for mkfs.* to support prepopulation | 16:26:12 |
 Arian | So then we can get rid of qemu no? | 16:28:59 |
| @elvishjerricco:matrix.org | I doubt it? I think the thing qemu is for is so we can just run a regular install process. We don't have a static fs tree to populate with | 16:30:01 |
| @nikstur:matrix.org | Maybe make-diks-image-ng.nix for most use-cases? | 16:30:17 |
| Arian | But the FS tree is just a nix store closure no? | 16:30:31 |
| @nikstur:matrix.org | * Maybe make-diks-image-ng.nix for ~~most~~ a few use-cases? | 16:30:33 |
| Arian | /Etc gets populated in boot | 16:30:46 |
| @elvishjerricco:matrix.org | Arian: from make-disk-image.nix:
The Nix-store only image only need to run LKL tools to produce an image and will never spawn a virtual machine, whereas full images will always require a virtual machine, b
ut also use LKL.
| 16:31:13 |
| Arian | What else is there to populate except for some directories? | 16:31:17 |
| @elvishjerricco:matrix.org | so we already don't need a vm if we're just making a nix store image | 16:31:27 |
| @elvishjerricco:matrix.org | * Arian: from make-disk-image.nix:
The Nix-store only image only need to run LKL tools to produce an image and will never spawn a virtual machine, whereas full images will always require a virtual machine, but also use LKL.
| 16:31:40 |
| @elvishjerricco:matrix.org | Arian: A big part of what the VM is used for is useBootLoader | 16:32:30 |
| @elvishjerricco:matrix.org | because you actually have to do a boot loader install process | 16:32:40 |
| Arian | For EFI that's just files on the ESP | 16:33:01 |
| @nikstur:matrix.org | I have built disk images like that, but it might be hard to make all the installer tools behave | 16:33:42 |
| @nikstur:matrix.org | And then there are fun things like useSecureBoot where sd-boot populates efi-vars | 16:34:09 |
| @nikstur:matrix.org | * And then there are fun things like useSecureBoot where bootctl populates efi-vars | 16:34:28 |
| @elvishjerricco:matrix.org | yea EFI vars are actually important | 16:34:37 |
| @elvishjerricco:matrix.org | you can't just make an esp tree | 16:34:46 |
| @nikstur:matrix.org | Although in principle they can be manipulated outside a VM. But I doubt bootctl can | 16:35:06 |
| Arian | EFI vars have nothing to do with the disk image | 16:35:36 |
| Arian | They're stored on EEPROM | 16:35:42 |
| @elvishjerricco:matrix.org | you mean nvram? | 16:35:53 |
| @elvishjerricco:matrix.org | and still | 16:35:58 |
| Arian | Yes sorry | 16:35:58 |
| @nikstur:matrix.org | In reply to @elvishjerricco:matrix.org
you can't just make an esp tree You can just put a boot loader in $esp/EFI/BOOT/BOOTX64.EFI and then you have a working disk image | 16:35:59 |
| @elvishjerricco:matrix.org | you need to produce both the esp and the ovmf variable file with the variables set | 16:36:57 |
| Arian | Efivars only need to be modified on non-compliant broken UEFI implementations. And that has to happen at installation time not at image building time | 16:36:59 |
