| 22 Mar 2023 |
 @elvishjerricco:matrix.org | I have thought about doing that already. But it's not clear where to source that cache from. If the point is to keep the mountpoint details out of the nix config, then it has to be acquired when the generation is added to /boot, which doesn't seem ideal | 13:29:02 |
| @elvishjerricco:matrix.org | oh, I misread | 13:29:16 |
| @elvishjerricco:matrix.org | have the zedlet do it. | 13:29:21 |
| @elvishjerricco:matrix.org | huh | 13:29:22 |
| @elvishjerricco:matrix.org | that seems... risky | 13:29:28 |
| @elvishjerricco:matrix.org | and also not helpful for nixos-install | 13:29:40 |
 @linus:schreibt.jetzt | hm yeah | 13:30:36 |
| @elvishjerricco:matrix.org | btw I do use non-legacy mountpoints for initrd FSes, I just also have them in fileSystems with the zfsutil option :P | 13:30:38 |
| @linus:schreibt.jetzt | right | 13:30:50 |
| @elvishjerricco:matrix.org | it's just nice to have mount.zfs handle turning properties into mount options, and to have the fs hierarchy so you can just make new datasets and have the mountpoints be inferred | 13:31:27 |
| @linus:schreibt.jetzt | yeah | 13:31:49 |
| @linus:schreibt.jetzt | [root@sol:~]# zfs list -Ho name | wc -l
277
| 13:32:12 |
| @elvishjerricco:matrix.org | (though I also have different datasets with mountpoint=/ canmount=off... | 13:32:17 |
| @linus:schreibt.jetzt | I don't want to do that in nixos config lol | 13:32:19 |
| @elvishjerricco:matrix.org | yea... | 13:32:26 |
| @linus:schreibt.jetzt | (ok, like half of that is podman image layers actually. But still) | 13:32:52 |
| @elvishjerricco:matrix.org | I believe ZFS's dracut module handles the stage 1 file systems by searching the pool for the bootfs property or its synonyms, and then also looking for child datasets that cover any critical mount points | 13:33:32 |
| @elvishjerricco:matrix.org | that should be easy to do with nixos | 13:33:40 |
| @elvishjerricco:matrix.org | Linux Hackerman: https://openzfs.github.io/openzfs-docs/man/7/dracut.zfs.7.html?highlight=dracut | 13:37:15 |
| 23 Mar 2023 |
|  @ckie:ckie.dev changed their display name from ckie (they/them; heavily limited keyboard usage, dictation or voice only) to ckie (they/them; limited keyboard usage, voice preferred). | 02:07:43 |
| 24 Mar 2023 |
| @elvishjerricco:matrix.org | looking over the networkd PR again, I've got two lingering questions. 1) Should the environment.etc thing be in there? I barely used it and it's not hard to work around its absence. 2) How can I best document the difference between boot.initrd.network.enable and boot.initrd.systemd.network.enable? It's similar to the difference between systemd.network.enable and networking.useNetworkd. The former simply turns on systemd-networkd, the latter also does some automatic configuration for networking.* things. Similarly, boot.initrd.systemd.network.enable just turns on systemd-networkd, and boot.initrd.network.enable also automatically configures DHCP on interfaces. | 23:07:24 |
 colemickens | (been carrying that pr a while) Does the latter option enable DHCP specifically or does it hoist the regular config into stage1? I thought it was the latter? | 23:33:57 |
| @elvishjerricco:matrix.org | it is not the latter | 23:34:21 |
| @elvishjerricco:matrix.org | There is no code in the PR that automatically copies the stage 2 network config into stage 1 | 23:34:58 |
| @elvishjerricco:matrix.org | though I could see that being a useful followup PR | 23:35:05 |
| 25 Mar 2023 |
| colemickens | Now that you say that, I remember yoinking the config so I could specify it for both. My mistake. (Excited to see it merged 🤞🙏) | 00:22:59 |
 Arian | Haven't followed the discussions here for a while. Where are we at these days? :D | 16:12:24 |
| @elvishjerricco:matrix.org | Arian: networking is an open pr and I think the only other remaining featureset is the weird LUKS stuff? | 16:22:04 |
| Arian | ncei | 16:22:22 |
| Arian | * nice | 16:22:25 |
