| 19 Mar 2022 |
bobvanderlinden | Hmm, at the moment, mine is 18M (/boot/kernels/9cvnrh9wh6r707klrv7aawl8zm8w22rs-initrd-linux-5.15.27-initrd) | 10:07:08 |
@elvishjerricco:matrix.org | Also, on some systems I'm pretty sure the decompression of the initramfs is extremely costly | 10:07:14 |
Arian | but what if we have a /boot/nix/store and initrd is just a small thing mounting that :Exploding head: | 10:07:23 |
@elvishjerricco:matrix.org | my rpi boots with EFI and Grub and it takes 3 minutes to reach the kernel | 10:07:27 |
Arian | then we can have garbage collection etc :P | 10:07:31 |
@elvishjerricco:matrix.org | that's... actually an incredibly interesting idea lol | 10:07:51 |
@elvishjerricco:matrix.org | In reply to @bobvanderlinden_:matrix.org Hmm, at the moment, mine is 18M (/boot/kernels/9cvnrh9wh6r707klrv7aawl8zm8w22rs-initrd-linux-5.15.27-initrd) That's impressive | 10:08:06 |
@elvishjerricco:matrix.org | Er, is that the systemd one or a regular one | 10:08:24 |
@elvishjerricco:matrix.org | * Er, is that the systemd one or a regular one? | 10:08:26 |
Arian | current one I suppose | 10:08:31 |
Arian | Does FAT32 support hardlinks? | 10:08:38 |
Arian | probably not right? | 10:08:49 |
@elvishjerricco:matrix.org | no idea | 10:08:55 |
| * colemickens had historically seen that on rpi but it went away after some recent updates to grub/uboot or the rpi firmware iirc | 10:08:59 |
Arian | still. proper nix store on the ESP doesn't sound too wild. Sounds like a good idea | 10:09:08 |
@elvishjerricco:matrix.org | Arian: That wouldn't work exactly, as it wouldn't be compressed. | 10:09:31 |
@elvishjerricco:matrix.org | But something in that direction, like an extra boot stage, is interesting | 10:09:59 |
Arian | stage 1.5 | 10:10:13 |
@elvishjerricco:matrix.org | I will not be pursuing this madness for the sake of my own sanity :P | 10:10:34 |
bobvanderlinden | Do any of you have experience with advanced mkOptions and submodules?
I'm trying to make the systemd units, services, mounts, etc options reusable for systemd, systemd-user and systemd-initramfs. What would be a good approach?
I have worked on a solution that still feels quite dirty, but it is easily reusable: https://github.com/bobvanderlinden/nixpkgs/commit/06fa176a1bab3ca1908188649fb3bd117b42c2f8 | 10:12:17 |
bobvanderlinden | Oh sorry, this commit is more relevant: https://github.com/bobvanderlinden/nixpkgs/commit/e5ad5b33604e9cb7bf2c37df179518140db7e430 | 10:16:00 |
bobvanderlinden | basically, it creates a submodule for each of the unit-types (services, mounts, etc). The submodule has:
{
options = {
${type} = mkOption {
...
};
};
config = {
units = convertToUnit config.${type};
};
}
That means that such modules need to be merged to get to a systemd module. I'm not sure if nixos config is capable of this or whether I should just write it out, like systemd.nix and systemd-user.nix also do.
| 10:20:13 |
@elvishjerricco:matrix.org | Sidenote, are you moving the systemd.* options to boot.systemd.*? | 10:21:58 |
@elvishjerricco:matrix.org | Cuz systemd units aren't all about booting | 10:22:08 |
bobvanderlinden | oh sorry, no I get confused by systemd.nix being in nixos/modules/boot/systemd.nix. I did 'move' things to boot.iniramfs.systemd for the stage-1 / inird stuff | 10:24:21 |
bobvanderlinden | * oh sorry, no I get confused by systemd.nix being in nixos/modules/boot/systemd.nix (while the option sits in systemd.*). I did 'move' things to boot.iniramfs.systemd for the stage-1 / inird stuff | 10:24:59 |
@elvishjerricco:matrix.org | Also, if I may nitpick, the systemd docs recommend to call it initrd even though initramfs is more technically correct. They just have a ton of stuff that calls it initrd and basically ask everyone to just play along | 10:25:14 |
bobvanderlinden | hmm, it's true that system only refers to initrd | 10:28:19 |
@elvishjerricco:matrix.org | bobvanderlinden: btw I had started what I'm doing today on top of your pr-refactor-systemd-module branch. Is that pr-reusable-systemd-module branch (refactor vs reusable) the one you're actually planning to try to get merged? | 10:28:50 |
bobvanderlinden |
Is that pr-reusable-systemd-module branch (refactor vs reusable) the one you're actually planning to try to get merged?
Yes, though pr-refactor-systemd-module were the commits that I am confident that it will get merged in a form simliar to what it currently is.
pr-reusable-systemd-module might be taking things 'too far' in terms of reusabability. Even though we can use this in 3 places, they way it is using modules and merging will have a higher probability that a reviewer will reject the change.
| 10:32:08 |